私はReduxを使ってアプリケーションを作成しており、アクションとレデューサーを別々のファイルに配置するのがなぜベストであるかについて頭を悩ましています。少なくとも、それは私がすべての例から得ている印象です。Redux：アクションとレデューサーを同じファイルに入れてみませんか？
各アクションまたはアクション作成者は、（switch文内の）減速機によって呼び出される単一の関数にマップされているようです。これらを同じファイルにまとめるのは理にかなっていませんか？また、ファイル間でエクスポート/インポートする必要がないため、アクションタイプとスイッチのケースで同じ定数を使用する方が簡単です。 Reduxの作成者ダン・アブラモフ監督から
：
多くの減速は1つのアクションを処理することができます。 1つのレデューサーが多くの処理を処理することがあります。 それらをまとめることで、Fluxと Reduxアプリケーションのスケールの多くの利点が無効になります。これにより、コードが膨らんで不要になります カップリング。 異なる場所から同じアクションに反応する柔軟性が失われ、アクション作成者が 「セッター」のように動作し始め、特定の状態シェイプに結合されて、 コンポーネントが結合されます。 Redux docsから
：
私たちは、あなたが各状態の特定のスライスへの更新を担当し ある独立した小さな減速関数を記述示唆しています。我々はこれを パターン「減速材組成」と呼ぶ。与えられたアクションはすべて で処理されます。 1つのアクションが状態 ツリーの異なる部分に影響を与える可能性があるため、これはコンポーネントが実際の データから切り離された状態を維持し、コンポーネントがこれを認識する必要はありません。
詳細については、this conversation on twitterおよびthis issue on githubを参照してください。
「多くのレデューサーが1つのアクションを処理できます。」私の質問に答えました。ありがとう。しかし、私は、1つのアクションが複数のレデューサーによって処理される状況を考えることはできません。 –
あなたは、空港を管理するためのアプリを開発しているチームのメンバーであるとします。あなたは、飛行状況メッセージを処理するアプリケーションの部分を構築する責任があります。別の開発者は、滑走路上の離陸と着陸のスケジュールを処理するアプリの別の部分に取り組んでいます。アプリのこれらの2つの部分は、Redux州の全く異なる支店で処理され、異なる還元剤を使用します。あなたと他の開発者の両方は、あなたのどちらの側もあなたのどちらのことを認識していなくても、あなたの特定の部分に対してFLIGHT_CANCELLEDのアクションに応答する必要がある減速機を作成します。 –
ああ大丈夫です！今それは理にかなっています。だからパブ・サブ・パターンのようなものだと言いますか？ –
関連性：https://github.com/erikras/ducks-modular-redux – zerkms