私はこのスレッドダンアブラモフ監督スポットの前に説明しようとして
短所:-)別の驚くべき答え書き込みます：減速機Aから
機能は、減速機Bからの情報についての情報を必要とするかもしれないが、しかし、このためアクセスできません。
この問題は実際には起こりません。これは、レデューサーをどのように組み合わせるかはあなた次第です。レデューサーが状態ツリーの一部にしか関心がない場合、combineReducersはその部分を受信することを確実にします。しかし、もっと状態が必要な場合は、この特定の減速機を状態全体を受け取るように適用します。
アプリケーション全体には、状態全体とすべてのアクションを処理する1つの縮小機能しかありませんが、アプリケーションコードをある時点でトピック関連モジュールに分割したいと思うでしょう。小さなトピック関連の減速機を書く方が簡単で、それらを1つにまとめることができます。 combineReducersは、必要なときに便利に行うことができるヘルパーです。
- 多くのファイルが混乱し、意図しないエラーが発生します。
- 不要なコード分割。 ...
コードを分割するタイミングまで。無関係の機能を別のファイルに保存するのが好きです。たとえば、私のWebアプリケーションにチャットモジュールがある場合は、おそらくchatパッケージを作成し、その中にチャット関連のコード（ビュー、一連のアクション、およびこれらのアクションを理解する減速機）を配置します。
プロへの移動：それは、再利用可能なアプリでは本当によく働くので
combineReducersに便利です。例えば、私はコメントを扱うモジュールを書くことができます...それの一部のような減速になります。
const initialState = {
commentList: [], // list of { author, text, upvotes }
commentingAllowed: true,
}
function commentReducer(state, action) {
if (typeof state === 'undefined') {
return initialState;
}
switch (action.type) {
// ...
}
}
が、自分のアプリケーションの実際の状態は次のように、より複雑になることがあります：
{
currentArticle: {
title: "Some article",
published: "2017-04-05",
author: "someone",
comments: {
commentList: [],
commentingAllowed: true,
}
}
}
コメントの状態はcurrentArticleにネストされていますが、私のコメントアプリ（具体的にはcommentReducerは記事全体の概念を認識していません！）ので、状態全体を受け取ることは望ましくありません。私は、この減量主体が、そのコメントに対応する国家の部分だけを受け取るようにしたい。
私は一度に多くの記事を持っている可能性があることに注意してください。レデューサーを巧みに組み合わせることで、コメントアプリの複数の「インスタンス」を持つことができ、それぞれは独自の小さな状態を処理します。これには、combineReducers単独よりも少しスマートなグルーコードが必要ですが、減速機がアプリケーション状態の特定の部分、つまり懸念の分離を必要とするのが当然の場合の状況を示しています。