247

最近Reduxを発見しました。それはすべてよさそうだ。Redux over Flux を使用することの欠点、落とし穴、または妥協点はありますか? ありがとう

4

7 に答える 7

416

Reduxの作者はこちら!

それを使用して、次の妥協をするつもりだと言いたいです。

  • 突然変異を避けることを学ぶ必要があります。Flux はデータの変更について意見がありませんが、Redux は変更を好みません。Redux を補完する多くのパッケージは、状態を決して変更しないと想定しています。redux-immutable-state-invariant のような開発専用パッケージでこれを強制するか、 Immutable.jsを使用するか、自分自身とチームが非ミュータティブ コードを書くことを信頼することができますが、これは知っておく必要があることであり、これはチームによって受け入れられる意識的な決定であること。

  • パッケージを慎重に選択する必要があります。Flux はundo/redopersistence、またはformsなどの「近く」の問題を明示的に解決しようとはしませんが、Redux にはミドルウェアやストア エンハンサーなどの拡張ポイントがあり、若いながらも豊かなエコシステムを生み出しています。これは、ほとんどのパッケージが新しいアイデアであり、まだクリティカル マスの使用を受けていないことを意味します。数か月後には明らかに悪いアイデアになるものに依存するかもしれませんが、まだ判断するのは困難です。

  • Flow の適切な統合はまだ行われていません。 現在、Flux では、Reduxがまだサポートしていない非常に印象的な静的型チェックを行うことができます。到着しますが、少し時間がかかります。

1 つ目は初心者にとって最大の障害であり、2 つ目は熱狂的なアーリー アダプターにとっては問題になる可能性があり、3 つ目は個人的な不満です。それ以外には、Redux を使用することで、Flux が回避できる特定の欠点がもたらされるとは思いません。また、Flux と比較して利点があると言う人もいます。


Redux を使用する利点に関する私の回答も参照してください。

于 2015-10-02T22:12:40.657 に答える
37

Redux と Flux はどちらも、多くの一般的なパターン、特に非同期データ フェッチを伴うパターンをカバーするために、かなりの量のボイラープレート コードを必要とします。Redux のドキュメントには、ボイラープレート削減の例がいくつかあります: http://redux.js.org/docs/recipes/ReducingBoilerplate.html。Alt や Fluxxor などの Flux ライブラリから必要なすべてを取得できますが、Redux は機能よりも自由を好みます。これは一部の開発者にとってマイナス面になる可能性があります。なぜなら、Redux はユーザーの状態について特定の仮定を行い、それが不注意で無視される可能性があるからです。

あなたの質問に真に答える唯一の方法は、できれば個人的なプロジェクトで Redux を試すことです。Redux は、より優れた開発者エクスペリエンスの必要性から生まれました。また、関数型プログラミングに偏っています。レデューサーや関数構成などの関数の概念に慣れていない場合は、速度が低下する可能性がありますが、わずかです。これらのアイデアをデータ フローに取り入れる利点は、テストと予測が容易になることです。

免責事項: 私は Flummox (人気のある Flux 実装) から Redux に移行しましたが、利点は欠点をはるかに上回ります。私は自分のコードで魔法をはるかに少なくすることを好みます。魔法が少なくなると、ボイラープレートが少し増えますが、支払う代償は非常に小さくなります。

于 2015-08-16T02:21:20.823 に答える
17

FluxRedux。. .

Redux は純粋な Flux 実装ではありませんが、間違いなく Flux に触発されています。最大の違いは、アプリケーションのすべての状態を含む状態オブジェクトをラップする単一のストアを使用することです。Flux で行うようにストアを作成する代わりに、単一のオブジェクトの状態を変更するレデューサー関数を作成します。このオブジェクトは、アプリのすべての状態を表します。Redux では、現在のアクションと状態を取得し、新しい状態を返します。つまり、アクションはシーケンシャルであり、状態は不変です。これにより、Redux の最も明白な短所がわかりました (私の意見では)。


Redux は不変の概念をサポートしています。

不変性の理由

これにはいくつかの理由があります:
1.コヒーレンス- ストアの状態は常にリデューサーによって変更されるため、誰が何を変更したかを簡単に追跡できます。
2.パフォーマンス- 不変であるため、Redux は前の状態が !== 現在の状態であるかどうかを確認し、そうであればレンダリングする必要があるだけです。レンダリングを決定するために毎回状態をループする必要はありません。
3.デバッグ- Time Travel DebuggingHot Reloadingなどの新しい素晴らしいコンセプト。

更新: 十分に説得力がない場合は、Lee ByronのImmutable User Interfacesに関する優れた講演をご覧ください。

Redux では、この考えを維持するために、コードベース/ライブラリを通じて開発者の規律が必要です。ライブラリを選択し、変更不可能な方法でコードを記述していることを確認する必要があります。

Flux の概念のさまざまな実装 (およびニーズに最も適したもの) について詳しく知りたい場合は、この便利な比較を確認してください。

そうは言っても、Redux が JS の将来の開発が進む場所であることを認めなければなりません (これらの行を書くことに関して)。

于 2016-01-21T03:00:33.703 に答える