React Thunk と React Saga は、React アプリケーションの副作用を処理するため、特に API 呼び出しなどの非同期操作を管理するためのミドルウェア ライブラリです。どちらも Redux で一般的に使用されますが、目的とアプローチが若干異なります。

反応サンク

1. 概要:

React Thunk は、アクション オブジェクトの代わりに関数を返すアクション クリエーターを作成できるミドルウェアです。これは、API リクエストや複雑な同期ロジック (アクションの条件付きディスパッチなど) などの非同期操作を処理する場合に便利です。返された関数は引数としてdispatchとgetStateを受け取り、他のアクションをディスパッチしたり、関数内の現在の状態にアクセスしたりすることができます。

2. 主要な概念:

• ミドルウェア: サンクは、関数 (サンクなど) を処理するストアの機能を拡張するミドルウェアです。
• 非同期アクション: サンクを使用すると、アクションのディスパッチを遅らせたり、特定の状態またはロジックに基づいて条件付きでディスパッチしたりできます。
• シンプル: サンクは比較的単純なので、ほとんどのユースケースで簡単に使用できます。

3. 仕組み:

• 通常、アクション作成者はプレーンな JavaScript オブジェクト (アクション) を返します。
• サンクを使用すると、アクション作成者はディスパッチと getState を受け取る関数 (「サンク」) を返すことができます。この関数内で、非同期ロジック (API からのデータのフェッチなど) を実行し、実際のアクションをディスパッチできます。

4. 例:

React アプリで redux-thunk を使用する基本的な例を次に示します:

   // Action Creator with Thunk
   export const fetchUser = () => {
     return async (dispatch) => {
       dispatch({ type: 'FETCH_USER_REQUEST' });
       try {
         const response = await fetch('/api/user');
         const data = await response.json();
         dispatch({ type: 'FETCH_USER_SUCCESS', payload: data });
       } catch (error) {
         dispatch({ type: 'FETCH_USER_FAILURE', payload: error });
       }
     };
   };

5. サンクの利点:

• シンプルさ: サンクは理解しやすく、実装しやすいです。
• 設置面積が小さい: 軽量で、複雑な構成は必要ありません。
• ディスパッチを直接制御: アクションがいつどのようにディスパッチされるかをより詳細に制御できます。

6. 欠点:

• スケーリングが難しい: 複雑な非同期フローの場合、入れ子になったロジックと多数のディスパッチ呼び出しにより、サンクが煩雑になる可能性があります。
• 構造が少ない: サンクは副作用を管理するための特定の構造を強制しないため、適切に処理しないとコードの不整合が生じる可能性があります。

リアクトサーガ

1. 概要:

React Saga は、ジェネレーター関数を使用して副作用をより体系的に処理できるようにするミドルウェアです。サンクのような関数を返す代わりに、「エフェクト」システムを使用して非同期操作を管理し、ロジックのフローを制御します。 Saga は、ディスパッチされたアクションをリッスンし、API 呼び出し、データのフェッチ、その他のタスクなどの副作用を実行できる、長時間実行されるバックグラウンド プロセスです。

2. 主要な概念:

• ジェネレーター関数: サーガは、ES6 ジェネレーター関数 (関数*) を使用して実装されます。これにより、同期のように見える非同期コードを作成できます。
• ウォッチャーとワーカー: サーガは、多くの場合、「ウォッチャー」サガ (ディスパッチされたアクションを監視する) と「ワーカー」サガ (副作用を処理する) に分けられます。
• Take、put、call: Redux-Saga は、副作用をトリガーするタイミング、アクションをディスパッチするタイミング、API を呼び出すタイミングを制御するためのエフェクト クリエーター (take、put、call など) を提供します。

3. 仕組み:

• Redux-Saga を使用すると、副作用の処理を担当するサガ (長時間実行されるバックグラウンド タスク) を定義します。
• サガは通常、ジェネレーター関数として記述され、call (関数を呼び出す) や put (アクションをディスパッチする) などの効果を生成します。
• Saga は、take を使用して特定のアクションを待機したり、takeEvery または takelatest を使用して任意のアクションをリッスンしたりすることもできます。

4. 例:

redux-saga の基本的な使用例を次に示します:

   import { call, put, takeLatest } from 'redux-saga/effects';

   // Worker saga: will be fired on FETCH_USER_REQUEST actions
   function* fetchUser(action) {
     try {
       const response = yield call(fetch, '/api/user');
       const data = yield response.json();
       yield put({ type: 'FETCH_USER_SUCCESS', payload: data });
     } catch (e) {
       yield put({ type: 'FETCH_USER_FAILURE', message: e.message });
     }
   }

   // Watcher saga: spawns a new fetchUser task on each FETCH_USER_REQUEST
   function* mySaga() {
     yield takeLatest('FETCH_USER_REQUEST', fetchUser);
   }

   export default mySaga;

5. Redux-Saga の利点:

• 複雑な副作用に優れています: Saga の効果ベースのアプローチはよりスケーラブルで、複雑な非同期フローの管理に適しています (再試行、デバウンス、またはカスケード API 呼び出しの処理など)。
• テスト可能: サーガはジェネレーター関数を中心に構築されているため、テストが簡単です。
• 宣言型: エフェクトを使用すると、どのような副作用が発生するかが明確になり、フローがより予測可能になります。
• キャンセルとシーケンス: Saga を使用すると、進行中のタスクをキャンセルしたり、イベントのシーケンス フロー (複数のアクションを待機するなど) を強制したりすることが簡単になります。

6. 欠点:

• 急峻な学習曲線: ジェネレーター関数の使用と全体的なパターンは、初心者にとって理解するのが難しい場合があります。
• オーバーヘッド: 小規模なアプリケーションの場合、Thunk のような単純なソリューションに比べて過剰に感じるかもしれません。
• Verbose: サーガには、サンクと比較してより多くの定型コードが含まれる傾向があります。

比較: React Thunk と React Saga

いつどれを使用すればよいですか?

• 次の場合に React Tunk を使用します:

  • アプリケーションには、基本的な API リクエストや条件に基づくディスパッチなど、比較的単純な非同期のニーズがあります。
  • 定型文があまりなく、軽量でわかりやすいソリューションが必要です。

• 次の場合は React Saga を使用します

  再試行、アクションのシーケンス、競合状態、または相互に依存する複数のタスクなど、より複雑な非同期フローを管理する必要があります。
  あなたは宣言型アプローチを好み、副作用をより適切に制御したいと考えています。
  アプリには、長期的にはより優れたテスト容易性とコードの保守容易性が必要です。