数ヶ月前、私は Flux に出会い、それが素晴らしいことを発見しました。私はそれが大好きで、私はそれを使用しています..ほとんどすべての新しいプロジェクトで、redux に会ったとき、私はそれをさらに愛していましたが、数日前に Pete Hunt がツイートを公開しました。彼は人々が何にでもフラックスを使うと判断します。そして、私はそれが完璧な意味を持っていると思いますが、一方で私はそれを理解していません.. 彼はフラックスのケースを説明する別のツイートを公開し、フラックスのユースケースに関する記事も読みました. 簡単に言えば、「アプリに複雑なデータ変更とキャッシュがない場合は、使用しないでください。ただし、そうである場合は、Flux を試すことを強くお勧めします。」なぜフラックスを使用する必要があるのか は完全に理にかなっていますが、複雑なデータ変更がない場合になぜフラックスを使用すべきでないのかは明確ではありません。
記事のダンポイントでは、実際のプロジェクトでこれらの問題（フラックスが解決する）に直面したとき、フラックスの利点を理解しやすくなりますが、まさにこれ（仕事のプロジェクトでこれらの問題に直面したため）を試してみますもう扱いたくないので、すべてのプロジェクトでフラックスを使用してください。
そしてクレイジーな部分は、データの変更だけでなく、UI の状態にもよく使用することです。時計などのウィジェット コンポーネントを使用できるとしましょう。秒の表示/非表示、デジタル/アナログの切り替え、昼間タイプの状態 (昼/夜) などのいくつかの UI 変更を行うことができ、変更されたときにイベントをディスパッチできますが、他のコンポーネントはそれをリッスンして反応することができます。背景色を変更します。ローカルコンポーネントの状態とコンテナ（スマートコンポーネント）の状態だけで簡単に解決できますが、これらすべてのロジックをストア（リデューサー）に配置できるのと同じで、コンポーネントは実際にダンプされ、現在の状態（小道具）とコンテナに反応するだけです(スマート) コンポーネント間のストアとパーティション化された状態をリッスンするだけです。そして、それでも問題ないように見える場合は、すべての UI 状態 (サイドバーの開閉、特定のコンポーネントの変更など) に使用できることを指摘してください。
できる理由：
- それは私にとって予測可能に見えます。アプリ サービスで発生した変更が 1 か所で発生したことは完全にわかっています。
- デバッグが簡単です。すべてのアクションをログに記録するだけで、バグが発生した場合に、何が起こったのかを簡単に見つけて再現できます。
- 心配することなくアプリを簡単に拡張できます。何かをフラックス状態に移動する必要があります。すでに行っているからです。
しかし、圧倒されているように見え、フラックスなしで解決できることにも同意しますが、これらの場合にフラックスを使用しない理由については答えられません。それの何が問題なのですか？私を助けてください。