ずっと前、全く同じ銀河系で、私は Angular 1.3 を学ぶ方法としてフリーセルを作ろうと試み始めました。

ここまで進んだのに、他のことに気を取られてしまいました。これはサイド プロジェクトの常です。

最近少し時間があったので (もちろん、私も期待していませんでした)、もう一度挑戦してみようと思いました。

私は基本的にゼロから始めました。Angular 1.3 にはもう興味がなく、フレームワークが必要な場合は Web のものに VueJS を使用する傾向があるためです。

結果を見るには、github.io にあります: ここをクリックしてフリーセルをプレイしてください!

10 年半前に WPF を学んで以来、私は MVVM スタイルのプログラミングがとても好きでした。 VueJS では、UI を更新するための明示的なイベントを必要とせずに、そのスタイルを非常に簡単に実現でき、さらに改良することもできます。

これは、ゲーム ロジックがビュー ロジックから完全に分離されていることを意味し、このゲームの作成が簡単になりました。

私は何らかの理由でカードを 2D ギザギザの配列に保存することに決めたので、すべてが飛行機で航行したわけではありません。ひどいアイデアではありませんが、各内部配列は列であるため、カードを CSS グリッド内で正しくレイアウトしようとしたとき、
のように外側の配列を反復処理してから内側の配列を反復処理することはできませんでした。

これにより、列が行としてレイアウトされるためです。そのため、オブジェクトではなくインデックスを使用し（なぜ VueJS は 0 から開始しないのですか？）、内部ループで外部配列をループする必要がありました。

私が行った他の 2 つの悪い設計上の決定は、オートコンプリートを実装することと、クリック ハンドラーをビュー内ではなくゲーム (モデル) 内の 1 つの関数にすぎず、ビューにどのコースを理解させるかであると思います。実行すべきアクション。

プレイヤーがどのアクションを意味するかをゲームに決定させる (つまり、カード (またはカードのスタック) を選択する、カードを別のスタックに置く、またはカードの選択を解除する) ことで、後日リファクタリングする可能性のあるスパゲッティ コードが生成されました。

当初、ロジックについて考えたくなかったため、オートコンプリートを実装するつもりはありませんでした。しかし、それなしでいくつかのゲームをプレイした後、各カードをホーム列にタップするのに非常に退屈したため、それを実装する必要があると感じました。

それはただ悪いことだから、銃を持ち続けるべきだった。これは膨大なコードの塊であり、当初は多くのバグや頭を悩ませる原因となっていました。完全自動でもありません。一方で、今ではほとんどタップする必要がなくなりました。

私はカードをドラッグ アンド ドロップできないようにすることにこだわりました。これは主に携帯電話とタブレットでプレイするために作成したためです。そのため、所定の位置にタップするのが UX 的にはるかに簡単です (少なくとも私の UX、 ymmv).

目に見えないところにいくつかのバグが残っているとしても、全体的には結果に満足しています。