1

プレイヤーのリストがあり、それぞれにステータスがあります。プレーヤーをステータス別に並べ替え、次のようにアイコンでステータスを表示します。

ここに画像の説明を入力

プレーヤーをクリックすると、ステータスアイコンがすぐに変更されますが、遅延が発生するまで順序が変更されないようにする必要があります (UX 上の理由から)。これを行うための最良の方法についての考え。

うまくいかないアイデアは次のとおりです。

  1. player.statusすぐに変更します(順序はあなたの下で変更されます)。

  2. タイムアウトによる変更の遅延player.status(アイコンはすぐには変更されず、何も起こらなかったように感じます)。

  3. #2を実行し、jQueryを介してアイコンクラスを変更します。いくつかの変更を行うと、遅延更新により再描画が行われ、設定したクラスが失われます.

私が持っている最良のアイデアは次のとおりです(そして、それがかなりくだらないことを認識しています):

  1. #2 を実行しますが、プレイヤーごとのセッション変数 ( Session.get("player-$ID-status")) を使用して最新バージョンのステータスを保存します。

これを機能させるには厄介な配管がいくつかありますが、そうなると思います。それを行うためのより良い方法(または「流星」の方法)を聞きたいです。

4

1 に答える 1

2

必要なことを達成するためのより微妙な方法がいくつかあると思います。1 つの方法は、ユーザーの行動と変化する状態との間に何らかの結合を引き起こします。2 番目の方法は、流星の方法に沿った、より切り離された優雅なアプローチです。

まず、やや密結合のアプローチ:

ユースケースでは、ユーザーが変更を希望することを示したときに、プレーヤーが新しいステータスに変更される必要があることを知っています。ここで重要なのは、プレイヤーが状態に変わるインタースティシャル状態があることだと思います。

この内訳を考えると、この動作を次の 2 つの属性でモデル化できます。

player.statusplayer.statusWillBe

このように実装すると、アイコンを offplayer.changingToStatusに、順序を off にできplayer.statusます。

これは、すべてのプレイヤーが と の同じ値で開始することを意味しplayer.statusplayer.statusWillBeアイコンは の値に基づいて正しく設定されplayer.statusWillBeます。

この種の内訳では、ユーザーの操作に基づいて動作を非常にきめ細かく制御できますが、UI の応答はユーザーの動作と非 UI コンポーネントに密​​接に結び付いています。このアプローチを使い続けると、すぐに醜くなる可能性があります。基本的に、モデル/状態とUIを混在させます。

より複雑な分離アプローチ (流星の方法に沿ったもの):

プレーヤーの状態を変更するためのステート マシンを実装します。その後、変更のレベルで状態の変更をキャッチできます。状態が変化すると、UI の再描画を引き起こすコンテキストを無効にします。この種のアプローチは、UI を「モデル」から完全に分離するため、はるかにクリーンです。Meteor コンテキストとその無効化は、基になるモデルの変更に基づいてクライアント側の UI を再描画するための鍵であり、2 つを密接に結合することはありません。

また、このパターンをよりよく理解するために、次のスクリーンキャストを強くお勧めします: Meteor reactivity with context.

于 2012-12-31T05:42:43.317 に答える