この YouTube ビデオを見ました。
ここで Jing は、ゴーストの新しいメッセージ数の問題の例と、Flux を使用してそれを修正した方法を示しています。そのような問題につながる特定の一連のイベントは何ですか? これはマルチスレッド環境による問題ですか? 単純なコード構造はさておき、Web ブラウザの Javascript のようなシングル スレッド環境ではフラックスのようなアーキテクチャが必要ですか?
この YouTube ビデオを見ました。
ここで Jing は、ゴーストの新しいメッセージ数の問題の例と、Flux を使用してそれを修正した方法を示しています。そのような問題につながる特定の一連のイベントは何ですか? これはマルチスレッド環境による問題ですか? 単純なコード構造はさておき、Web ブラウザの Javascript のようなシングル スレッド環境ではフラックスのようなアーキテクチャが必要ですか?
特にシングルスレッド言語でフラックスが必要な理由について、同様の疑問がありました。この特定の質問が私の助けになることがわかりました。
ここでのポイントは、シングル スレッドかマルチ スレッドかということではありません。ここでのポイントは、モデルとビューの間のバインディングがコントローラーを使用して双方向であるということです。したがって、懸念を引き起こすのは、モデルがビューを更新し、それがモデルを更新する可能性があることです。これは、ビデオの大きな MVC の図に示されています。
短所
ビデオで伝えられている主な欠点は、独立したモデルとビューの数が増えるにつれて、独立したモデルとビューの間の双方向の関係をデバッグすることが非常に困難になることです。
ビデオに示されているチャットの例は、チャット モジュールと対話するさまざまな独立したビューを追加しようとしたときに、対話が各ビューでますます複雑になったという事実の例です。
救助へのフラックス
Flux は、モデルとビューの間の双方向の関係を壊すだけで上記の問題を解決しようとします。これにより、ビュー内の各アクションがモデル/データストアを更新するディスパッチャに送られ、処理が終了するとビューが更新されます。
データフローはモデルからビューへ(一方向) であり、その逆ではないため、コードの理解、デバッグ、および管理がはるかに簡単であることがわかります。