Redux で非同期アクションにミドルウェアを使用する理由

Redux で非同期フローにミドルウェアが必要なのはなぜですか?

最初は、Redux は非同期データ フローをサポートしていないように見えるかもしれません。 「Redux ストアは同期データ フローのみをサポートします。」しかし、これは当てはまりません。

指定された例では、コンテナ コンポーネントは確実に非同期 API を呼び出し、その後必要なアクションをディスパッチできます。実際、ボタンがクリックされたときにフィールドが更新されることからわかるように、このアプローチは適切に機能します。

では、この戦略の問題点は何でしょうか?

主な懸念は、多数のコンポーネントが同じ動作を実行する可能性がある、またはデバウンスなどの機能を組み込むことが望ましい場合がある、より大規模なアプリケーションのコンテキストで発生します。さらに、ID の自動インクリメントなどのタスクのためにアクション クリエーターの近くのローカル状態を保存すると有益な場合があります。

メンテナンスの観点からは、アクション クリエーターを個別の機能に分離することで問題が簡素化され、アクション クリエーターの開発と維持が簡素化されます。 codebase.

Redux Thunk や Redux Promise などのミドルウェアは、構文シュガーを通じてコードを簡素化しますが、そうではありません。非同期アクションを処理する目的で必ず必要です。

ミドルウェアなし:

ミドルウェアがない場合、以下に示すように、アクション作成者は非同期操作を直接実行できます。

function loadData(dispatch, userId) {
  fetch(`http://data.com/${userId}`)
    .then(res => res.json())
    .then(
      data => dispatch({ type: 'LOAD_DATA_SUCCESS', data }),
      err => dispatch({ type: 'LOAD_DATA_FAILURE', err })
    );
}

// in component
componentWillMount() {
  loadData(this.props.dispatch, this.props.userId); // pass dispatch as argument for async action creator
}

サンク付きミドルウェア:

Redux Thunk は、非同期アクションをディスパッチするためのより簡潔な構文を提供します:

function loadData(userId) {
  return dispatch =>
    fetch(`http://data.com/${userId}`)
      .then(res => res.json())
      .then(
        data => dispatch({ type: 'LOAD_DATA_SUCCESS', data }),
        err => dispatch({ type: 'LOAD_DATA_FAILURE', err })
      );
}

// in component
componentWillMount() {
  this.props.dispatch(loadData(this.props.userId)); // dispatch as usual
}

ミドルウェアの利点:

Redux Thunk のようなミドルウェアを使用する利点は、アクションからコンポーネントが切り離されることにあります。クリエイターの実装の詳細。コンポーネントは、アクション クリエーターが同期か非同期か、Redux ステートまたは他のアクション クリエーターと対話するかどうかを認識しません。

ミドルウェアの代替:

Redux Thunk はRedux アプリケーションで非同期リクエストを処理する唯一のアプローチではありません。もう 1 つの魅力的な代替手段は、Redux Saga です。これにより、受信アクションを処理し、追加のアクションを生成する前にリクエストを変換または実行する、長時間実行される「サガ」の定義が可能になります。

以上がRedux で非同期アクションにミドルウェアを使用する理由の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。