[解決済み] Facebook FluxよりReduxを使う理由とは？[クローズド］

2022-03-19 22:26:53

質問

私が読んだのはこの回答 , 定型文の削減 GitHub のサンプルを見て、redux も少し試してみました (todoアプリ)。

私の理解では redux公式ドキュメントの動機は、従来の MVC アーキテクチャと比較して、長所を提供します。しかし、それは質問に対する答えを提供するものではありません。

Facebook FluxよりReduxを使うべき理由とは？

それはプログラミングスタイルの問題だけなのでしょうか？それとも、reduxのアプローチから派生する能力・開発ツールに問題があるのでしょうか？スケーリングとか？それともテスト？

reduxは、関数型言語から来た人たちのための流動的なものだと言っていいのでしょうか？

この質問に答えるには、fluxとreduxのモチベーションポイントである実装の複雑さを比較するとよいでしょう。

以下、モチベーションポイントは redux公式ドキュメント motivations :

楽観的な更新の処理 ( のように、5点目にはほとんど依存しないと理解しています。facebook fluxでの実装は難しいのでしょうか？ )
サーバーでのレンダリング ( facebook fluxでも可能です。reduxと比較して何か利点はありますか？ )
ルート遷移を行う前にデータをフェッチする ( なぜfacebook fluxでは実現できないのか？そのメリットは？ )
ホットリロード( で可能です。リアクトホットリロード . なぜreduxが必要なのか？ )
Undo/Redo機能
その他に何かポイントはありますか？状態の永続化とか...。

解決方法は？

Reduxの作者はこちら!

Reduxはその Fluxとの違いです。全体的には同じアーキテクチャですが、Fluxがコールバック登録を使うのに対し、Reduxは関数型コンポジションを使うことで、複雑さを軽減しているのです。

Reduxには根本的な違いはありませんが、Fluxでは実装が難しい、あるいは不可能な、ある種の抽象化を容易に、あるいは少なくとも実装可能にするものだと感じています。

減速機の構成

たとえば、ページネーション。私の Flux + React Routerの例はページネーションを処理しますが、そのためのコードはひどいものです。ひどい理由のひとつは Fluxは、店舗をまたいで機能を再利用することを不自然にしています。 2つのストアが異なるアクションに対応してページ送りを処理する必要がある場合、共通のベースストアを継承するか（まずい！継承を使用すると、特定のデザインに自分を閉じ込めてしまいます）、イベントハンドラの中から外部で定義した関数を呼び出し、Fluxストアのプライベートステートに対して何らかの操作を行う必要があります。全体的に面倒なことになります（可能な範囲ではありますが）。

一方、Reduxでは、Redducerの合成によりページネーションが自然に行われます。ずっとreducerなので、「？ページ処理用リデューサを生成するリデューサファクトリで、次にそれをレデューサーツリーで使用する . なぜこんなに簡単なのかというと、その鍵は Fluxではストアはフラットですが、ReduxではReactのコンポーネントがネストできるように、機能合成によってリデューサをネストすることができます。

また、このパターンにより、ノーユーザーコードのような素晴らしい機能が可能になります。アンドゥ/リドゥ . FluxアプリにUndo/Redoをプラグインするのが2行のコードで済むと想像できますか？難しいですね。Reduxを使えば、それは -またしても、reducer composition patternのおかげです。このパターンについては、何も新しいことはないことを強調しておきます。エルム・アーキテクチャは、Fluxの影響を受けています。

サーバーレンダリング

しかし、20ものFluxライブラリがそれぞれサーバーでのレンダリングを「より簡単に」しようと試みているところを見ると、おそらくFluxはサーバーでは粗削りなところがあるのでしょう。実際のところ、Facebookはあまりサーバレンダリングをしないので、あまり気にしておらず、エコシステムに頼っているのです。

従来のFLUXでは、ストアはシングルトンです。つまり、サーバー上で異なるリクエストのデータを分離するのは難しいのです。不可能ではありませんが、難しいです。そのため、ほとんどのFluxライブラリ（そして新しいフラックスユーティリティそのため、リクエストごとにストアをインスタンス化することができます。

Fluxで解決しなければならない問題はまだあります（自分で解決するか、以下のようなお気に入りのFluxライブラリの助けを借りて）。 Flummox またはアルト ):

ストアがクラスである場合、リクエストごとにディスパッチャでストアを作成および破棄するにはどうすればよいですか？ストアの登録はいつ行うのですか?
ストアからデータをハイドレートして、後でクライアントでハイドレートし直すにはどうすればよいですか？このために特別なメソッドを実装する必要がありますか？

確かにFluxフレームワーク（vanilla Fluxではない）はこれらの問題に対する解決策を持っていますが、私はそれらが複雑になりすぎていると感じています。例えば Flummoxでは、以下のような実装を要求されます。 serialize() と deserialize() あなたのお店で . Alt は、この問題を解決するために takeSnapshot() で、状態を自動的にJSONツリーにシリアライズします。

Reduxはさらに進化しています。 多くのリデューサーによって管理される）単一のストアがあるだけなので、（再）水和を管理するための特別なAPIは必要ない。 ストアを「フラッシュ」したり「ハイドレート」したりする必要はありません。ストアはひとつだけで、その現在の状態を読み取ったり、新しい状態を持つ新しいストアを作成したりすることができます。各リクエストは個別のストアインスタンスを取得します。 Reduxによるサーバーレンダリングについてもっと読む。

繰り返しになりますが、これはFluxでもReduxでも可能なことですが、Fluxのライブラリは大量のAPIと規約を導入することでこの問題を解決していますし、Reduxはコンセプトがシンプルなため、そもそもこの問題を解決する必要さえないのです。

開発者体験

Reduxが人気のあるFluxライブラリになることを意図していたわけではありません。 ReactEuropeでの講演：タイムトラベルを利用したホットリロードについて . 主な目的は1つでした。 Reducerのコードをその場で変更したり、アクションを消すことで「過去を変える」ことができ、再計算された状態を見ることができるようにします。

これができるFluxライブラリは1つもありません。React Hot Loaderもこれをさせない。実際、Fluxストアを編集すると、それをどうしたらいいのかわからず、壊れてしまう。

ReduxはRedducerのコードを再読み込みする必要があるとき、Reduxは以下のように呼び出します。 replaceReducer() そして、アプリは新しいコードで実行されます。Fluxでは、データと関数がFluxストアで絡み合っているので、「関数を置き換えるだけ」ではダメなのだ。さらに、新しいバージョンをDispatcherに再登録する必要があるのですが、これはReduxにはないことです。

エコシステム

Reduxには豊富で急成長しているエコシステム . これは、以下のようないくつかの拡張ポイントを提供しているためです。ミドルウェア . などのユースケースを想定して設計されています。ロギングをサポートします。プロミス , 観測可能なもの , ルーティング , 不変性デブチェック , 永続性などを念頭に置いています。これらすべてが有用になるとは限りませんが、簡単に組み合わせて連動させることができるツール群を利用できるのは嬉しいことです。

シンプルさ

ReduxはFluxの利点（アクションの記録と再生、一方向のデータフロー、依存性のあるミューテーション）をすべて維持し、Dispatcherやストア登録を導入せずに新しい利点（簡単に元に戻せる、ホットリロード）を追加しています。

シンプルであることは、より高度な抽象化機能を実装している間、正気を保つために重要です。

他のFluxライブラリと違って、ReduxのAPIサーフェイスは小さいです。開発者の警告、コメント、サニティチェックを取り除けば、それは 99行 . デバッグするためのトリッキーな非同期コードもありません。

実際に読んでみて、Reduxのすべてを理解することができます。

こちらもご覧ください ReduxとFluxを比較した場合のデメリットについての私の回答です。 .