Redux: 状態ツリーのさまざまなブランチ間で依存状態を更新するためのベストプラクティスは？

申し訳ありませんが、私が発見した他のオプションは、カスタムrootReducerを使用することです。 技術的には、このレデューサーはルートにある必要はありません。 これは、相互に依存している状態ツリーの部分の最も低い共通祖先である可能性があります。

データが「より少ない」状態から計算できる場合は、その状態に保持しないでください。 派生データの計算で説明されているように、メモ化されたセレクターを使用します。

実際にそれができない場合は、（必要に応じて）追加のパラメーターをレデューサーに渡すか、その結果を使用できる単一のレデューサーを使用します。

function a(state, action) { }
function b(state, action, a) { } // depends on a's state

function something(state = {}, action) {
  let a = a(state.a, action);
  let b = b(state.b, action, a); // note: b depends on a for computation
  return { a, b };
}

そのスニペットを@gaearonに感謝します。 ウィジェットをreduxに移植しようとしたときに、私はすぐにこの問題に遭遇し、コミュニティが認可した解決策を見つけるためにしばらく時間を費やしました。 おそらくこれは、依存状態を持つことがかなり一般的であると私が想像するので、ドキュメント内でより目立つ可能性があるものです。

また、 combineReducers関数の内部で、状態ツリー全体をオプションの3番目のパラメーターとして渡すのは簡単なようです。 そうすることで、この問題が容易になりますが、reduxの経験が十分でなく、それが良いアイデアか悪いアイデアかを判断することはできません。 考え？

ドキュメントには独自のセクションがあるので、個人的にはかなり目立つと思います。 ：スマイル：

使用したくない場合は、 combineReducersする必要はありません。 これは便利なユーティリティですが、必須ではありません。 おそらく、 reduce-reducersまたはredux-actionsの方があなたのスタイルですか？

データが「より少ない」状態から計算できる場合は、その状態に保持しないでください。

ドキュメントには独自のセクションがあるので、個人的にはかなり目立つと思います。

わかりました、私はそれが最終的に私のためにクリックしたと思います。 ありがとう！

「データが「より少ない」状態から計算できる場合は、その状態で保持しないでください。」

アクションのペイロードと組み合わせた「より少ない」状態からのみデータを計算できる場合はどうなりますか？

各ブランチで相互に排他的な方法で処理できない単一のアクションの影響を解決するために状態ツリーのさまざまな部分が必要な場合は、 reduce-reducersを使用して、 combineReducerによって生成されたレデューサーを横断的なレデューサー：

export default reduceReducers(
  combineReducers({
    router: routerReducer,
    customers,
    stats,
    dates,
    filters,
    ui
  }),
  // cross-cutting concerns because here `state` is the whole state tree
  (state, action) => {
    switch (action.type) {
      case 'SOME_ACTION':
        const customers = state.customers;
        const filters = state.filters;
        // ... do stuff
    }
  }
);

@neverfoxありがとうございます！ まさに私が探していたもの。 結合されたレデューサーからルート状態にアクセスするか、何かを再構築する他の方法を知っていますか？

@imton

あなたの特定の例では、なぜ異なるレデューサーに同じアクションを処理させたくないのかわかりません。 それがReduxを使用するポイントです。 https://gist.github.com/imton/cf6f40578524ddd085dd#gistcomment-1656424を参照して

「横断的な」レデューサーは一般的に良い考えではないと思います。 それらは個々のレデューサーのカプセル化を破ります。 レデューサーの外部にある他のコードがそれに依存している可能性があるため、内部状態の形状を変更するのは困難です。

反対に、レデューサー自体を除いて、状態の形状に依存しないことをお勧めします。 レデューサーと同じファイルから「セレクター」（状態を照会する関数）をエクスポートすると、コンポーネントでさえ状態の形状に依存することを回避できます。 このアプローチのリポジトリのshopping-cart例を確認してください。

明確にするために、私は相互に排他的ではない場合、つまり、クロスカッティングレデューサーのみを提案していました。 同じアクションに応答する個別のレデューサーだけで処理することはできません。 たとえば、アクションが発生し、ツリーの1つのブランチ（通常はレデューサーAによって処理される）からいくつかのデータを取得し、別のブランチ（通常はレデューサーBによって処理される）からいくつかのデータを取得し、それらの組み合わせからいくつかの新しい状態データを導出する必要があります。両方（おそらく別の状態ブランチCに格納されます）。 状態の形状をリファクタリングしたり、データを複製したりする以外にこれを行う方法がある場合（これは常に実行可能または望ましいとは限りません）、アプリが成長して新しいときにそのような状況が頻繁に発生するため、私は確かに提案を受け入れます元の状態の設計には反映されなかった機能が付属しています。

派生データを計算するには、状態ツリーに格納するのではなく、セレクターを使用することをお勧めします。

http://redux.js.org/docs/recipes/ComputingDerivedData.html

それが州の一部である必要があるまで、これは素晴らしくて便利です。

「ニーズ」とはどういう意味ですか？ あなたが言及している特定のシナリオを説明できますか？

@gaearon 、次のシナリオについてのあなたの考えを聞いて興味があります...

パスワードフィールドにcharsを入力すると、 password状態プロパティに対して次の検証ルールが実行されます。

• 連続した文字が3つ以上ありますか？
• passwordスペースはありますか？
• usernameはpasswordですか？

上記のいずれかに該当する場合は、対応する特定のページレベルのエラーメッセージとともにページレベルのエラーが表示され、エラーによっては、フィールドレベルのエラーメッセージが表示される場合があります。

私はのために3つのレデューサー、各1を持っていますので、 usernameとpassword 、単純に文字列値を保持するために、そして1のためのnotification 、ページレベルのエラー通知処理するmessageおよびtype ：

// reducers/notifcation.js
import { ENTER_PASSWORD } from "../../actions/CreateAccount/types";
import strings from "../../../../example/CreateAccount/strings_EN";



const DEFAULT_STATE = {
  type: '',
  message: ''
};

export default (state = DEFAULT_STATE, action) => {
  const { value: password, type } = action;

  if (type === ENTER_PASSWORD) {
    const errors = strings.errors.password;
    let message;

    if (password.length <= 3) {
      message = errors.tooShort;
    } else if (password.indexOf(username) !== -1) {
      message = errors.containsUsername;
    } else if (password.indexOf(' ') !== -1) {
      message = errors.containsSpace;
    }

    if (message) {
      return {
        message,
        type: 'error'
      };
    }
  }
  return DEFAULT_STATE;
};

したがって、この場合、 notificationレデューサーはusernameとpasswordについて知る必要があります。 passwordアクセスできるのは、それを含むENTER_PASSWORDアクションタイプに関係しているためですが、現在整理されているため、 usernameとpassword取得できません。一緒にENTER_USERNAMEアクションタイプもチェックして、すでにpasswordを入力していることを確認してから、ユーザー名フィールドに戻ってusernameを変更する必要があります。 、次に、 passwordに更新されたusernameが含まれていないことを確認します...しかし、今はそれをスキップできます。

考え？

1つの解決策は、 usernameとpasswordをcredentialsとしてグループ化し、 ENTER_PASSWORDとENTER_USERNAMEアクションタイプを1つのENTER_CREDENTIALSマージすることです。

redux-formとそれがこのようなシナリオをどのように処理するかを見てください。 一般的に、ここよりもStackOverflowで質問する方が良いでしょう。 忙しいので、今は長い答えが出せません。

私はcombineSectionReducersを作成し
combineReducers 'のようにこれを解決します。

多分これについて何か知っていますか？ @gaearon https://github.com/omnidan/redux-undo/issues/102

ありがとう！

@gaearon @neverfoxとの話し合いは突然停止しましたが、彼の意味はわかっていると思います。同じ問題に遭遇しました。

combineReducersと状態ブランチchatおよびuiを使用して構成されたルートレデューサーがあるとします。 chat固有のレデューサーの内部では、アクションに反応する必要があります_（たとえば、サーバーから新しいメッセージを受信しました）_ ui部分からの状態に応じた方法で_（たとえば、新しいメッセージを追加します） msgsリストの最後がビューポートにある場合にのみmsgs-その情報はui部分に保持されます）_。 私たちは、から状態をアクセスもできませんui内部のブランチchat枝-したがって、それは、セレクタを使用することは不可能です。

私の頭に浮かんだ最初の解決策は、専用のサンクで条件付きの部分を実行し、その場所から2つの専用のアクションのいずれかをディスパッチすることでした。 ただし、これによりいくつかの追加の作成が導入されるため、何が起こっているのかがかなりわかりにくくなります。

このため、 @ neverfoxのソリューションが最もクリーンなソリューションだと思いますが、あなたが言ったように、カプセル化は破られます。 私が上でしたように問題を述べた後、あなたはこの問題について他の意見/解決策を持っていますか？

@jalooc ：Redux FAQは、 http： //redux.js.org/docs/FAQ.html#reducers-share-stateでこの問題について説明しています。

基本的に、主なオプションは「アクションでより多くのデータを渡す」または「Aから取得してBに渡すことを認識しているレデューサーロジックを作成する」です。 レデューサー中心のアプローチを選択した場合、 @ neverfoxのアプローチがそれを処理するための最良の方法であると

私はまた、＃1784で、レデューサーの構造化に関する新しいドキュメントのセットを作成している最中です。 新しいページの1つは、この概念に具体的に取り組んでいます- 「 combineReducers"超えて」 。

ドラフトドキュメントページとこのトピック全般について、さらにフィードバックをお寄せください。

ここで人々が言うことは何でも。 私は、人々が通常直面する問題は、彼らが理想的ではない方法で彼らの状態を設計するときだけであると強く疑っています。 状態ツリーのブランチ間に多くの依存関係がある場合、それ自体が重複データを示している可能性があり、「lesser」/「leaner」状態を使用できます。 React + Reduxプラットフォームは、あなたの手に計り知れないパワーと非常に決定論的なUIアップデートを提供します。 奇妙なUIの更新や2ウェイバインディングのループの問題に悩まされていない人は、おそらくこれを理解しないでしょう。 手に力が強いと、本質的に足を撃ちやすくなり、悪夢になり、みんなの痛みも感じます。 状態アーキテクチャの部分を正しく理解すると、他のすべてが簡単になります。 したがって、基本的には州の建築にもっと時間を費やす必要がありますが、その後はずっと利益を得ることができます。
また、リーン状態と通常の再計算を使用して、パフォーマンスの問題があるかどうかを最初に確認することを強くお勧めします。 非常に重要です。 再計算によるパフォーマンスの問題が発生した場合にのみ、再選択アプローチを使用してください（はい、再選択は段階的に適用できます、右@gaearon ？）。 私はアプローチを取り、再計算がまったく影響を及ぼさないことに気づきました。確かに起こるのではないかと心配していましたが、実際には影響しませんでした。一方、キーを押すたびにアイテムを並べ替えることができ、アプリは使用しなくても速く燃えるように感じます。再選択します。 多くの場合、再計算の手順について考えすぎる傾向がありますが、今日の平均的なプロセッサは、ほんの一瞬で数百、数千の種類を実行できることを忘れないでください。 実話。

誰かがこのアプローチを検討しましたか？ 落とし穴は何ですか？

const combinedReducers = combineReducers({
  dog: dogReducer,
  cat: catReducer
})

const stateInjectedReducers = (state, action) => {
  return {
    ...state,
    frog : frogReducer(state.frog, action, state) // frogReducer depends on cat state
  }
}

export default reduceReducers(combinedReducers, stateInjectedReducers)

安くて簡単ですが、他の場所から状態を注入する必要がある新しいレデューサーのためにstateInjectedReducersを書き直す必要がないので、私には魅力的です。

@funwithtriangles ：http://redux.js.org/docs/recipes/reducers/BeyondCombineReducers.htmlで話し、私のブログ投稿はhttp://blog.isquaredsoftware.com/2017/01/practical-reduxにあります。 -part-7-forms-editing-reducers / 。

@markeriksonは、私があまりクレイジーなことをしていないことを知ってうれしいです！ :)皮肉なことに、そのアプローチを思いついた後、 dog 、 cat 、およびfrog状態スライスが絡みすぎて、個別のレデューサーにできないと判断し、それらを1つにマージしました。 ！！ 😛

複数のレデューサーに同じアクションを尊重させてから、それぞれの状態ツリーでそれぞれの変更をトリガーするのは悪い習慣ですか？ これを行う必要がある場合も可能だと思います。これは、状態ツリーを誤って構造化したことを示している可能性がありますが、目的のために、2つの異なる状態があるとします。

const combinedReducers = combineReducers({
  a: aReducer,
  b: bReducer
})

そして、1回のディスパッチから両方の状態ツリーで状態変更をトリガーしたいとしました。 両方のレデューサーで同じアクションを尊重するのは悪い習慣ですか？ 必然的に、ディスパッチはとにかくcombinedReducers全体を通過し、最終的に両方のツリーで状態が変化します。 唯一の問題は、特定のアクションがさまざまな状態ツリーのトリガー変更であるかどうかを調べて確認する必要があることです（ただし、命名規則を使用してそれを処理できます）。

@augbogこれはまったく問題なく、Reduxで行うのが一般的なことですが、上記の説明とは実際には関係ありません。 この問題は、状態ツリーの他のブランチから状態にアクセスできるレデューサーに関するものです。

@augbog ：これはReduxの使用目的です。 詳細については、私のブログ投稿The Tao of Redux、Part 1-Implementation andIntentを参照してください。

別の角度-状態ツリーのルートにあるセレクターを使用して、状態のサブブランチからセレクターを呼び出して必要なデータを取得し、必要なデータ形状を返すことで、必要な特定のデータを取得します。

const selector = state => {
    const x = someSelectorForA(state.a);
    const y = someSelectorForB(state.b);
    return compute(x,y);
}

レデューサーはカプセル化されたままで、競合状態はなく、セレクターはうなり声を上げています。 いくつかの素晴らしい再帰パターンにつながる可能性があります。

状態ツリーのブランチを越えて到達したいときはいつでも、通常はセレクターを使用する必要があります。 私はこれらの原則に従うように一生懸命努力しています。

1. 状態ツリーには、状態ツリーの他の何かから派生したものを含めることはできません。
2. 派生データの計算にはセレクターを使用する必要があります。

フォームに関する限り、私にはストアに属するものが2つあります。

1. 検証ルール
2. ユーザー入力からのデータ（テキスト、ぼかし、その他のイベント）

次に、セレクターを使用して、2が1で定義されたルールに従うかどうかを計算します。レデューサーの状態ツリー全体に到達する理由はありません。

「フォームが有効かどうかを申請状態に反映させるべきではないかと思うこともありますが、それは重要なことのように思えます」。 しかし、それでも、それは国家が唯一の正しい情報源であるべきであるという原則に違反しています。 有効性が正しく計算されないバグがある場合、状態は内部的に矛盾します。 それは不可能なはずです。

セレクターは、結果が主要な場合でも、派生データを格納するのに最適な場所です。 計算された状態には多くの関心のあるサブスクライバーがいる可能性があるため、 @ gaearonが提案したようにメモ化されたセレクターを使用してください。

また、レデューサーがアクションを正しく解釈するために派生データのコンテキスト情報を必要とする場合は、それをディスパッチするときにアクションに含めることができます。

この問題の代わりに、redux-thunkを使用することもできます。 解決策は、中間アクションを使用して、現在の状態に基づいてより多くのコンテキスト認識アクションを実行することです。

function incrementIfOdd() {
  return (dispatch, getState) => {
    const { counter } = getState();

    if (counter % 2 === 0) {
      return;
    }

    dispatch(increment());
  };
}

このソリューションを使用すると、アクションとレデューサーの両方がダムのままになり、ロジックは中間レイヤーに移動し、ユーザーの操作と現在の状態に基づいて追加のチェックと推論を行います。

ドキュメントには独自のセクションがあるので、個人的にはかなり目立つと思います。

この引用とのリンクは壊れていますが、私はそれがこれを参照していると信じています： https ：

ただし、見直すと、このセクションは、それ以上ではないにしても、関連性があるように見えます： //redux.js.org/docs/recipes/reducers/BeyondCombineReducers.html

うん、そこに移動します。