React Context vs React Redux、それぞれをいつ使うべきですか？
React 16.3.0がリリースされました そして Context APIは実験的な機能ではなくなりました。 Dan Abramov（Reduxの作成者）はこれについて良いコメントを書いています ここ /しかしContextがまだ実験的な機能になったのは2年でした。
私の質問は、あなたの意見では、 React Context over React Redux を使用する必要があるのはいつですか？
As Context は実験的な機能ではなくなったので、アプリケーションで直接Contextを使用することができ、設計されたもののように深くネストされたコンポーネントにデータを渡すのに最適になります。
Mark eriksonが彼の blog に書いているように：
小道具の引き渡しを避けるためにReduxのみを使用している場合は、コンテキストがReduxに取って代わる可能性があります - ただし、そもそもReduxはおそらく必要ありません。
Contextは、
Redux DevTools、状態の更新を追跡する機能、集中化されたアプリケーションロジックを追加するmiddleware、およびReduxが可能にするその他の強力な機能なども提供しません。
Reduxははるかに強力で、Context Apiが提供していない多くの機能を提供します。これもAs @danAbramov として言及されています。
React Reduxは内部的にコンテキストを使用しますが、パブリックAPIではこの事実を公開していません。そのため、React Reduxを介してコンテキストを使用することは、直接変更するよりも直接変更するよりもはるかに安全に感じられるはずです。
最新のコンテキストAPIに準拠するように実際に実装を更新するための、Reduxの最新情報
コンポーネント間でデータをやり取りするためにReduxを使用するだけのアプリケーションには、最新のContext APIを使用できますが、redux-thunkまたはredux-sagaを使用して集中型データを使用してAPI要求を処理するアプリケーションには、それでもreduceが必要です。このreduxとは別に、redux-persistのように関連付けられた他のライブラリがあり、これを使用してストアデータをlocalStorageに保存し、リフレッシュ時に再ハイドレートすることができます。これはコンテキストAPIがまだサポートしていないものです。
@dan_abramovが彼のブログで述べたように あなたはReduxを必要としないかもしれない 、そのreduxはのような便利なアプリケーションを持っています
- 状態をローカルストレージに保持してから、そのまま箱から出して起動します。
- サーバー上の状態を事前に記入し、それをHTMLでクライアントに送信し、それから起動します。
- ユーザーのアクションをシリアル化し、状態のスナップショットとともに自動化されたバグレポートに添付することで、製品開発者は
はそれらを再生してエラーを再現できます。- コードの記述方法を大幅に変更することなく、ネットワークを介してアクションオブジェクトを渡して共同作業環境を実装します。
- コードの記述方法を大幅に変更することなく、元に戻す履歴を維持するか、楽観的な変更を実装します。
- 開発中の状態履歴間を移動し、コードが変更されたときにアクション履歴から現在の状態を再評価します（la TDD）。
- 製品開発者が自分のためにカスタムツールを構築できるように、開発ツールに完全な検査および制御機能を提供します。
アプリ.- ほとんどのビジネスロジックを再利用しながら、代替のUIを提供します。
これらの多くのアプリケーションでは、Reduxが新しいContext APIに置き換えられると言うには早すぎる
深く入れ子になったコンポーネントにプロップを渡さないようにするためだけにReduxを使用している場合 その場合は、ReduxをContext APIに置き換えることができます。それはまさにこのユースケースを対象としています。
一方、 あなたが他のすべてにReduxを使用している場合 （予測可能な状態コンテナを持ち、コンポーネントの外側でアプリケーションのロジックを処理し、状態更新履歴を保持し、 Redux DevTools を使用する、 Redux Undo 、 Redux Persist 、 Redux Form 、 Redux Saga 、 Redux Logger など。それなら、ReduxをContext APIに置き換える理由はまったくありません。
参考文献：
私は（やはりAxiosを使って）API呼び出しをするためにredux-thunkと共にreduxを使用し、その応答をreducerにディスパッチすることを好みます。それは清潔で理解しやすいです。
コンテキストAPIはReactコンポーネントがストアにどのように接続されているかについてのreact-reduxの部分に非常に固有のものです。これにはreact-reduxがいいです。しかし、望むなら、Contextは公式にサポートされているので、react-reduxの代わりにContext APIを使うことができます。
したがって、問題はContext API vs react-reduxであり、Context API vs reduxではありません。また、質問は少し意見があります。私はreact-reduxに精通しており、すべてのプロジェクトでそれを使用しているので、これからも使用します。 （私が変えるための動機はありません）。
しかし、今日ちょうどあなたがreduxを学んでいて、あなたがどこでもそれを使ったことがなければ、それはContext APIを打撃し、あなたのカスタムContext APIコードでreact-reduxを置き換える価値があります。たぶん、それはそのようにずっときれいです。
個人的には、それは親しみやすさの問題です。これらが同等であるため、一方を他方を選択する明確な理由はありません。そして内部的には、react-reduxはとにかくContextを使用します。
私にReduxを使用する唯一の理由は以下のとおりです。
- グローバル状態オブジェクトが必要です（デバッグ容易性、永続性など、さまざまな理由から）。
- あなたのアプリは大きいか、これから大きくなりますが、多くの開発者向けに拡張する必要があります。そのような場合、おそらくある程度の間接指定（イベントシステム）が必要です。組織は実際に彼らに耳を傾けることができます
あなたはおそらくあなたのアプリケーション全体のために間接指定のレベルを必要としないので、スタイルを混在させ、同時にローカルの状態/コンテキストとReduxを使用するのは良いことです。
- さまざまな目的でミドルウェアを使用する必要がある場合。 たとえば、アクションのログ記録、エラー報告、サーバーの応答に応じた他の要求のディスパッチなど.
- 複数のエンドポイントから来るデータが単一のコンポーネント/ビューに影響を与える場合。
- アプリケーション内のアクションをもっと制御したい場合。 Reduxはアクションとデータ変更の追跡を可能にし、デバッグを非常に簡単にします。
- サーバーの応答によってアプリケーションの状態を直接変更したくない場合。 Reduxはレイヤーを追加します。ここで、このデータをどのように、いつ、どのように適用するかを決定できます。観察者パターン。アプリ全体で複数の発行者と購読者を作成する代わりに、コンポーネントをReduxストアに接続するだけです。
From： いつReduxを使うの？