Immutable.jsまたはその他を使用するかどうか興味があります。 Reduxの物事の一握りで、私は不変使用していない想像できませんでし構築しましたが、私は不変で飼いならさに役立つことはかなり深くネストされた構造を有している_do_。

わお。 それについては言うまでもありません。 はい！ イミュータブルを使用しています！ あなたが言うように、それを実質的な何かに使用しないことを想像するのは難しいです。

@bvaughn私が苦労した領域の1つは、Immutableとコンポーネントの間に線を引く場所です。 不変オブジェクトをコンポーネントに渡すと、純粋なレンダリングのデコレータ/ミックスインを非常に簡単に使用できますが、コンポーネントに不変のコードが含まれることになります（私は好きではありません）。 これまでのところ、私はそれを実行しましたが、Immutable.jsのメソッドに直接アクセスする代わりに、render（）メソッドでセレクターを使用していると思いますか？

正直なところ、これは私たちがまだ厳しい方針を定義していないものです。 多くの場合、「スマート」コンテナでセレクタを使用して、不変オブジェクトからネイティブ値を追加し、ネイティブ値を文字列やブール値などとしてコンポーネントに渡します。不変オブジェクトを渡すこともありますが、ほとんどの場合、 Record型を渡して、コンポーネントがそれをネイティブオブジェクトのように（ゲッターを使用して）処理できるようにします。

私は反対の方向に進んでおり、アクションクリエーターをより些細なものにしています。 しかし、私は本当にreduxから始めたばかりです。 あなたのアプローチに関するいくつかの質問：

1）アクションクリエーターをどのようにテストしますか？ テストが簡単なため、外部サービスに依存しない純粋な同期関数にできるだけ多くのロジックを移動するのが好きです。
2）ホットリロードでタイムトラベルを使用していますか？ react redux devtoolsの優れた点の1つは、ホットリロードがセットアップされると、ストアが新しいレデューサーに対してすべてのアクションを再実行することです。 ロジックをアクションクリエーターに移すとしたら、それは失われます。
3）アクションクリエーターが効果をもたらすために複数回ディスパッチする場合、それはあなたの状態が一時的に無効な状態にあることを意味しますか？ （ここでは、後で非同期にディスパッチするのではなく、複数の同期ディスパッチについて考えています）

どこでもセレクターを使用

はい、それはあなたのレデューサーがあなたの状態の実装の詳細であり、あなたがクエリAPIを通してあなたの状態をあなたのコンポーネントに公開していると言っているようです。
他のインターフェースと同様に、デカップリングして状態のリファクタリングを容易にします。

ImmutableJSを使用する

新しいJS構文のIMOは、通常のJSでリストとオブジェクトを簡単に変更できるため、ImmutableJSを使用することはあまり役に立ちません。 多くのプロパティを持つ非常に大きなリストとオブジェクトがあり、パフォーマンス上の理由で構造的な共有が必要な場合を除いて、ImmutableJSは厳密な要件ではありません。

actionCreatorsでさらに多くのことを行う

@bvaughnあなたは本当にこのプロジェクトを見る必要があります： https ：
@yelouafiにsagas （当初はバックエンドの概念）について話し始めたとき、それはこの種の問題を解決することでした。 私の場合、既存のアプリにオンボーディングしているユーザーを接続しているときに、最初にsagasを使用しようとしました。

1）アクションクリエーターをどのようにテストしますか？ テストが簡単なため、外部サービスに依存しない純粋な同期関数にできるだけ多くのロジックを移動するのが好きです。

私はこれを上で説明しようとしましたが、基本的には...「アヒル」のようなアプローチでアクションクリエーターをテストするのが（これまでのところ私にとって）最も理にかなっていると思います。 アクションクリエーターの結果をディスパッチしてテストを開始し、セレクターを使用して状態を確認します。 このように、単一のテストで、アクションクリエーター、そのレデューサー、および関連するすべてのセレクターをカバーできます。

2）ホットリロードでタイムトラベルを使用していますか？ react redux devtoolsの優れた点の1つは、ホットリロードがセットアップされると、ストアが新しいレデューサーに対してすべてのアクションを再実行することです。 ロジックをアクションクリエーターに移すとしたら、それは失われます。

いいえ、タイムトラベルは使用していません。 しかし、なぜあなたのビジネスロジックがアクションクリエーターになっていることがここで何らかの影響を与えるのでしょうか？ アプリケーションの状態を更新するのはレデューサーだけです。 したがって、作成されたアクションを再実行すると、どちらの方法でも同じ結果が得られます。

3）アクションクリエーターが効果をもたらすために複数回ディスパッチする場合、それはあなたの状態が一時的に無効な状態にあることを意味しますか？ （ここでは、後で非同期にディスパッチするのではなく、複数の同期ディスパッチについて考えています）

一時的な無効状態は、場合によっては実際に回避できないものです。 結果整合性がある限り、通常は問題ありません。 また、アクションクリエーターまたはリデューサーにビジネスロジックが存在するかどうかに関係なく、状態が一時的に無効になる可能性があります。 それは副作用とあなたの店の詳細ともっと関係があります。

新しいJS構文のIMOは、通常のJSでリストとオブジェクトを簡単に変更できるため、ImmutableJSを使用することはあまり役に立ちません。 多くのプロパティを持つ非常に大きなリストとオブジェクトがあり、パフォーマンス上の理由で構造的な共有が必要な場合を除いて、ImmutableJSは厳密な要件ではありません。

（私の目には）Immutableを使用する主な理由は、更新のためのパフォーマンスや構文糖衣構文ではありません。 主な理由は、あなた（または他の誰か）がレデューサー内で着信状態を_偶然に_変更するのを防ぐためです。 それはノーノーであり、残念ながらプレーンなJSオブジェクトで行うのは簡単です。

@bvaughnあなたは本当にこのプロジェクトを見る必要があります： https ：
@yelouafiにsagas （当初はバックエンドの概念）について話し始めたとき、それはこの種の問題を解決することでした。 私の場合、既存のアプリにオンボーディングしているユーザーを接続しているときに、最初にsagasを使用しようとしました。

私は実際にそのプロジェクトを以前にチェックアウトしました:)まだ使用していませんが。 それはきちんと見えます。

私はこれを上で説明しようとしましたが、基本的には...「アヒル」のようなアプローチでアクションクリエーターをテストするのが（これまでのところ私にとって）最も理にかなっていると思います。 アクションクリエーターの結果をディスパッチしてテストを開始し、セレクターを使用して状態を確認します。 このように、単一のテストで、アクションクリエーター、そのレデューサー、および関連するすべてのセレクターをカバーできます。

すみません、その部分を手に入れました。 私が疑問に思っていたのは、非同期性と相互作用するテストの一部です。 私はこのようなテストを書くかもしれません：

var store = createStore();
store.dispatch(actions.startRequest());
store.dispatch(actions.requestResponseReceived({...});
strictEqual(isLoaded(store.getState());

しかし、あなたのテストはどのように見えますか？ このようなもの？

var mock = mockFetch();
store.dispatch(actions.request());
mock.expect("/api/foo.bar").andRespond("{status: OK}");
strictEqual(isLoaded(store.getState());

いいえ、タイムトラベルは使用していません。 しかし、なぜあなたのビジネスロジックがアクションクリエーターになっていることがここで何らかの影響を与えるのでしょうか？ アプリケーションの状態を更新するのはレデューサーだけです。 したがって、作成されたアクションを再実行すると、どちらの方法でも同じ結果が得られます。

コードが変更された場合はどうなりますか？ レデューサーを変更すると、同じアクションが再生されますが、新しいレデューサーが使用されます。 一方、アクションクリエーターを変更すると、新しいバージョンは再生されません。 したがって、2つのシナリオを検討します。

レデューサー付き：

1）アプリでアクションを試します。
2）レデューサーにバグがあり、状態が間違っています。
3）レデューサーのバグを修正して保存します
4）タイムトラベルは新しいレデューサーをロードし、私を本来あるべき状態にします。

一方、アクションクリエーターの場合

1）アプリでアクションを試します。
2）アクション作成者にバグがあり、間違ったアクションが作成される結果になります
3）アクションクリエーターのバグを修正して保存します
4）まだ正しくない状態にあるため、少なくともアクションを再試行する必要があります。完全に壊れた状態になった場合は、更新する必要があります。

一時的な無効状態は、場合によっては実際に回避できないものです。 結果整合性がある限り、通常は問題ありません。 また、アクションクリエーターまたはリデューサーにビジネスロジックが存在するかどうかに関係なく、状態が一時的に無効になる可能性があります。 それは副作用とあなたの店の詳細ともっと関係があります。

私のreduxの考え方は、ストアは常に有効な状態にあると主張していると思います。 レデューサーは常に有効な状態を取り、有効な状態を生成します。 一貫性のない状態を許可するように強制するのはどのような場合だと思いますか？

中断して申し訳ありませんが、無効で有効な状態とはどういう意味ですか
ここ？ データが読み込まれている、またはアクションが実行されているが、まだ完了していない外観
私にとっては有効な一時的な状態のようです。

Redux @bvaughnと@sompylasarの一時的な状態とはどういう意味ですか？ ディスパッチが終了するか、スローされます。 スローされた場合、状態は変化しません。

レデューサーにコードの問題がない限り、Reduxにはレデューサーロジックと一致する状態しかありません。 どういうわけか、ディスパッチされたすべてのアクションはトランザクションで処理されます。ツリー全体が更新されるか、状態がまったく変更されないかのどちらかです。

ツリー全体が更新されても適切な方法ではない場合（Reactがレンダリングできない状態など）、それはあなたが正しく仕事をしていないだけです:)

Reduxでは、現在の状態は、単一のディスパッチがトランザクション境界であると見なすことです。

ただし、同じトランザクションで2つのアクションを同期的にディスパッチしたいと思われる@winstonewertの懸念を理解しています。 actionCreatorが複数のアクションをディスパッチし、すべてのアクションが正しく実行されることを期待する場合があるためです。 2つのアクションがディスパッチされ、2番目のアクションが失敗した場合、最初のアクションのみが適用され、「一貫性がない」と見なすことができる状態になります。 @winstonewertは、2番目のアクションのディスパッチが失敗した場合に、2つのアクションをロールバックすることを望んでいる可能性があります。

@winstonewertここの内部フレームワークにそのようなものを実装しましたが、これまではます： //github.com/stample/atom-react/blob/master/src/atom/atom.js
また、レンダリングエラーを処理したかったのです。状態を正常にレンダリングできない場合は、UIがブロックされないように、状態をロールバックする必要がありました。 残念ながら、次のリリースまで、レンダリングメソッドがエラーをスローするとReactは非常に悪い仕事をするので、それほど有用ではありませんでしたが、将来的には役立つ可能性があります。

ミドルウェアとのトランザクションで、ストアが複数の同期ディスパッチを受け入れることができると確信しています。

ただし、レンダリングエラーが発生した場合に状態をロールバックできるかどうかはわかりません。通常、状態をレンダリングしようとすると、reduxストアはすでに「コミット」されているためです。 私のフレームワークには、レンダリングをトリガーし、最終的にレンダリングエラーをロールバックするために使用する「beforeTransactionCommit」フックがあります。

@gaearonこの種の機能をサポートする予定があるのか​​、

redux-batched-subscribeは実際のトランザクションを実行することを許可せず、レンダリングの数を減らすだけであるように私には思えます。 私が見ているのは、サブスクリプションリスナーが最後に一度だけ起動されたとしても、各ディスパッチの後にストアが「コミット」することです。

完全なトランザクションサポートが必要なのはなぜですか？ ユースケースを理解していないと思います。

@gaearonまだよくわかりませんが、 @ winstonewertの

アイデアは、 dispatch([a1,a2])を実行でき、a2が失敗した場合、a1がディスパッチされる前の状態にロールバックするというものです。

これまで、私は複数のアクションを同期的にディスパッチしており（たとえば、単一のonClickリスナー、またはactionCreatorで）、ディスパッチされているすべてのアクションの最後にのみレンダーを呼び出す方法として主にトランザクションを実装していましたが、これはredux-batched-subscribeプロジェクトによって別の方法で解決されました。

私のユースケースでは、トランザクションで実行するために使用したアクションは、ほとんどの場合、不要なレンダリングを回避するためのものでしたが、アクションは独立して意味があったため、2番目のアクションのディスパッチが失敗した場合でも、最初のアクションをロールバックしないと、一貫した状態が得られます（しかし、計画されたものではないかもしれません...）。 誰かが完全なロールバックが役立つユースケースを思い付くことができるかどうかは本当にわかりません

ただし、レンダリングが失敗した場合、レンダリングできない状態で進行を試みるのではなく、レンダリングが失敗しない最後の状態にロールバックしようとするのは意味がありませんか？

単純なレデューサーエンハンサーは機能しますか？ 例えば

const enhanceReducerWithTheAbilityToConsumeMultipleActions = (reducer =>
  (state, actions) => (typeof actions.reduce === 'function'
    ? actions.reduce(reducer, state)
    : reducer(state, actions)
  )
)

これで、配列をストアにディスパッチできます。 エンハンサーは個々のアクションをアンパックし、それを各レデューサーに送ります。

はい、存在します： https ：

ああ@gaearon私はそれを知りませんでした。 非常によく似たユースケースをさまざまな方法で解決しようとする2つの異なるプロジェクトがあることに気づきませんでした。

• https://github.com/tshelburne/redux-batched-actions
• https://github.com/tappleby/redux-batched-subscribe

どちらも不要なレンダリングを回避できますが、1つ目はバッチ処理されたすべてのアクションをロールバックし、2つ目は失敗したアクションのみを適用しません。

@gaearon痛い、それを見ないのは悪い。 ：フラッシュ：

アクションクリエーターは不純なコードを表します

私はおそらくほとんどの人ほどReduxを実際に体験したことはありませんが、一見したところ、「アクションクリエーターでより多くのことを行い、レデューサーでより少ないことを行う」ことに反対しなければなりません。会社。

Hacker Way： Fluxパターンが導入さWebアプリ開発の再考では、Fluxが発明されることにつながるまさに問題は命令型コードです。

この場合、I / Oを実行するアクションクリエーターはその命令型コードです。

私たちは仕事でReduxを使用していませんが、私が仕事をしている場所では、きめ細かいアクション（もちろん、すべてそれ自体で意味があります）を実行し、それらをバッチでトリガーしていました。 たとえば、メッセージをクリックすると、 OPEN_MESSAGE_VIEW 、 FETCH_MESSAGE 、 MARK_NOTIFICATION_AS_READ 3つのアクションがトリガーされます。

次に、これらの「低レベル」アクションは、ストア内に何らかの値を設定するための「コマンド」、「セッター」、または「メッセージ」にすぎないことがわかります。 このように続ければ、戻ってMVCを使用し、コードが単純になる可能性があります。

ある意味で、アクションクリエーターは不純なコードを表し、レデューサー（およびセレクター）は純粋なコードを表します。 Haskellの人々は、不純なコードを少なくし、より純粋なコードを使用する方がよいと考えてい

たとえば、私のサイドプロジェクト（Reduxを使用）では、webkitの音声認識APIを使用しています。 あなたが話すと、それはonresultイベントを発します。 2つの選択肢があります—これらのイベントはどこで処理されますか？

• アクションの作成者に最初にイベントを処理させてから、ストアに送信してもらいます。
• イベントオブジェクトをストアに送信するだけです。

私は2番目に行きました：生のイベントオブジェクトをストアに送信するだけです。

ただし、Redux dev-toolsは、プレーンでないオブジェクトがストアに送信されるときにそれを好まないようです。そこで、これらのイベントオブジェクトをプレーンオブジェクトに変換するために、アクションクリエーターにいくつかの小さなロジックを追加しました。 （アクションクリエーターのコードは非常に些細なものなので、間違いはありません。）

次に、レデューサーはこれらの非常に原始的なイベントを組み合わせて、話された内容のトランスクリプトを構築できます。 そのロジックは純粋なコード内にあるため、（レデューサーをホットリロードすることで）非常に簡単にライブで微調整できます。

@dtinthをサポートしたいと思います。 アクションは、これらのイベントにどのように反応したいかではなく、現実の世界から発生したイベントを表す必要があります。 特に、CQRSを参照してください。実際のイベントについてできるだけ多くの詳細をログに記録する必要があります。レデューサーは将来改善され、古いイベントを新しいロジックで処理する可能性があります。

@dtinth @ denis-sokolov私もあなたに同意します。 ところで、 redux-sagaプロジェクトを参照していたとき、actionCreatorsを成長させ、時間の経過とともにますます複雑にするという考えに反対していることを明確にできなかったかもしれません。

Redux-sagaプロジェクトも、 @ dtinthで説明していることを実行する試みですが、両方の発言には

たぶん、Redux sagaの議論につながる元の議論のこの時点を見ることができます： https ：

解決するユースケース

明らかなTodoCreatedイベントがあるTodoアプリがあると想像してください。 次に、アプリのオンボーディングをコーディングするようにお願いします。 ユーザーがToDoを作成したら、ポップアップで祝福する必要があります。

「不純な」方法：

これは@bvaughnが好むようです

function createTodo(todo) {
   return (dispatch, getState) => {
       dispatch({type: "TodoCreated",payload: todo});
       if ( getState().isOnboarding ) {
         dispatch({type: "ShowOnboardingTodoCreateCongratulation"});
       }
   }
}

このアプローチは、アクションクリエーターをアプリビューのレイアウトと高度に結合させるため、好きではありません。 actionCreatorは、決定を下すためにUI状態ツリーの構造を知っている必要があることを前提としています。

「生のイベントからすべてを計算する」方法：

これは@ denis-sokolov @ dtinthが好むように思われるものです：

function onboardingTodoCreateCongratulationReducer(state = defaultState, action) {
  var isOnboarding = isOnboardingReducer(state.isOnboarding,action);
  switch (action) {
    case "TodoCreated": 
        return {isOnboarding: isOnboarding, isCongratulationDisplayed: isOnboarding}
    default: 
        return {isOnboarding: isOnboarding, isCongratulationDisplayed: false}
  }
}

はい、おめでとうを表示する必要があるかどうかを知るレデューサーを作成できます。 ただし、ポップアップが表示されたことを示すアクションがなくても表示されるポップアップがあります。 私自身の経験では、それを実行している（そしてそれを実行しているレガシーコードをまだ持っている）ので、それを非常に明示的にする方が常に良いです。アクションDISPLAY_CONGRATULATIONが起動されない場合は、お祝いポップアップを表示しないでください。 明示的は、暗黙的よりも保守がはるかに簡単です。

簡略化された佐賀の方法。

redux-sagaはジェネレーターを使用しており、慣れていない場合は少し複雑に見えるかもしれませんが、基本的に単純化された実装では、次のように記述します。

function createTodo(todo) {
   return (dispatch, getState) => {
       dispatch({type: "TodoCreated",payload: todo});
   }
}

function onboardingSaga(state, action, actionCreators) {
  switch (action) {
    case "OnboardingStarted": 
        return {onboarding: true, ...state};
    case "OnboardingStarted": 
        return {onboarding: false, ...state};
    case "TodoCreated": 
        if ( state.onboarding ) dispatch({type: "ShowOnboardingTodoCreateCongratulation"});
        return state;
    default: 
        return state;
  }
}

佐賀は、イベントを受け取り、効果を生み出す可能性のあるステートフルな俳優です。 ここでは、それが何であるかを理解するために不純なレデューサーとして実装されていますが、実際にはredux-sagaプロジェクトには含まれていません。

ルールを少し複雑にします。

あなたが最初のルールの世話をするならば、それはすべてについてあまり明確ではありません。
上記の実装を見ると、オンボーディング中にToDoを作成するたびにお祝いポップアップが開くことがわかります。 ほとんどの場合、オンボーディング中に最初に作成されたToDoに対してのみ開き、すべてではないようにします。 また、ユーザーが最終的にオンボーディングを最初からやり直すことができるようにしたいと考えています。

オンボーディングがますます複雑になるにつれて、3つの実装すべてでコードが時間の経過とともにどのように乱雑になるかがわかりますか？

redux-sagaの方法

redux-sagaと上記のオンボーディングルールを使用すると、次のように記述できます。

function* onboarding() {
  while ( true ) {
    take(ONBOARDING_STARTED)
    take(TODO_CREATED)
    put(SHOW_TODO_CREATION_CONGRATULATION)
    take(ONBOARDING_ENDED)
  }
}

上記のソリューションよりもはるかに簡単な方法でこのユースケースを解決できると思います。 私が間違っている場合は、より簡単な実装を教えてください:)

あなたは不純なコードについて話しましたが、この場合、テイク/プット効果は実際にはデータであるため、Redux-sagaの実装に不純物はありません。 take（）が呼び出されると、実行されません。実行するエフェクトの記述子が返され、ある時点でインタープリターが起動するため、サガをテストするためのモックは必要ありません。 Haskellをやっている機能的な開発者なら、Free / IOモナドを考えてください。

この場合、次のことが可能になります。

• actionCreatorを複雑にすることを避け、 getStateに依存するようにします
• 暗黙的をより明確にする
• トランスバーサルロジック（上記のオンボーディングなど）をコアビジネスドメイン（todoの作成）に結合することは避けてください

また、解釈レイヤーを提供して、生のイベントをより意味のある高レベルのイベントに変換できるようにします（ELMがバブルアップ時にイベントをラップすることで行うのと少し似ています）。

例：

• 「TIMELINE_SCROLLED_NEAR-BOTTOM」は「NEXT_PAGE_LOADED」につながる可能性があります
• エラーコードが401の場合、「REQUEST_FAILED」は「USER_DISCONNECTED」につながる可能性があります。
• 「HASHTAG_FILTER_ADDED」は「CONTENT_RELOADED」につながる可能性があります

アヒルを使用してモジュラーアプリのレイアウトを実現する場合は、アヒルを結合しないようにすることができます。 佐賀がカップリングポイントになります。 アヒルは彼らの生の出来事を知っている必要があり、佐賀はこれらの生の出来事を解釈します。 これは、duck1プロジェクトを別のコンテキストで再利用しやすくするため、duck1がduck2のアクションを直接ディスパッチするよりもはるかに優れています。 ただし、カップリングポイントはactionCreatorsにもある可能性があり、これが今日ほとんどの人が行っていることであると主張する人もいるかもしれません。

@slorberこれは素晴らしい例です！ 各アプローチのメリットとデメリットを明確に説明するために時間を割いていただきありがとうございます。 （私はそれがドキュメントにあるべきだとさえ思います。）

私は以前、同様のアイデア（「ワーカーコンポーネント」と名付けました）を検討していました。 基本的に、これは何もレンダリングしない（ render: () => null ）が、イベント（たとえば、ストアから）をリッスンし、他の副作用をトリガーするReactコンポーネントです。 次に、そのワーカーコンポーネントがアプリケーションルートコンポーネント内に配置されます。 複雑な副作用を処理するもう1つのクレイジーな方法。 ：stuck_out_tongue：

私が寝ている間、ここでたくさんの議論がありました。

@winstonewert 、あなたはタイムトラベルとバグのあるコードの再生について良い点を挙げています。 特定の種類のバグ/変更はどちらの方法でもタイムトラベルでは機能しないと思いますが、全体的には正しいと思います。

@dtinth 、申し訳ありませんが、私はあなたのコメントのほとんどをフォローしていません。 アクションクリエーター/リデューサーの「アヒル」コードの一部は、データをフェッチする必要があるという点で、不純である必要があります。 それを超えて、あなたは私を失いました。 私の最初の投稿の主な目的の1つは、実用主義の1つにすぎませんでした。

@winstonewertは、「reduxの私の考え方は、ストアが常に有効な状態にあることを主張していると思います」と述べています。
@slorberは、「Redux @bvaughnと@sompylasarの一時的な状態とはどういう意味ですか？ディスパッチが終了するか、スローされます。スローされても、状態は変わりません。」

私たちはさまざまなことを考えていると確信しています。 「一時的な無効状態」と言ったとき、私は次のようなユースケースを参照していました。 たとえば、私と同僚は最近redux-searchをリリースしました。 この検索ミドルウェアは、検索可能なもののコレクションへの変更をリッスンし、検索のためにそれらに（再）インデックスを付けます。 ユーザーがフィルターテキストを指定すると、redux-searchはユーザーのテキストに一致するリソースuidのリストを返します。 したがって、次のことを考慮してください。

アプリケーションストアにいくつかの検索可能なオブジェクトが含まれていると想像してください： [{id: 1, name: "Alex"}, {id: 2, name: "Brian"}, {id: 3, name: "Charles"}] 。 ユーザーがフィルターテキスト「e」を入力したため、検索ミドルウェアにはID 1と3の配列が含まれています。ユーザー1（Alex）が、ローカルでのユーザーアクションまたはリモートデータの更新に応じて削除されたとします。そのユーザーレコードは含まれなくなりました。 レデューサーがユーザーコレクションを更新した時点で、ストアは一時的に無効になります。これは、redux-searchがコレクションに存在しなくなったIDを参照するためです。 ミドルウェアが再度実行されると、無効な状態が修正されます。 この種のことは、ツリーの1つのノードが別のノードに関連付けられているときにいつでも発生する可能性があります。

@slorber氏は、「このアプローチは、アクションクリエーターをアプリビューのレイアウトと高度に結合させるため、好きではありません。actionCreatorは、決定を下すためにUI状態ツリーの構造を知っている必要があると想定しています。」

アクションクリエーターを「アプリビューのレイアウトに」結合するアプローチの意味がわかりません。 状態ツリーはUIを_ドライブ_（または通知）します。 これがFluxの主な目的の1つです。 そして、アクションクリエーターとリデューサーは、定義上、その状態と結合されます（ただし、UIとは結合されません）。

私が好むものとしてあなたが書いたサンプルコードの価値があるのは、私が考えていたようなものではありません。 多分私は自分自身を説明するのに貧弱な仕事をしました。 このようなことを議論することの難しさは、それが通常、単純な例や一般的な例では現れないことだと思います。 （たとえば、標準のTODO MVCアプリは、このような微妙な議論を行うには十分に複雑ではありません。）

最後の点を明確にするために編集。

ところで@slorberはここで私が考えていたものの例です。 少し工夫が凝らされています。

あなたの州に多くのノードがあるとしましょう。 それらのノードの1つは、共有リソースを格納します。 （「共有」とは、ローカルにキャッシュされ、アプリケーション内の複数のページからアクセスされるリソースを意味します。）これらの共有リソースには、独自のアクションクリエーターとリデューサー（「アヒル」）があります。 別のノードは、特定のアプリケーションページの情報を格納します。 あなたのページにも独自のアヒルがあります。

あなたのページが最新で最高のThingをロードし、ユーザーがそれを編集できるようにする必要があるとしましょう。 このような状況で使用する可能性のあるアクションクリエーターアプローチの例を次に示します。

import { fetchThing, thingSelector } from 'resources/thing/duck'
import { showError } from 'messages/duck'

export function fetchAndProcessThing ({ params }): Object {
  const { id } = params
  return async ({ dispatch, getState }) => {
    try {
      await dispatch(fetchThing({ id }))

      const thing = thingSelector(getState())

      dispatch({ type: 'PROCESS_THING', thing })
    } catch (err) {
      dispatch(showError(`Invalid thing id="${id}".`))
    }
  }
}

@winstonewertは、2番目のアクションのディスパッチが失敗した場合に、2つのアクションをロールバックすることを望んでいる可能性があります。

いいえ。2つのアクションをディスパッチするアクションクリエーターは作成しません。 2つのことを行う単一のアクションを定義します。 OPは、私が嫌う一時的な無効状態を許可する小さなアクションをディスパッチするアクションクリエーターを好むようです。

レデューサーがユーザーコレクションを更新した時点で、ストアは一時的に無効になります。これは、redux-searchがコレクションに存在しなくなったIDを参照するためです。 ミドルウェアが再度実行されると、無効な状態が修正されます。 この種のことは、ツリーの1つのノードが別のノードに関連付けられているときにいつでも発生する可能性があります。

これは実際に私を悩ませているようなケースです。 私の考えでは、インデックスは理想的にはレデューサーまたはセレクターによって完全に処理されるものです。 検索を最新の状態に保つために追加のアクションをディスパッチする必要があるのは、reduxの純粋な使用法ではないようです。

OPは、私が嫌う一時的な無効状態を許可する小さなアクションをディスパッチするアクションクリエーターを好むようです。

ではない正確に。 状態ツリーのアクション作成者のノードに関しては、単一のアクションを優先します。 ただし、単一の概念的なユーザー「アクション」が状態ツリーの複数のノードに影響を与える場合は、複数のアクションをディスパッチする必要があります。 各アクションを個別に呼び出すことも（私は_bad_だと思います）、単一のアクション作成者にアクションをディスパッチさせることもできます（redux-thunkの方法で、ビューレイヤーからその情報を隠すので_better_だと思います）。

これは実際に私を悩ませているようなケースです。 私の考えでは、インデックスは理想的にはレデューサーまたはセレクターによって完全に処理されるものです。 検索を最新の状態に保つために追加のアクションをディスパッチする必要があるのは、reduxの純粋な使用法ではないようです。

余分なアクションをディスパッチしていません。 検索はミドルウェアです。 自動です。 ただし、ツリーの2つのノードが一致しない場合、一時的な状態が存在します。

@bvaughnああ、そのような純粋主義者であることをお詫びします！

まあ、不純なコードはデータのフェッチやその他の副作用/ IOと関係がありますが、純粋なコードは副作用を引き起こすことはできません。 純粋なコードと不純なコードの比較については、この表を参照してください。

Fluxのベストプラクティスでは、アクションは「セッターではなく、ユーザーのアクションを説明する」必要があるとされています。 Fluxのドキュメントは、これらのアクションがどこから来るのかをさらに示唆しています。

新しいデータがシステムに入ると、アプリケーションを操作する人またはWeb API呼び出しを介し

基本的に、アクションは「何が起こったのか」を説明する事実/データであり、何が起こるべきかではありません。 ストアは、これらのアクションに同期的かつ予測可能にのみ反応でき、他の副作用はありません。 他のすべての副作用は、アクションクリエーター（またはsagas：wink :)で処理する必要があります。

例

これが最善の方法であるとか、他のどの方法よりも優れているとか、あるいは良い方法でさえあると言っているのではありません。 しかし、これは私が現在ベストプラクティスと考えているものです。

たとえば、ユーザーがリモートサーバーへの接続を必要とするスコアボードを表示したいとします。 何が起こるべきかは次のとおりです。

• ユーザーがスコアボードの表示ボタンをクリックします。
• スコアボードビューは、読み込みインジケーターとともに表示されます。
• スコアボードを取得するための要求がサーバーに送信されます。
• 応答を待ちます。
• 成功した場合は、スコアボードを表示します。
• 失敗した場合、スコアボードが閉じ、エラーメッセージを含むメッセージボックスが表示されます。 ユーザーはそれを閉じることができます。
• ユーザーはスコアボードを閉じることができます。

ユーザーのアクションまたはサーバーの応答の結果としてのみアクションがストアに到達できると仮定すると、5つのアクションを作成できます。

• SCOREBOARD_VIEW （ユーザーがスコアボードの表示ボタンをクリックした結果）
• SCOREBOARD_FETCH_SUCCESS （サーバーからの応答が成功した結果）
• SCOREBOARD_FETCH_FAILURE （サーバーからのエラー応答の結果として）
• SCOREBOARD_CLOSE （ユーザーが閉じるボタンをクリックした結果）
• MESSAGE_BOX_CLOSE （ユーザーがメッセージボックスの閉じるボタンをクリックした結果）

これらの5つのアクションは、上記のすべての要件を処理するのに十分です。 最初の4つのアクションは「アヒル」とは何の関係もないことがわかります。 すべてのアクションは、外の世界で何が起こったかを説明であり（ユーザーはこれを実行したい、サーバーはそう言っています）、どのレデューサーでも消費できます。 また、 MESSAGE_BOX_OPENアクションはありません。これは、「何が起こったのか」ではないためです（ただし、そうあるべきです）。

状態ツリーを変更する唯一の方法は、何が起こったかを説明するオブジェクトであるアクションを発行する—ReduxのREADME

彼らはこれらのアクションクリエーターと一緒に接着されています：

function viewScoreboard () {
  return async function (dispatch) {
    dispatch({ type: 'SCOREBOARD_VIEW' })
    try {
      const result = fetchScoreboardFromServer()
      dispatch({ type: 'SCOREBOARD_FETCH_SUCCESS', result })
    } catch (e) {
      dispatch({ type: 'SCOREBOARD_FETCH_FAILURE', error: String(e) })
    }
  }
}
function closeScoreboard () {
  return { type: 'SCOREBOARD_CLOSE' }
}

次に、ストアの各部分（レデューサーによって管理される）は、次のアクションに反応できます。

| ストア/リデューサーの一部| 行動|
| --- | --- |
| スコアボードビュー| SCOREBOARD_VIEWでは可視性をtrueに更新し、 SCOREBOARD_CLOSEとSCOREBOARD_FETCH_FAILUREではfalseに更新します|
| scoreboardLoadingIndicator | 上trueに更新視界SCOREBOARD_VIEWで、偽SCOREBOARD_FETCH_* |
| スコアボードデータ| SCOREBOARD_FETCH_SUCCESSストア内のデータを更新する|
| messageBox | 可視性をtrueに更新し、メッセージをSCOREBOARD_FETCH_FAILUREに保存し、可視性をMESSAGE_BOX_CLOSEにfalseに更新します|

ご覧のとおり、1つのアクションがストアの多くの部分に影響を与える可能性があります。 ストアには、コマンド（何をすべきか）ではなく、アクション（何が起こったのか）の高レベルの説明のみが与えられます。 結果として：

1. エラーを特定する方が簡単です。

メッセージボックスの状態に影響を与えるものはありません。 なんらかの理由で開くように指示することはできません。 サブスクライブされているもの（ユーザーアクションとサーバー応答）にのみ反応します。

たとえば、サーバーがスコアボードのフェッチに失敗し、メッセージボックスが表示されなかった場合、 SHOW_MESSAGE_BOXアクションがディスパッチされない理由を調べる必要はありません。 メッセージボックスがSCOREBOARD_FETCH_FAILUREアクションを適切に処理しなかったことが明らかになります。

修正は簡単で、ホットリロードしてタイムトラベルすることができます。

1. アクションクリエーターとリデューサーは別々にテストできます。

アクションクリエーターが、ストアがそれらにどのように反応するかに関係なく、外の世界で何が起こっているかを正しく説明したかどうかをテストできます。

同様に、レデューサーは、外界からのアクションに適切に反応するかどうかを簡単にテストできます。

（統合テストは依然として非常に役立ちます。）

心配ない。 :)私はさらなる説明に感謝します。 実際、ここで同意しているように聞こえます。 アクションクリエーターの例viewScoreboardを見ると、そのすぐ上にあるアクションクリエーターの例fetchAndProcessThingによく似ています。

アクションクリエーターとリデューサーは別々にテストできます。

私はこれに同意しますが、それらを一緒にテストする方がより実用的な意味を持つことが多いと思います。 アクション_または_またはレデューサー（おそらく両方）のいずれかが非常に単純である可能性が高いため、単純なものを単独でテストすることによる労力の見返りの価値はやや低くなります。 そのため、アクションクリエーター、レデューサー、および関連するセレクターを一緒に（「アヒル」として）テストすることを提案しました。

ただし、単一の概念的なユーザー「アクション」が状態ツリーの複数のノードに影響を与える場合は、複数のアクションをディスパッチする必要があります。

それこそが、あなたがしていることは、reduxのベストプラクティスと考えられていることとは異なると私が思うところです。 標準的な方法は、状態ツリーの複数のノードが応答する1つのアクションを持つことだと思います。

ああ、興味深い観察@winstonewert。 私たちは、「アヒル」バンドルごとに一意の型定数を使用するパターンに従っています。したがって、拡張すると、リデューサーは、兄弟のアクション作成者によってディスパッチされたアクションにのみ応答します。 正直なところ、最初は、アクションに応答する任意のレデューサーについてどのように感じているのかわかりません。 それは少し悪いカプセル化のように感じます。

「アヒル」バンドルごとに一意のタイプ定数を使用するパターンに従っています。

ドキュメントのどこにもそれを推奨していないことに注意してください;-)悪いと言っているわけではありませんが、Reduxについて時々間違った考えを人々に与えます。

したがって、拡張すると、レデューサーは、兄弟のアクション作成者によってディスパッチされたアクションにのみ応答します。

Reduxにはレデューサー/アクションクリエーターのペアリングのようなものはありません。 それは純粋にアヒルのことです。 一部の人々はそれを好きですが、それはRedux / Fluxモデルの基本的な強みを覆い隠します：状態の突然変異はお互いからそしてそれらを引き起こすコードから切り離されています。

正直なところ、最初は、アクションに応答する任意のレデューサーについてどのように感じているのかわかりません。 それは少し悪いカプセル化のように感じます。

カプセル化の境界と見なすものによって異なります。 アクションはアプリ内でグローバルであり、それで問題ないと思います。 複雑な製品要件のために、アプリの一部が別の部分のアクションに反応したい場合がありますが、これは問題ないと考えています。 結合は最小限です。依存するのは文字列とアクションオブジェクトの形状だけです。 利点は、アクションクリエーターとの大量の配線を作成することなく、アプリのさまざまな部分にアクションの新しい派生を簡単に導入できることです。 コンポーネントは、アクションがディスパッチされたときに正確に何が起こるかを認識しません。これは、レデューサー側で決定されます。

したがって、私たちの公式の推奨事項は、最初に異なるレデューサーが同じアクションに応答するようにすることです。 それが厄介になった場合は、確かに、別々のアクションクリエーターを作成してください。 しかし、このアプローチから始めないでください。

セレクターを使用することをお勧めします。実際、状態から読み取る関数（「セレクター」）をレデューサーと一緒にエクスポートし、コンポーネントの状態構造をハードコーディングするのでmapStateToPropsなく、常に再選択を使用できます（ただし、使用する必要はありません）が、 shopping-cart例のように単純にセレクターを実装することもできます。

おそらく、それはあなたが命令型または反応型のどちらでプログラミングするかに要約されます。 アヒルを使用すると、アクションとレデューサーが高度に結合される可能性があり、より必須のアクションが促進されます。

• 命令型では、ストアには「何をすべきか」が与えられます。例： SHOW_MESSAGE_BOXまたはSHOW_ERROR
• リアクティブスタイルでは、ストアには「何が起こったかの事実」が与えられます（例： DATA_FETCHING_FAILEDまたはUSER_ENTERED_INVALID_THING_ID 。 ストアはそれに応じて反応します。

前の例では、 SHOW_MESSAGE_BOXアクションまたはshowError('Invalid thing id="'+id+'"')アクションクリエーターはありません。これは事実ではないためです。 それはコマンドです。

そのファクトがストアに入ると、そのファクトを純粋なレデューサー内のコマンドに変換できます。

// type Command = State → State
// :: Action → Command
function interpretAction (action) {
  switch (action.type) {
  case 'DATA_FETCHING_FAILED':
    return showErrorMessage('Data fetching failed')
    break
  case 'USER_ENTERED_INVALID_THING_ID':
    return showErrorMessage('User entered invalid thing ID')
    break
  case 'CLOSE_ERROR_MESSAGE':
    return hideErrorMessage()
    break
  default:
    return doNothing()
  }
}

// :: (State, Action) → State
function errorMessageReducer (state, action) {
  return interpretAction(action)(state)
}

const showErrorMessage = message => state => ({ visible: true, message })
const hideErrorMessage = () => state => ({ visible: false })
const doNothing = () => state => state

アクションが「コマンド」ではなく「ファクト」としてストアに入力された場合、それが失敗する可能性は低くなります。なぜなら、それは事実だからです。

これで、レデューサーがその事実を誤って解釈した場合、それは簡単に修正でき、修正は時間の経過とともに進む可能性があります。 ただし、アクションクリエーターがその事実を誤って解釈した場合は、アクションクリエーターを再実行する必要があります。

USER_ENTERED_INVALID_THING_ID発生したときに、ThingIDテキストフィールドがリセットされるようにレデューサーを変更することもできます。 そして、その変化は時間とともに伝わります。 ページを更新せずに、エラーメッセージをローカライズすることもできます。 これにより、フィードバックループが強化され、デバッグと調整がはるかに簡単になります。

（私は、ここに長所について話しています、もちろん短所があります。あなたがより多くのお店が唯一の同期これらの事実にと副作用なしで応答。見ることができることを考えると、その事実を表現する方法について多くのことを考える必要があるについて議論を代替の非同期/副作用モデルと私がStackOverflowに投稿したこの質問。私たちはまだその部分を釘付けにしていないと思います。）

正直なところ、最初は、アクションに応答する任意のレデューサーについてどのように感じているのかわかりません。 それは少し悪いカプセル化のように感じます。

複数のコンポーネントが同じストアからデータを取得することも非常に一般的です。 また、単一のコンポーネントがストアの複数の部分からのデータに依存することもよくあります。 それもカプセル化が悪いように聞こえませんか？ 真にモジュール化するには、Reactコンポーネントも「ダック」バンドル内に含めるべきではありませんか？ （ Elmアーキテクチャはそれを行います。）

Reactは、ストアからのデータをファクトとして扱うことで

同様に、Redux / Fluxは、アクションをファクトとして扱うことで

時間を割いてあなたの考えを書き、共有してくれてありがとう、@ dtinth。 また、この議論に参加してくれた

複数のコンポーネントが同じストアからデータを取得することも非常に一般的です。 また、単一のコンポーネントがストアの複数の部分からのデータに依存することもよくあります。 それもカプセル化が悪いように聞こえませんか？

ええと...これのいくつかは主観的ですが、違います。 エクスポートされたアクションクリエーターとセレクターは、モジュールのAPIだと思います。

とにかく、これは良い議論だったと思います。 タイ人が以前の回答で述べたように、私たちが議論しているこれらのアプローチには賛否両論があります。 他のアプローチへの洞察を得るのは素晴らしいことです。 :)

ちなみに、メッセージボックスは、表示用に別のアクションクリエーターを用意したい場合の良い例です。 自動的に却下できるように作成された時間を渡したいからです（そしてアクションクリエーターはあなたが不純なDate.now()と呼ぶところです）、それを却下するタイマーを設定したいので、私はそのタイマーなどをデバウンスしたいので、メッセージボックスの「アクションフロー」が個人的なアクションを正当化するのに十分重要である場合を考えます。 そうは言っても、おそらく私が説明したことはhttps://github.com/yelouafi/redux-sagaによってよりエレガントに解決できるでしょう

私は最初にDiscordReactifluxチャットでこれを書きましたが、ここに貼り付けるように求められました。

私は最近、同じことについてよく考えています。 状態の更新は3つの部分に分かれているように感じます。

1. アクションの作成者には、更新の実行に必要な最小限の情報が渡されます。 つまり、現在の状態から計算できるものはすべてその中にあるべきではありません。
2. 更新を実行するために必要な情報について状態が照会されます（たとえば、ID XのTodoをコピーする場合は、コピーを作成できるようにID XのTodoの属性をフェッチします）。 これはアクションクリエーターで行うことができ、その情報はアクションオブジェクトに含まれます。 これにより、ファットアクションオブジェクトが生成されます。 または、レデューサー（シンアクションオブジェクト）で計算することもできます。
3. その情報に基づいて、純粋なレデューサーロジックが適用されて次の状態が取得されます。

ここで問題となるのは、アクションクリエーターに何を入れるか、レデューサーに何を入れるか、太いアクションオブジェクトと薄いアクションオブジェクトのどちらを選択するかです。 すべてのロジックをアクションクリエーターに配置すると、基本的に状態の更新を宣言するファットアクションオブジェクトになります。 レデューサーは純粋になり、馬鹿になり、これを追加し、それを削除し、これらの関数を更新します。 それらは簡単に作成できます。 しかし、ビジネスロジックの多くはそこにありません。

レデューサーにより多くのロジックを配置すると、データロジックのほとんどが1つの場所にある、すてきで薄いアクションオブジェクトになりますが、他のブランチからの情報が必要になる可能性があるため、レデューサーを作成するのは困難です。 州の上位から追加の引数を取る大きなレデューサーまたはレデューサーになります。

これらの問題に対する答えが何であるかわからない、まだあるかどうかわからない

これらの考えを@tommikaikkonenと共有していただきありがとうございます。 私はまだ「答え」がここにあるかについて自分自身を決めていません。 私はあなたの要約に同意します。 「すべてのロジックをアクションクリエーターに入れる...」セクションに1つの小さなメモを追加します。これにより、データの読み取りに（共有）セレクターを使用できるようになります。

これは面白いスレッドです！ reduxアプリのどこにコードを配置するかを理解することは、私たち全員が直面している問題だと思います。 起こったことを記録するというCQRSのアイデアが好きです。
しかし、CQRSではアイデアの不一致が見られます。AFAIKのベストプラクティスは、ビューによって直接消費されるアクション/イベントから非正規化された状態を構築することです。 ただし、reduxのベストプラクティスは、完全に正規化された状態を構築し、セレクターを介してビューのデータを取得することです。
ビューによって直接消費できる非正規化状態を構築すると、レデューサーが別のレデューサーにデータを必要とするという問題はなくなると思います（各レデューサーは正規化を気にする必要のないすべてのデータを格納できるため）。 しかし、データを更新するときに他の問題が発生します。 多分これが議論の核心ですか？

長年のオブジェクト指向開発から来ています。Reduxは大きな後退のように感じます。 イベント（アクションクリエーター）とビジネスロジックをカプセル化するクラスを作成することを自分自身が懇願していることに気付きました。 私はまだ意味のある妥協点を見つけようとしていますが、現時点ではそれができていません。 他の誰かが同じように感じますか？

オブジェクト指向プログラミングでは、読み取りと書き込みを組み合わせることが推奨されます。 これにより、スナップショットとロールバック、集中ログ、誤った状態の変更のデバッグ、きめ細かい効率的な更新など、多くの問題が発生します。 これらが問題であると感じない場合、従来のオブジェクト指向MVCコードを記述しながらそれらを回避する方法を知っている場合、およびReduxがアプリで解決するよりも多くの問題を引き起こす場合は、Redux：wink：を使用しないでください。 。

@jayesbeオブジェクト指向プログラミングのバックグラウンドから来ているので、プログラミングの新しいアイデアと衝突することがあります。 これは、このテーマに関する多くの記事の1つです： https ：

アクションをデータ変換から分離することにより、ビジネスルールの適用のテストがより簡単になります。 変換は、アプリケーションのコンテキストへの依存度が低くなります。

これは、Javascriptでオブジェクトやクラスを放棄することを意味するものではありません。 たとえば、Reactコンポーネントはオブジェクトとして実装され、現在はクラスとして実装されています。 しかし、Reactコンポーネントは、提供されたデータの投影を作成するためだけに設計されています。 状態を保存しない純粋なコンポーネントを使用することをお勧めします。

そこでReduxが登場します。アプリケーションの状態を整理し、アクションとそれに対応するアプリケーションの状態の変換をまとめることです。

@johnsoftekリンクをありがとう。 しかし、過去10年間の私の経験に基づくと、私はそれに同意しませんが、ここでOOと非OOの間の議論に入る必要はありません。 私が抱えている問題は、コードの整理と抽象化です。

私の目標は、（構成値のみを使用して）数百のアプリを作成するために使用できる単一のアプリ/単一のアーキテクチャを作成することです。 私が対処しなければならないユースケースは、多くのクライアントによって使用されているホワイトラベルソフトウェアソリューションを処理することです。それぞれが独自のアプリケーションを呼び出します。

私は興味深い妥協案を思いついた。そしてそれは十分にうまく処理できると思うが、関数型プログラミングの群集の基準を満たしていないかもしれない。 私はまだそれをそこに出したいです。

サーバー側アプリケーションとのインターフェイスに必要なすべてのビジネスロジック、APIラッパーなどを含む単一のApplicationクラスがあります。

例..

export default Application {
    constructor(config) {
        this.config = config;
    } 

    config() {
        return this.config;
    }

    login(data, cb) {
        const url = [
            this.config.url,
            '?client=' + this.config.client,
            '&username=' + data.username,
            ....
        ].join('');

        fetch(url).then((responseText) => {
            cb(responseText);
        })
    }

    ... more business logic 
}

このオブジェクトの単一のインスタンスを作成し、Reduxプロバイダーを拡張してコンテキストに配置しました。

import { Provider } from 'react-redux';

export default class MyProvider extends Provider {
    getChildContext() {
        return Object.assign({}, Provider.prototype.getChildContext.call(this), {
            app: this.props.app
        });
    }

    render() {
        return this.props.children;
    }
}
MyProvider.childContextTypes = {
    store: React.PropTypes.object,
    app: React.PropTypes.object
}

それから私はこのプロバイダーをそのように使用しました

import Application from './application';
import config from './config';

class MyApp extends Component {
  render() {
    return (
      <MyProvider store={store} app={new Application(config)}>
        <Router />
      </MyProvider>
    );
  }
}

AppRegistry.registerComponent('MyApp', () => MyApp);

最後に、コンポーネントでアプリを使用しました。

class Login extends React.Component {
    render() {
        const { app } = this.context;
        const { state, actions } = this.props;
        return (
              <View style={style.transparentContainer}>
                <Form ref="form" type={User} options={options} />
                <Button 
                  onPress={() => {
                    value = this.refs.form.getValue();
                    if (value) {
                      app.login(value, actions.login);
                    }
                  }}
                >
                  Login
                </Button>
              </View>
        );
    }
};
Login.contextTypes = {
  app: React.PropTypes.object,
};

function mapStateToProps(state) {
  return {
      state: state.default.auth
  };
};

function mapDispatchToProps(dispatch) {
  return {
    actions: bindActionCreators(authActions, dispatch),
    dispatch
  };
}

export default connect(mapStateToProps, mapDispatchToProps)(Login);

したがって、Action Creatorは、私のビジネスロジックへの単なるコールバック関数です。

                      app.login(value, actions.login);

私は認証から始めたばかりですが、このソリューションは現時点ではうまく機能しているようです。

ストアをアプリケーションインスタンスに渡すこともできると思いますが、ストアに偶然の変化が発生したくないので、それはしたくありません。 ストアへのアクセスは便利かもしれませんが。 必要に応じて、それについてもっと考えます。

私は興味深い妥協案を思いついた。そしてそれは十分にうまく処理できると思うが、関数型プログラミングの群集の基準を満たしていないかもしれない。

ここには「機能的な群集」はありません：wink:。 Reduxで機能的なソリューションを選択する理由は、私たちが独断的であるためではなく、クラスのために人々がしばしば犯すいくつかの問題を解決するためです。 たとえば、レデューサーをアクションクリエーターから分離すると、バグのログ記録と再現に重要な読み取りと書き込みを分離できます。 プレーンオブジェクトであるアクションは、シリアル化可能であるため、記録と再生が可能です。 同様に、状態がMyAppStateインスタンスではなくプレーンオブジェクトであるため、サーバーでのシリアル化とクライアントでの逆シリアル化が非常に簡単になり、サーバーレンダリングのために、またはその一部をlocalStorage永続化できます。 レデューサーを関数として表現すると、タイムトラベルとホットリロードを実装でき、セレクターを関数として表現すると、メモ化を簡単に追加できます。 これらの利点はすべて、私たちが「機能的な群衆」であることとは関係がなく、このライブラリが解決するために作成された特定のタスクを解決することと関係があります。

このオブジェクトの単一のインスタンスを作成し、Reduxプロバイダーを拡張してコンテキストに配置しました。

これは私には完全に賢明に見えます。 私たちはクラスの不合理な憎しみを持っていません。 重要なのは、それらが厳しく制限されている場合（レデューサーやアクションオブジェクトなど）には使用したくないということですが、たとえば、アクションオブジェクトを生成するために使用することは問題ありません。

ただし、これは壊れやすいため、 Providerを拡張することは避けます。 その必要はありません。Reactはコンポーネントのコンテキストをマージするので、代わりにラップするだけです。

import { Component } from 'react';
import { Provider } from 'react-redux';

export default class MyProvider extends Component {
    getChildContext() {
        return {
            app: this.props.app
        };
    }

    render() {
        return (
            <Provider store={this.props.store}>
                {this.props.children}
            </Provider>
        );
    }
}
MyProvider.childContextTypes = {
    app: React.PropTypes.object
}
MyProvider.propTypes = {
    app: React.PropTypes.object,
    store: React.PropTypes.object
}

私の見解では、実際には読みやすく、壊れにくいです。

したがって、全体として、あなたのアプローチは完全に理にかなっています。 この場合のクラスの使用は、アクション作成者をパラメーター化する必要がある場合にも推奨されるパターンであるcreateActions(config)ようなものと実際には違いはありません。 何も悪いことはありません。

クラスインスタンスはシリアル化を非常にトリッキーにするため、状態オブジェクトとアクションオブジェクトにクラスインスタンスを使用することはお勧めしません。 レデューサーの場合、レデューサー構成、つまり他のレデューサーを呼び出すレデューサーを使用するのが難しくなるため、クラスの使用もお勧めしません。 それ以外の場合は、クラスを含む、コード編成の任意の手段を使用できます。

アプリケーションと構成が不変である場合（そして、そうあるべきだと思いますが、機能的なクールエイドを飲みすぎた可能性があります）、次のアプローチを検討できます。

const appSelector = createSelector(
   (state) => state.config,
   (config) => new Application(config)
)

そして、mapStateToPropsで：

function mapStateToProps(state) {
  return {
      app: appSelector(state)
  };
};

次に、採用したプロバイダー手法は必要ありません。状態からアプリケーションオブジェクトを取得するだけです。 再選択のおかげで、アプリケーションオブジェクトは、構成が変更されたときにのみ構築されます。これはおそらく1回だけです。

このアプローチに利点があると思うのは、アイデアを複数のそのようなオブジェクトを持つように簡単に拡張でき、それらのオブジェクトを状態の他の部分に依存させることもできるということです。 たとえば、構成と状態の一部の両方にアクセスできるlogin / logout / etcメソッドを持つUserControlクラスを作成できます。

したがって、全体として、あなたのアプローチは完全に理にかなっています。

：+1：ありがとうございます。 MyProviderの改善に同意します。 従うようにコードを更新します。 Reduxを最初に学んだときに私が抱えていた最大の問題の1つは、「アクションクリエーター」のセマンティックな概念でした。 私にとっては、ある種の気づきでした。これらは、ディスパッチされているイベントです。

@winstonewertはcreateSelectorがreact-nativeで利用できますか？ そうだとは思わない。 同時に、あるコンポーネントのmapStateToPropsにアタッチするたびに、新しいアプリケーションを作成しているように見えますか？ 私の目的は、アプリケーションにすべてのビジネスロジックを提供し、そのオブジェクトにグローバルにアクセスできるようにする単一のオブジェクトをインスタンス化することです。 あなたが提案がうまくいくかどうかはわかりません。 必要に応じて追加のオブジェクトを使用できるようにするというアイデアは気に入っていますが、技術的には、Applicationインスタンスを介して必要に応じてインスタンス化することもできます。

Reduxを最初に学んだときに私が抱えていた最大の問題の1つは、「アクションクリエーター」のセマンティックな概念でした。 私にとっては、ある種の気づきでした。これらは、ディスパッチされているイベントです。

Reduxにはアクションクリエーターのセマンティックな概念はまったくありません。 アクションのセマンティックな概念があります（これは、何が起こったかを説明し、イベントとほぼ同等ですが、完全ではありません。たとえば、＃351の説明を参照してください）。 アクションクリエーターは、コードを整理するための単なるパターンです。 同じタイプのアクションが一貫した構造を持ち、ディスパッチされる前に同じ副作用があることを確認したいので、アクション用のファクトリがあると便利です。しかし、Reduxの観点からは、アクションクリエーターは存在しません—Reduxアクションのみが表示されます。

createSelectorはreact-nativeで利用できますか？

これは、依存関係のないプレーンなJavaScriptであり、Web、ネイティブ、サーバーなどで機能するReselectで使用できます。

ああ。 はい、わかった。 物事ははるかに明確です。 乾杯。

mapStateToPropsおよびmapDispatchToPropsにオブジェクトをネストしないでください

最近、ReduxがmapStateToPropsとmapDispatchToPropsをマージするときにネストされたオブジェクトが失われるという問題に遭遇しました（reactjs / react-redux＃324を参照）。 @gaearonは、ネストされたオブジェクトを使用できるようにするソリューションを提供しますが、これはアンチパターンであると彼は続けます。

このようにオブジェクトをグループ化すると、不要な割り当てが発生し、結果の小道具が変更されたかどうかを判断する方法として結果の小道具の浅い同等性に依存できなくなるため、パフォーマンスの最適化が難しくなることに注意してください。 そのため、ドキュメントで推奨されている名前空間のない単純なアプローチよりも多くのレンダリングが表示されます。

@bvaughnは言った

レデューサーは愚かでシンプルでなければなりません

そして、ほとんどのビジネスロジックをアクションクリエーターに組み込む必要があります。私はそれに完全に同意します。 しかし、すべてがアクションに移行した場合でも、なぜレデューサーファイルと関数を手動で作成する必要があるのでしょうか。 アクションで操作したデータを直接保存してみませんか？

それは私をしばらく混乱させました...

レデューサーファイルと関数を手動で作成する必要があるのはなぜですか？

レデューサーは純粋関数であるため、状態更新ロジックにエラーがある場合は、レデューサーをホットリロードできます。 その後、開発ツールはアプリを初期状態に巻き戻し、新しいレデューサーを使用してすべてのアクションを再生できます。 これは、手動でロールバックしてアクションを再実行することなく、状態更新のバグを修正できることを意味します。 これは、状態更新ロジックの大部分をレデューサーに保持することの利点です。

これは、状態更新ロジックの大部分をレデューサーに保持することの利点です。

@dtinth明確にするために、「状態更新ロジック」とは「ビジネスロジック」を意味しますか？

あなたのロジックのほとんどをアクションクリエーターに入れるのが良い考えかどうかはわかりません。 すべてのレデューサーがADD_Xようなアクションを受け入れる些細な関数である場合、エラーが発生する可能性はほとんどありません。 しかし、その後、すべてのエラーがアクションクリエーターにプッシュされ、 @ dtinthがほのめかしている優れたデバッグエクスペリエンスが

しかし、 @ tommikaikkonenが述べたように、複雑なレデューサーを書くのはそれほど簡単ではありません。 私の直感は、Reduxのメリットを享受したい場合は、プッシュしたい場所です。それ以外の場合は、副作用をエッジにプッシュする代わりに、純粋関数をプッシュして、最も些細なタスクのみを処理し、ほとんどを残します。状態に満ちた地獄であなたのアプリの。 :)

@sompylasar 「ビジネスロジック」と「状態更新ロジック」は、

ただし、私自身の実装の詳細を理解するために、私のアクションは主にアクションへの入力のルックアップです。 実際、すべての「ビジネスロジック」をアプリケーションコンテキストに移動したため、すべてのアクションは純粋です。

例として..これは私の典型的なレデューサーです

export default function reducer(state = initialState, action = {}) {
  switch (action.type) {
    case 'FOO_REQUEST':
    case 'FOO_RESPONSE':
    case 'FOO_ERROR':
    case 'FOO_RESET':
      return {
        ...state,
        ...action.data
      }; 
    default:
      return state;
  }
}

私の典型的な行動：

export function fooRequest( res ) {
  return {
    type: 'FOO_REQUEST',
    data: {
        isFooing: true,
        toFoo: res.saidToFoo
    }
  };
}

export function fooResponse( res ) {
  return {
    type: 'FOO_RESPONSE',
    data: {
        isFooing: false,
        isFooed: true,
        fooData: res.data
    }
  };
}

export function fooError( res ) {
  return {
    type: 'FOO_ERROR',
    data: {
        isFooing: false,
        fooData: null,
        isFooed: false,
        fooError: res.error
    }
  };
}

export function fooReset( res ) {
  return {
    type: 'FOO_RESET',
    data: {
        isFooing: false,
        fooData: null,
        isFooed: false,
        fooError: null,
        toFoo: true
    }
  };
}

私のビジネスロジックは、コンテキストに格納されているオブジェクトで定義されています。

export default class FooBar
{
    constructor(store)
    {
        this.actions = bindActionCreators({
            ...fooActions
        }, store.dispatch);
    }

    async getFooData()
    {
        this.actions.fooRequest({
            saidToFoo: true
        });

        fetch(url)
        .then((response) => {
            this.actions.fooResponse(response);
        })
    }
}

上記のコメントをご覧になると、私も最善のアプローチに苦労していました。最終的に、ストアをアプリケーションオブジェクトのコンストラクターに渡し、この中心点ですべてのアクションをディスパッチャーに接続することで、リファクタリングと解決を行いました。 私のアプリケーションが知っているすべてのアクションがここに割り当てられます。

mapDispatchToProps（）をどこでも使用しなくなりました。 Reduxの場合、接続されたコンポーネントを作成するときにmapStateToPropsのみを使用するようになりました。 アクションをトリガーする必要がある場合は、コンテキストを介してアプリケーションオブジェクトからアクションをトリガーできます。

class SomeComponent extends React.Component {
    componentWillReceiveProps(nextProps) {
        if (nextProps.someFoo != this.props.someFoo) {
            const { app } = this.context;
            app.actions.getFooData();
        }
    }
}
SomeComponent.contextTypes = {
    app: React.PropTypes.object
};

上記のコンポーネントは、redux接続する必要はありません。 それでもアクションをディスパッチできます。 もちろん、コンポーネント内の状態を更新する必要がある場合は、接続されたコンポーネントに変換して、状態の変更が確実に伝達されるようにします。

これが私のコア「ビジネスロジック」を整理した方法です。 私の状態はバックエンドサーバーで実際に維持されているので、これは私のユースケースでは非常にうまく機能します。

「ビジネスロジック」をどこに保存するかは、実際にはあなた次第であり、それがどのようにユースケースに適合するかはあなた次第です。

@jayesbe次の部分は、レデューサーに「ビジネスロジック」がないことを意味します。さらに、状態構造は、レデューサーを介してストアに転送されるペイロードを作成するアクションクリエーターに移動しました。

    case 'FOO_REQUEST':
    case 'FOO_RESPONSE':
    case 'FOO_ERROR':
    case 'FOO_RESET':
      return {
        ...state,
        ...action.data
      }; 

export function fooRequest( res ) {
  return {
    type: 'FOO_REQUEST',
    data: {
        isFooing: true,
        toFoo: res.saidToFoo
    }
  };
}

@jayesbe私のアクションとレデューサーはあなたのものと非常に似ており、一部のアクションは引数としてプレーンネットワーク応答オブジェクトを受け取ります。応答データをアクションに処理し、最後に非常に単純なオブジェクトを戻り値として返し、に渡す方法のロジックをカプセル化しました。呼び出しdispatch（）を介したレデューサー。 あなたがしたのと同じように。 問題は、アクションがこのように記述されていて、アクションがほぼすべてを実行し、レデューサーの責任が非常に軽い場合、レデューサーがアクションオブジェクトを単純に拡散するだけの場合、データを転送して手動で保存する必要があるのはなぜですか？ Reduxはそれを自動的に投与するのは難しいことではありません。

必ずしも。 しかし、多くの場合、ビジネスプロセスの一部です
ビジネスルールに従ってアプリケーションの状態を更新する必要があります。
したがって、そこにビジネスロジックを配置する必要があるかもしれません。

極端な場合は、これを確認してください。
「同期RTSエンジンと非同期の物語」@ForrestTheWoods
https://blog.forrestthewoods.com/synchronous-rts-engines-and-a-tale-of-desyncs-9d8c3e48b2be

2016年4月5日午後5時54分、「JohnBabak」 [email protected]は次のように書いています。

これは、状態更新ロジックの大部分を
レデューサー。

@dtinth https://github.com/dtinth明確にするために、
「状態更新ロジック」とは「ビジネスロジック」のことですか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/reactjs/redux/issues/1171#issuecomment -205754910

@LumiaSaki複雑なロジックをアクションクリエーターに維持しながら、レデューサーをシンプルに保つというアドバイスは、Reduxを使用するための推奨される方法に反します。 Reduxの推奨パターンは逆です。レデューサーで複雑なロジックを維持しながら、アクションクリエーターをシンプルに保ちます。 もちろん、とにかくすべてのロジックをアクションクリエーターに自由に配置できますが、そうすることで、Reduxを使用している場合でも、Reduxパラダイムに従わなくなります。

そのため、Reduxはアクションからストアにデータを自動的に転送しません。 それはあなたがReduxを使うことになっている方法ではないからです。 Reduxは、意図した以外の方法での使用を容易にするために変更されることはありません。 もちろん、あなたはあなたのために働くことを絶対に自由に行うことができますが、Reduxがそれのために変わることを期待しないでください。

その価値のために、私は次のようなものを使用してレデューサーを作成します。

let {reducer, actions} = defineActions({
   fooRequest: (state, res) => ({...state, isFooing: true, toFoo: res.saidToFoo}),
   fooResponse: (state, res) => ({...state, isFooing: false, isFooed: true, fooData: res.data}),
   fooError: (state, res) => ({...state, isFooing: false, fooData: null, isFooed: false, fooError: res.error})
   fooReset: (state, res) => ({...state, isFooing: false, fooData: null, isFooed: false, fooError: null, toFoo: false})
})

defineActionsは、レデューサーとアクションクリエーターの両方を返します。 このようにして、些細なアクションクリエーターの作成に多くの時間を費やす必要がなく、更新ロジックをレデューサー内に保持するのが非常に簡単であることがわかります。

アクションクリエーターでロジックを維持することを主張する場合は、データを自分で自動化することに問題はありません。 あなたのレデューサーは関数であり、それはそれが望むことを何でもすることができます。 したがって、レデューサーは次のように単純にすることができます。

function reducer(state, action) {
    if (action.data) {
        return {...state, ...action.data}
   } else {
        return state;
   }
}

ビジネスロジックに関するこれまでのポイントを拡張すると、ビジネスロジックを次の2つの部分に分けることができると思います。

• 非決定論的部分。 この部分は、外部サービス、非同期コード、システム時間、または乱数ジェネレーターを利用します。 私の意見では、この部分はI / O関数（またはアクション作成者）によって最も適切に処理されます。 私はそれらをビジネスプロセスと呼んでいます。

ユーザーが実行ボタンをクリックでき、アプリをコンパイルして実行するIDEのようなソフトウェアについて考えてみます。 （ここでは、ストアを取得する非同期関数を使用していますが、代わりにredux-thunk使用できます。）

js export async function runApp (store) { try { store.dispatch({ type: 'startCompiling' }) const compiledApp = await compile(store) store.dispatch({ type: 'startRunning', app: compiledApp }) } catch (e) { store.dispatch({ type: 'errorCompiling', error: e }) } }

• 決定論的な部分。 この部分は完全に予測可能な結果を​​もたらします。 同じ状態と同じイベントが与えられた場合、結果は常に予測可能です。 私の意見では、この部分はレデューサーによって最もよく処理されます。 私はこれをビジネスルールと呼んでいます。

`` `js
'updeep'からuをインポートします

export const reducer = createReducer（{
// [アクション名]：action => currentState => nextState
startCompiling：（）=> u（{コンパイル：true}）、
errorCompiling：（{エラー}）=> u（{コンパイル：false、compileError：エラー}）、
startRunning：（{app}）=> u（{
実行中：（）=>アプリ、
コンパイル：false
}）、
stopRunning：（）=> u（{running：false}）、
destroyCompileError：（）=> u（{compileError：null}）、
//..。
}）
`` `

私は、この決定論的な土地にできるだけ多くのコードを入れるようにしていますが、レデューサーの唯一の責任は、入ってくるアクションを考慮して、アプリケーションの状態を一定に保つことであることを念頭に置いています。 これ以上何もない。 Reduxは単なる状態コンテナなので、それ以外はReduxの外で行います。

@dtinthすばらしい。https： //github.com/reactjs/redux/issues/1171#issuecomment-205782740の前の例は、 。 issues / 1171＃issuecomment -205888533-アクションクリエーターで状態の一部を構築し、それらをレデューサーに渡して更新を拡散することを提案します（このアプローチは私には間違っているように見えます、そして私はで指摘された同じことに同意しますhttps://github.com/reactjs/redux/issues/1171#issuecomment-205865840）。

@winstonewert

Reduxの推奨パターンは逆です。レデューサーで複雑なロジックを維持しながら、アクションクリエーターをシンプルに保ちます。

どうすればルーデューサーに複雑なロジックを配置し、それでもそれらを純粋に保つことができますか？

たとえば、fetch（）を呼び出してサーバーからデータをロードしている場合は、何らかの方法で処理します。 「複雑なロジック」を備えたレデューサーの例はまだ見ていません

@jayesbe ：ええと...「複雑」と「純粋」は直交しています。 レデューサー内で_本当に_複雑な条件付きロジックまたは操作を行うことができ、それが副作用のない入力の関数である限り、それでも純粋です。

複雑なローカル状態（投稿エディター、ツリービューなど）がある場合、または楽観的な更新などを処理する場合、レデューサーには複雑なロジックが含まれます。 それは本当にアプリに依存します。 複雑なリクエストがあるものもあれば、複雑な状態更新があるものもあります。 いくつかは両方を持っています:-)

@markerikson okロジックステートメントは1つですが、特定のタスクを実行しますか？ たとえば、1つのアクションがあり、ある場合には他の3つのアクションをトリガーするか、別の場合には2つの別個のアクションをトリガーします。 そのロジック+タスクの実行は、レデューサーで実行する必要があるようには聞こえません。

私の状態データ/モデル状態はサーバー上にあり、ビュー状態はデータモデルとは異なりますが、その状態の管理はクライアント上にあります。 私のデータモデルの状態は単にビューに渡されます。これが私のレデューサーとアクションを非常にスリムにしている理由です。

@jayesbe ：他のアクションのトリガーはレデューサーで行うべきだと誰も言ったことがないと思います。 そして実際、そうすべきではありません。 レデューサーの仕事は単に(currentState + action) -> newStateです。

複数のアクションを結び付ける必要がある場合は、サンクやサガのようなものでそれを実行して順番に起動するか、状態の変化をリッスンするか、ミドルウェアを使用してアクションをインターセプトして追加の作業を行います。

正直なところ、現時点での議論は少し混乱しています。

@markeriksonトピックは、「ビジネスロジック」とその

お気づきのように、本当に重要なのはあなたのために働くものです。 しかし、これが私があなたが尋ねた問題に取り組む方法です。

たとえば、fetch（）を呼び出してサーバーからデータをロードしている場合は、何らかの方法で処理します。 「複雑なロジック」を備えたレデューサーの例はまだ見ていません

レデューサーはサーバーから生の応答を受け取り、それで状態を更新します。 そうすれば、あなたが話している処理応答は私のレデューサーで行われます。 たとえば、リクエストがサーバーのJSONレコードをフェッチする場合があります。これは、レデューサーがローカルレコードキャッシュに保持します。

k個の論理ステートメントは1つですが、特定のタスクを実行しますか？ たとえば、1つのアクションがあり、ある場合には他の3つのアクションをトリガーするか、別の場合には2つの別個のアクションをトリガーします。 そのロジック+タスクの実行は、レデューサーで実行する必要があるようには聞こえません。

それはあなたがしていることに依存します。 明らかに、サーバーフェッチの場合、1つのアクションが別のアクションをトリガーします。 これは、推奨されるReduxの手順の範囲内です。 ただし、次のようなこともしている可能性があります。

function createFoobar(dispatch, state, updateRegistry) {
   dispatch(createFoobarRecord());
   if (updateRegistry) {
      dispatch(updateFoobarRegistry());
   } else {
       dispatch(makeFoobarUnregistered());
   }
   if (hasFoobarTemps(state)) {
      dispatch(dismissFoobarTemps());
   }
}

これは、Reduxを使用するための推奨される方法ではありません。 推奨されるReduxの方法は、これらの必要な変更をすべて引き起こす単一のCREATE_FOOBARアクションを使用することです。

@winstonewert ：

これは、Reduxを使用するための推奨される方法ではありません。 推奨されるReduxの方法は、これらの必要な変更をすべて引き起こす単一のCREATE_FOOBARアクションを使用することです。

指定された場所へのポインタがありますか？ よくある質問のページを調べていたときに思いついたのは、ダンから直接の「状況次第」だったからです。 http://redux.js.org/docs/FAQ.html#actions -multiple-actionsと、SOに関するDanによるこの回答を参照してください。

「ビジネスロジック」は実際にはかなり広い用語です。 「何かが起こったのか」、「これが起こった今、私たちは何をしているのか」、「これは有効ですか？」などの内容をカバーできます。 Reduxの設計に基づいて、これらの質問は状況に応じてさまざまな場所で回答できますが、「それは起こったのか」というのはアクションクリエーターの責任であり、「今何が起こったのか」はほぼ間違いなく削減者の責任です。

全体として、「ビジネスロジック」のこの_全体の質問_に対する私の見解は次のとおりです。_ に依存します」。 アクションクリエーターでリクエストの解析を実行する理由と、レデューサーで要求の解析を実行する理由があります。 レデューサーが単に「このオブジェクトを取得して私の状態に叩き込む」場合もあれば、レデューサーが非常に複雑な条件付きロジックである場合もあります。 アクションの作成者が非常に単純な場合もあれば、複雑な場合もあります。 プロセスのステップを表すために複数のアクションを連続してディスパッチすることが理にかなっている場合もあれば、すべてを表すために一般的な「THING_HAPPENED」アクションのみをディスパッチしたい場合もあります。

私が同意する唯一の厳格なルールについては、「アクションクリエーターの非決定論、レデューサーの純粋な決定論」です。 それは当然のことです。

それ以外？ あなたのために働く何かを見つけてください。 一貫性を保つ。 なぜあなたがそれを特定の方法でやっているのかを知ってください。 それと一緒に行きなさい。

「それは起こったのか」というのはアクションクリエーターの責任であり、「今何が起こったのか」はほぼ間違いなく削減者の責任だと思いますが。

そのため、副作用、つまり「今何を」の純粋でない部分をレデューサーに入れる方法について並行して議論があります。＃1528そして、次にディスパッチするアクションのように、何が起こるべきかを純粋に説明するだけです。

私が使用しているパターンは次のとおりです。

• 何をすべきか：アクション/アクションクリエーター
• 方法：ミドルウェア（たとえば、「非同期」アクションをリッスンし、APIオブジェクトを呼び出すミドルウェア）。
• 結果をどうするか：レデューサー

このスレッドの前半から、ダンの声明は次のとおりでした。

したがって、私たちの公式の推奨事項は、最初に異なるレデューサーが同じアクションに応答するようにすることです。 それが厄介になった場合は、確かに、別々のアクションクリエーターを作成してください。 しかし、このアプローチから始めないでください。

そのことから、推奨されるアプローチは、イベントごとに1つのアクションをディスパッチすることであると思います。 しかし、実際的には、うまくいくことをしてください。

@winstonewert ：Danは、「レデューサー構成」パターンを参照しています。つまり、「1つのレデューサーだけが聞いたアクションです」と「多くのレデューサーは同じアクションに応答できます」です。 ダンは、単一のアクションに応答する任意のレデューサーに非常に大きな関心を持っています。 他の人は、レデューサーとアクションが非常に緊密にバンドルされ、1つのレデューサーだけが特定のアクションを処理する「アヒル」アプローチのようなものを好みます。 したがって、その例は「複数のアクションを順番にディスパッチする」ことではなく、「レデューサー構造のいくつの部分がこれに応答することを期待している」かということです。

しかし、実際的には、うまくいくことをしてください。

：+1：

@sompylasarアクションに状態構造があると、自分のやり方のエラーがわかります。 状態構造をレデューサーに簡単にシフトして、アクションを単純化できます。 乾杯。

同じことだと私には思えます。

複数のレデューサーをトリガーして複数の状態変化を引き起こす単一のアクションがあるか、それぞれが単一のレデューサーをトリガーして単一の状態変化を引き起こす複数のアクションがあります。 複数のレデューサーがアクションに応答し、イベントが複数のアクションをディスパッチすることは、同じ問題の代替ソリューションです。

あなたが言及したStackOverflowの質問で、彼は次のように述べています。

アクションログは、ユーザーの操作の履歴にできるだけ近づけてください。 ただし、レデューサーの実装が難しい場合は、いくつかのアクションをいくつかに分割することを検討してください。UIの更新が、たまたま一緒になっている2つの別々の操作と考えられる場合。

私が見ているように、Danは、理想的な方法として、ユーザーの操作ごとに1つのアクションを維持することを推奨しています。 しかし、彼は実用的であり、それがレデューサーの実装を難しくするとき、彼はアクションの分割を支持します。

ここでは、似ているが多少異なるユースケースをいくつか視覚化しています。

1）アクションでは、特にcombineReducersを使用して各サブドメインを処理する個別のレデューサー関数を使用している場合は、状態の複数の領域を更新する必要があります。 あなたは：

• レデューサーAとレデューサーBの両方が同じアクションに応答し、状態のビットを個別に更新するようにします
• サンクにすべての関連データをアクションに詰め込んで、レデューサーが自身のチャンク外の他の状態ビットにアクセスできるようにします
• レデューサーAの状態のビットを取得する別のトップレベルのレデューサーを追加し、特別な場合はそれをレデューサーBに渡しますか？
• 必要な状態のビットを使用してレデューサーAを対象としたアクションをディスパッチし、必要なものを使用してレデューサーBを対象とした2番目のアクションをディスパッチしますか？

2）特定の順序で発生する一連のステップがあり、各ステップには状態の更新またはミドルウェアのアクションが必要です。 あなたは：

• 進捗状況を表す個別のアクションとして個々のステップをディスパッチし、個々のレデューサーが特定のアクションに応答できるようにしますか？
• 1つの大きなイベントをディスパッチし、レデューサーがそれを適切に処理することを信頼しますか？

そうですね、確かにいくつかの重複がありますが、ここでのメンタルイメージの違いの一部はさまざまなユースケースだと思います。

@markeriksonつまり、あなたのアドバイスは「遭遇した状況によって異なります」であり、アクションまたはレデューサーの「ビジネスロジック」のバランスをとる方法はあなたの検討次第です。純粋関数の利点も可能な限り

うん。 Reduxの要件として、レデューサーは純粋である必要があります（特別な場合の0.00001％を除く）。 アクションクリエーターは絶対に純粋である必要はありません。実際、ほとんどの「不純物」が存在する場所です。 ただし、純粋関数は純粋関数よりも明らかに理解とテストが容易であるため、アクション作成ロジックの一部を純粋で優れたものにすることができます。 そうでない場合は、それで問題ありません。

そして、はい、私の観点からは、開発者として、自分のアプリのロジックとその場所に適切なバランスを決定するのはあなた次第です。 アクションクリエーター/リデューサーのどちら側に分割するかについての単一の厳格なルールはありません。 （ええと、私が上で述べた「決定論/非決定論」のことを除いて。私は明らかにこのコメントで参照するつもりでした。明らかに。）

@cpsubrian

結果をどうするか：レデューサー

実際、これがサガの目的である理由です。「これが起こった場合、それも起こるはずです」などの影響に対処するため

@markerikson @LumiaSaki

アクションクリエーターは絶対に純粋である必要はなく、実際、あなたの「不純物」のほとんどが住む場所です。

実際、アクションクリエーターは、不純である必要も、存在する必要さえありません。
http://stackoverflow.com/a/34623840/82609を参照して

そして、はい、私の観点からは、開発者として、自分のアプリのロジックとその場所に適切なバランスを決定するのはあなた次第です。 アクションクリエーター/リデューサーのどちら側に分割するかについての単一の厳格なルールはありません。

はい。ただし、経験がなくても各アプローチの欠点に気付くのはそれほど明白ではありません:)ここにある私のコメントも参照してください： https ：

ほとんどの単純なアプリでは厳密なルールは適切に機能しませんが、再利用可能なコンポーネントを構築する場合、これらのコンポーネントは独自の範囲外の何かを認識してはなりません。

そのため、アプリ全体のグローバルアクションリストを定義する代わりに、アプリを再利用可能なコンポーネントに分割し始めることができます。各コンポーネントには独自のアクションリストがあり、これらをディスパッチ/削減することしかできません。 問題は、「日付ピッカーで日付を選択したら、そのToDoアイテムにリマインダーを保存し、フィードバックトーストを表示してから、リマインダー付きのToDoにアプリをナビゲートする必要がある」とどのように表現するかです。佐賀が行動を起こす：コンポーネントの調整

https://github.com/slorber/scalable-frontend-with-elm-or-reduxも参照して

そして、はい、私の観点からは、開発者として、自分のアプリのロジックとその場所に適切なバランスを決定するのはあなた次第です。 アクションクリエーター/リデューサーのどちら側に分割するかについての単一の厳格なルールはありません。

はい、ロジックをレデューサーに配置するかアクションクリエーターに配置するかは、Reduxからの要件はありません。 Reduxはどちらの方法でも壊れません。 いずれかの方法でそれを行うことを要求する厳格な規則はありません。 しかし、Danの推奨は、「アクションログをユーザーインタラクションの履歴にできるだけ近づける」ことでした。 ユーザーイベントごとに1つのアクションをディスパッチする必要はありませんが、推奨されます。

私の場合、1つのアクションに関心のある2つのレデューサーがあります。 生のaction.dataでは不十分です。 変換されたデータを処理する必要があります。 2つのレデューサーで変換を実行したくありませんでした。 そこで、変換を実行する関数をサンクに移動しました。 このようにして、私のレデューサーは消費の準備ができているデータを受け取ります。 これは、1か月の短いreduxの経験で私が考えることができる最高のものです。

コンポーネント/ビューをストアの構造から切り離すのはどうですか？ 私の目標は、ストアの構造に影響されるものはすべてレデューサーで管理することです。そのため、セレクターをレデューサーと同じ場所に配置するのが好きなので、コンポーネントはストアの特定のノードを取得する方法を実際に知る必要はありません。

これは、コンポーネントがアクションをディスパッチするときに、コンポーネントにデータを渡すのに最適です。逆の場合はどうでしょうか。

たとえば、Todoアプリで、Todoアイテムの名前を更新しているとしましょう。そのため、更新したいアイテムの部分を渡すアクションをディスパッチします。

dispatch(updateItem({name: <text variable>}));

、およびアクションの定義は次のとおりです。

const updateItem = (updatedData) => {type: "UPDATE_ITEM", updatedData}

これは、単純に実行できるレデューサーによって処理されます。

Object.assign({}, item, action.updatedData)

アイテムを更新します。

これは、同じアクションとレデューサーを再利用してTodoアイテムの小道具を更新できるため、非常に効果的です。

updateItem({description: <text variable>})

代わりに説明が変更されたとき。

しかし、ここでコンポーネントはTodoアイテムがストアでどのように定義されているかを知る必要があり、その定義が変更された場合、それに依存するすべてのコンポーネントでそれを変更することを覚えておく必要があります。これは明らかに悪い考えです。このシナリオの提案はありますか？

@dcoellarb

この種の状況での私の解決策は、Javascriptの柔軟性を利用して、定型的なものを生成することです。

だから私は持っているかもしれません：

const {reducer, actions, selector} = makeRecord({
    name: TextField,
    description: TextField,
    completed: BooleanField
})

makeRecordは、私の説明からレデューサー、アクションクリエーター、セレクターを自動的に作成する関数です。 これで定型文がなくなりますが、後でこのきちんとしたパターンに合わないことをする必要がある場合は、makeRecordの結果にカスタムのレデューサー/アクション/セレクターを追加できます。

tks @winstonewertボイラープレートを回避するアプローチが好きです。多くのモデルを使用するアプリでは、多くの時間を節約できることがわかります。 しかし、これがコンポーネントをストア構造からどのように分離するかはまだわかりません。つまり、アクションが生成された場合でも、コンポーネントは更新されたフィールドを渡す必要があります。つまり、コンポーネントは次の構造を知る必要があります。店でしょ？

@winstonewert @dcoellarb私の意見では、アクションペイロード構造は、レデューサーではなくアクションに属し、レデューサーの状態構造に明示的に変換される必要があります。 これらの構造が最初の単純さのために互いにミラーリングしているのは幸運な偶然です。 これらの2つの構造は、同じエンティティではないため、常に相互にミラーリングする必要はありません。

@sompylasarそうです、私はapi / restデータをストア構造に変換しますが、それでもストア構造を知っておく必要があるのはレデューサーとセレクターだけですか？ 私がそれらを同じ場所に配置する理由、私の問題は、後で変更することにした場合に備えて、ストアの構造を知る必要がないことを望んでいるコンポーネント/ビューにありますが、私の例で説明されているように、彼らは構造を知る必要があります更新する適切なデータを送信します。これを行うためのより良い方法が見つかりません:(。

@dcoellarbビューは、特定のタイプのデータの入力と考えることができます（文字列や数値などですが、フィールドを持つ構造化オブジェクト）。 このデータオブジェクトは、必ずしもストア構造を反映しているわけではありません。 このデータオブジェクトをアクションに入れます。 これは店舗構造とは関係ありません。 ストアとビューの両方をアクションペイロード構造と組み合わせる必要があります。

@sompylasarは理にかなっています、私はそれを試してみます、どうもありがとう!!!

redux-sagaを使用すると、アクションをより純粋にすることができることも付け加えておきます。 ただし、redux-sagaは非同期イベントの処理に苦労しているため、redux-sagaの代わりにRxJS（または任意のFRPライブラリ）を使用することで、このアイデアをさらに一歩進めることができます。 KefirJSを使用した例を次に示します： https ：

こんにちは@frankandrobot 、

redux-sagaは非同期イベントの処理に苦労しています

これはどういう意味ですか？ redux-sagaは、非同期イベントと副作用をエレガントな方法で処理するように作られていませんか？ https://github.com/reactjs/redux/issues/1171#issuecomment-167715393をご覧ください

@IceOnFireはありません。 前回redux-sagaドキュメントを読んだとき、複雑な非同期ワークフローを処理するのは困難です。 たとえば、次を参照してください： http ：
それは効果に何かを言った（まだ言う？）

複雑になり始めているので、残りの詳細は読者に任せます

それをFRPの方法と比較してください： //github.com/frankandrobot/rflux/blob/master/doc/06-sideeffects.md#a -more-complex-workflow
そのワークフロー全体が完全に処理されます。 （ほんの数行で追加できます。）さらに、 redux-sagaの長所のほとんどを得ることができます（すべてが純粋関数であり、ほとんどが簡単な単体テストです）。

前回これについて考えたとき、問題はredux-sagaであり、すべてが同期しているように見えるという結論に達しました。 単純なワークフローには最適ですが、複雑な非同期ワークフローの場合は、非同期を明示的に処理すると簡単になります...これがFRPの優れた点です。

こんにちは@frankandrobot 、

説明ありがとうございます。 あなたが言及した見積もりが表示されません。ライブラリが進化した可能性があります（たとえば、今まで見たことのないcancel効果が表示されます）。

2つの例（sagaとFRP）がまったく同じように動作している場合、大きな違いは見られません。1つはtry / catchブロック内の一連の命令であり、もう1つはストリーム上の一連のメソッドです。 ストリームの経験が不足しているため、sagaの例はさらに読みやすく、すべてのyield 1つずつテストできるため、テストしやすくなっています。 しかし、これはテクノロジーよりも私の考え方によるものだと確信しています。

とにかく、これに関する@yelouafiの意見を知りたいです。

@bvaughnここで説明しているのと同じテストで、アクション、レデューサー、セレクターをテストする適切な例を示していただけますか？

アクション、レデューサー、セレクターをテストする最も効率的な方法は、テストを作成するときに「アヒル」アプローチに従うことです。 つまり、それぞれに個別に焦点を当てる3セットのテストではなく、特定のアクション、レデューサー、およびセレクターのセットをカバーする1セットのテストを作成する必要があります。 これにより、実際のアプリケーションで何が起こるかをより正確にシミュレートし、費用対効果を最大限に高めることができます。

こんにちは@ morgs32😄

この問題は少し古く、しばらくReduxを使用していません。 Reduxサイトには、ライティングテストに関するセクションがありますので、チェックしてみてください。

基本的に私は、アクションとレデューサーのテストを個別に作成するよりも、次のように一緒に作成する方が効率的である可能性があることを指摘していました。

import configureMockStore from 'redux-mock-store'
import { actions, selectors, reducer } from 'your-redux-module';

it('should support adding new todo items', () => {
  const mockStore = configureMockStore()
  const store = mockStore({
    todos: []
  })

  // Start with a known state
  expect(selectors.todos(store.getState())).toEqual([])

  // Dispatch an action to modify the state
  store.dispatch(actions.addTodo('foo'))

  // Verify the action & reducer worked successfully using your selector
  // This has the added benefit of testing the selector also
  expect(selectors.todos(store.getState())).toEqual(['foo'])
})

これは、プロジェクトで数か月間Reduxを使用した後の私自身の観察でした。 公式の推奨ではありません。 YMMV。 👍

「アクションでより多くのことを行う-クリエーターでより少なく、レデューサーでより少ない」

アプリケーションがサーバーとクライアントであり、サーバーにビジネスロジックとバリデーターが含まれている必要がある場合はどうなりますか？
だから私はアクションをそのまま送信し、ほとんどの作業はサーバー側でレデューサーによって行われます...

まず、英語でごめんなさい。 しかし、私はいくつかの異なる意見を持っています。

私の選択はfatレデューサー、 thinアクションクリエーターです。

私のアクションクリエーターは、いくつかの__promiseミドルウェア__に基づいて__dispatch__アクション（async、sync、serial-async、parallel-async、parallel-async in for-loop）を実行します。

私のレデューサーは、ビジネスロジックを処理するために、多くの小さな状態スライスに分割されます。 combineReduersてそれらを組み合わせます。 reducerは__純粋関数__なので、簡単に再利用できます。 いつかangularJSを使用するかもしれませんが、同じビジネスロジックのサービスでreducerを再利用できると思います。 reducerに多くのラインコードがある場合は、より小さなレデューサーに分割したり、いくつかの関数を抽象化したりすることができます。

はい、 AがB, C依存することを意味するクロスステートケースがいくつかあります..そしてB, Cは非同期データです。 Aを埋めるか初期化するには、 B,Cを使用する必要があります。そのため、 crossSliceReducerを使用します。

__アクションクリエーターでより多くのことを行い、レデューサーでより少ないことを行う__について。

1. redux-thunkなどを使用する場合。ええ。 getState()で、アクションクリエーター内の完全な状態にアクセスできます。 これは選択です。 または、いくつかの__crossSliceReducer__を作成して、完全な状態にアクセスすることもできます。いくつかの状態スライスを使用して、他の状態を計算することもできます。

__ユニットテストについて__

reducerは__純粋関数__です。 したがって、テストするのは簡単です。 今のところ、他の部分よりも重要なので、レデューサーをテストするだけです。

action creatorsをテストするに

私はあなたに同意します@mrdulinそれは今私も行った方法です。

@mrdulinうん。 ミドルウェアは、不純なロジックを配置するのに適した場所のようです。
しかし、ビジネスロジックにとって、レデューサーは適切な場所のようには思えません。 最終的には、ユーザーの質問ではなく、ビジネスロジックに必要なものを表す複数の「合成」アクションが発生します。

はるかに簡単な選択は、ミドルウェアからいくつかの純粋関数/クラスメソッドを呼び出すことです。

middleware = (...) => {
  // if(action.type == 'HIGH_LEVEL') 
  handlers[action.name]({ dispatch, params: action.payload })
}
const handlers = {
  async highLevelAction({ dispatch, params }) {
    dispatch({ loading: true });
    const data = await api.getData(params.someId);
    const processed = myPureLogic(data);
    dispatch({ loading: false, data: processed });
  }
}

@bvaughn

これにより、変数の入力ミスが微妙な未定義の値につながる可能性が低くなり、ストアの構造の変更などが簡単になります。

メモ化やデータ変換を必要としない些細な状態であっても、どこでもセレクターを使用することに反対する私の場合：

• レデューサーの単体テストは、誤って入力された状態のプロパティをすでにキャッチするべきではありませんか？
• 店舗の構造の変更は、私の経験では発生しません。ほとんどの場合、プロジェクトの立ち上げ段階です。 後で、 state.stuff.item1をstate.stuff.item2変更すると、他の名前を実際に変更するのと同じように、コードを検索してどこでも変更できます。 これは一般的なタスクであり、特にIDEを使用している人にとっては簡単です。
• どこでもセレクターを使用することは、一種の空の抽象化です。 単純な状態に直接アクセスするというこの懸念を私は理解していませんでした。 確かに、このAPIを使用して状態にアクセスすることで一貫性が得られますが、単純さはあきらめます。

明らかにセレクターが必要ですが、それらを必須のAPIにするための他のいくつかの議論を聞きたいと思います。

実用的な観点から、私の経験の1つの正当な理由は、reselectやredux-sagaなどのライブラリがセレクターを利用して状態の一部にアクセスすることです。 これは私がセレクターに固執するのに十分です。

哲学的に言えば、私は常にセレクターを機能的な世界の「より良い方法」と見なしています。 また、Javaオブジェクトのパブリック属性にアクセスしないのと同じ理由で、Reduxアプリでサブステートに直接アクセスすることはありません。

@IceOnFire計算に費用がかからない場合、またはデータ変換が必要ない場合は、活用するものは何もありません。

ゲッターメソッドはJavaでは一般的な方法かもしれませんが、JSで直接POJOにアクセスすることも同様です。

@timotgl

ストアと他のreduxコードの間にAPIがあるのはなぜですか？

セレクターはレデューサーのクエリ（読み取り）パブリックAPIであり、アクションはレデューサーのコマンド（書き込み）パブリックAPIです。 レデューサーの構造は、その実装の詳細です。

セレクターとアクションは、レデューサー自体ではなく、UIレイヤーとsagaレイヤー（redux-sagaを使用している場合）で使用されます。

@sompylasarここであなたの見解に従うかどうかはありません

セレクターをレデューサーの「読み取り」APIとして考える方法を説明していますが、私の質問は、セレクターを最初に必須のAPIにすることを正当化するものでした（ライブラリではなく、プロジェクトのベストプラクティスとしてそれを強制する場合のように必須です）。設計）。

@timotglはい、セレクターは必須ではありません。 ただし、アプリコードの将来の変更に備えて、個別にリファクタリングできるようにすることをお勧めします。

• 特定の状態がどのように構造化され、どのように書き込まれるか（削減の懸念、1つの場所）
• その状態の一部がどのように使用されるか（UIと副作用の懸念、同じ状態の一部が照会される多くの場所）

ストア構造を変更しようとしているとき、セレクターがないと、影響を受ける状態の部分にアクセスするすべての場所を見つけてリファクタリングする必要があります。これは、単に見つけて-だけでなく、重要なタスクになる可能性があります。特に、セレクターを介さずにストアから直接取得した状態のフラグメントを渡す場合は、置き換えます。

@sompylasarご

これは潜在的に重要なタスクである可能性があります

これは有効な懸念事項です。私にとっては、コストのかかるトレードオフのように思えます。 そのような問題を引き起こした状態リファクタリングに出くわしたことはないと思います。 しかし、私は「セレクタースパゲッティ」に出くわしました。そこでは、状態の些細なサブピースごとにネストされたセレクターがかなりの混乱を引き起こしました。 結局のところ、この対策自体も維持する必要があります。 しかし、私はこれの背後にある理由を今よく理解しています。

@timotgl私が公に共有できる簡単な例：

export const PROMISE_REDUCER_STATE_IDLE = 'idle';
export const PROMISE_REDUCER_STATE_PENDING = 'pending';
export const PROMISE_REDUCER_STATE_SUCCESS = 'success';
export const PROMISE_REDUCER_STATE_ERROR = 'error';

export const PROMISE_REDUCER_STATES = [
  PROMISE_REDUCER_STATE_IDLE,
  PROMISE_REDUCER_STATE_PENDING,
  PROMISE_REDUCER_STATE_SUCCESS,
  PROMISE_REDUCER_STATE_ERROR,
];

export const PROMISE_REDUCER_ACTION_START = 'start';
export const PROMISE_REDUCER_ACTION_RESOLVE = 'resolve';
export const PROMISE_REDUCER_ACTION_REJECT = 'reject';
export const PROMISE_REDUCER_ACTION_RESET = 'reset';

const promiseInitialState = { state: PROMISE_REDUCER_STATE_IDLE, valueOrError: null };
export function promiseReducer(state = promiseInitialState, actionType, valueOrError) {
  switch (actionType) {
    case PROMISE_REDUCER_ACTION_START:
      return { state: PROMISE_REDUCER_STATE_PENDING, valueOrError: null };
    case PROMISE_REDUCER_ACTION_RESOLVE:
      return { state: PROMISE_REDUCER_STATE_SUCCESS, valueOrError: valueOrError };
    case PROMISE_REDUCER_ACTION_REJECT:
      return { state: PROMISE_REDUCER_STATE_ERROR, valueOrError: valueOrError };
    case PROMISE_REDUCER_ACTION_RESET:
      return { ...promiseInitialState };
    default:
      return state;
  }
}

export function extractPromiseStateEnum(promiseState = promiseInitialState) {
  return promiseState.state;
}
export function extractPromiseStarted(promiseState = promiseInitialState) {
  return (promiseState.state === PROMISE_REDUCER_STATE_PENDING);
}
export function extractPromiseSuccess(promiseState = promiseInitialState) {
  return (promiseState.state === PROMISE_REDUCER_STATE_SUCCESS);
}
export function extractPromiseSuccessValue(promiseState = promiseInitialState) {
  return (promiseState.state === PROMISE_REDUCER_STATE_SUCCESS ? promiseState.valueOrError || null : null);
}
export function extractPromiseError(promiseState = promiseInitialState) {
  return (promiseState.state === PROMISE_REDUCER_STATE_ERROR ? promiseState.valueOrError || true : null);
}

保存されているものがstate, valueOrErrorか、それとも他のものであるかは、このレデューサーユーザーの関心事ではありません。 公開されているのは、状態文字列（列挙型）、その状態、値、およびエラーについて頻繁に使用されるいくつかのチェックです。

しかし、私は「セレクタースパゲッティ」に出くわしました。そこでは、状態の些細なサブピースごとにネストされたセレクターがかなりの混乱を引き起こしました。

この入れ子がレデューサーの入れ子（構成）のミラーリングによって引き起こされた場合、それは私がお勧めするものではなく、それがレデューサーの実装の詳細です。 上記の例を使用すると、状態の一部にpromiseReducerを使用するレデューサーは、これらの部分に従って名前が付けられた独自のセレクターをエクスポートします。 また、セレクターのように見えるすべての関数をエクスポートして、レデューサーAPIの一部にする必要があるわけではありません。

function extractTransactionLogPromiseById(globalState, transactionId) {
  return extractState(globalState).transactionLogPromisesById[transactionId] || undefined;
}

export function extractTransactionLogPromiseStateEnumByTransactionId(globalState, transactionId) {
  return extractPromiseStateEnum(extractTransactionLogPromiseById(globalState, transactionId));
}

export function extractTransactionLogPromiseErrorTransactionId(globalState, transactionId) {
  return extractPromiseError(extractTransactionLogPromiseById(globalState, transactionId));
}

export function extractTransactionLogByTransactionId(globalState, transactionId) {
  return extractPromiseSuccessValue(extractTransactionLogPromiseById(globalState, transactionId));
}

ああ、私がほとんど忘れていたもう一つのこと。 関数名とエクスポート/インポートは、適切かつ安全に最小化できます。 ネストされたオブジェクトキー—それほど多くはありませんが、コードを台無しにしないために、ミニファイアに適切なデータフロートレーサーが必要です。

@timotgl ：Reduxで推奨されるベストプラクティスの多くは、Redux関連のロジックと動作をカプセル化することです。

たとえば、 this.props.dispatch({type : "INCREMENT"})実行することにより、接続されたコンポーネントから直接アクションをディスパッチできます。 ただし、コンポーネントがReduxと通信していることを「認識」するように強制するため、これはお勧めしません。 よりReactの慣用的な方法は、バインドされたアクションクリエーターを渡すことです。これにより、コンポーネントはthis.props.increment()呼び出すことができ、その関数がバインドされたReduxアクションクリエーターであるかどうかは関係ありません。コールバックが渡されます。親によるダウン、またはテストの模擬関数。

どこにでもアクションタイプを手書きすることもできますが、定数変数を定義して、それらをインポート、トレースし、タイプミスの可能性を減らすことをお勧めします。

同様に、 mapState関数またはサンクでstate.some.deeply.nested.fieldにアクセスすることを妨げるものは何もありません。 ただし、このスレッドですでに説明したように、これによりタイプミスの可能性が高まり、特定の状態が使用されている場所を追跡するのが難しくなり、リファクタリングがより困難になり、高価な変換ロジックがおそらく再実行されることを意味します-必要がなくても毎回実行します。

いいえ、セレクターを使用する必要はありませんが、セレクターは優れたアーキテクチャープラクティスです。

私の投稿「慣用的なRedux：カプセル化とパフォーマンスのための再選択セレクターの使用」をお読みください。

@markerikson私は一般的なセレクター、または高価な計算のためのセレクターに反対しているわけではありません。 そして、私はディスパッチ自体をコンポーネントに渡すつもりはありませんでした:)

私のポイントは、私がこの信念に同意しないということでした：

理想的には、レデューサー関数とセレクターのみが正確な状態構造を知っている必要があるため、一部の状態が存在する場所を変更した場合は、これら2つのロジックを更新するだけで済みます。

state.some.deeply.nested.fieldを使用した例については、これを短縮するためのセレクターを使用することの価値がわかります。 selectSomeDeeplyNestedField()は1つの関数名であるのに対し、5つのプロパティは間違っている可能性があります。

一方、この手紙のガイドラインに従うと、 const selectSomeField = state => state.some.field;またはconst selectSomething = state => state.something; 、ある時点でこれを一貫して実行するオーバーヘッド（インポート、エクスポート、テスト）が発生します。私の意見では、（議論の余地のある）安全性と純度はもはや正当化されません。 それは意味のあることですが、私はガイドラインの独断的な精神を振り払うことはできません。 私のプロジェクトの開発者は、セレクターを賢く、適切な場合に使用することを信頼します。これまでの私の経験では、セレクターを使用しているからです。

特定の条件下では、安全性と慣習の面で間違いを犯したいと思う理由がわかりました。 あなたの時間と関与に感謝します、私は私たちがreduxを持っていることを全体的に非常に嬉しく思います。

もちろん。 FWIWには、他のセレクターライブラリがあり、Reselectのラッパーもあります。 たとえば、 https：//github.com/planttheidea/selectoratorを使用すると、ドット表記のキーパスを定義でき、内部で中間セレクターを実行できます。