0

最近、あるアプリでそれを行いましたが、これが悪い習慣と見なされるのか、それとも問題ないのかを知りたいです。2 つのアクションをリッスンするレデューサーがあるとします。

switch (action.type) {
  case 'PRE_FETCH_ACTION':
    return Object.assign({}, state, {value: action.value, isAllowed: true})
  case 'FETCHED_SUCCESS':
    if (!state.isAllowed) {
      throw Error('You did not dispatch PRE_FETCH_ACTION before fetching!');
    }
    return Object.assign({}, state, {data: action.data, isAllowed: false})
}

したがって、フローは次のとおりです。

  • 発送しますPRE_FETCH_ACTION
  • 外部 API へのフェッチ呼び出しを行います
  • サービスの応答が返ってきたらディスパッチするFETCHED_SUCCESS

誰かがPRE_FETCH_ACTION最初のデータをディスパッチせずにデータをフェッチしようとすると、コードはエラーをスローします。

わかりました、これでうまくいきます。私の懸念は、私が言ったように、これが悪いパターンと見なされるかどうかです。なぜそう思うのですか？状態のisAllowed一部はレデューサーの内部にあるため、コンポーネントのレンダリング メソッドには影響しません。

4

1 に答える 1

1

アプリの状態にそのような「技術的」フラグを付けても問題ないと思います。

あなたのケースでは、アプリの特定の動作を定義する特定の順序でアクションがディスパッチされるようにする必要があります (たとえば、データ取得の開始時に画面にローダーを表示するなど)。そのため、「技術的」フラグが最終的に UI を管理すると思います。

リデューサーを「リデュースのみ」にするには、アクション クリエーターで状態をテストすることにより、ディスパッチする前にチェックを行うことができます。このパターンは Redux のドキュメント about async actionsで詳しく説明されています。次のように、同期アクション「fetchedSuccess」を呼び出す代わりに呼び出す「サンク」アクション作成者でそれを行います。

function toFetchedSuccess(data) {  // "thunk" action creator
    return (dispatch, getState) => {
        const state = getState();  // current state
        if(!state.isAllowed) {
            console.error(
                'You did not dispatch PRE_FETCH_ACTION before fetching!');
            return Promise.resolve();  // nothing to do
        } else {
            return dispatch(fetchedSuccess(data));
        }
    };
}
于 2016-04-01T13:15:41.777 に答える