Redux: レデューサーおよびコンポーネントエンハンサーとしてジェネリックリストを作成するにはどうすればよいですか？

これが良い例だと思います。
ReduxはここではElmArchitectureに似ているので、そこにある例から自由にインスピレーションを得てください。

あらゆる種類のエンティティを収集するために、一般化されたリストストア+コンポーネントをどのように作成しますか？ リストストア+コンポーネントをさらに一般化して、todomvc-exampleからカウンターとtodo-itemsの両方を取得することは可能でしょうか？

はい、間違いなく可能です。
高次のレデューサーと高次のコンポーネントを作成する必要があります。

高階レデューサーについては、こちらのアプローチを参照してください。

function list(reducer, actionTypes) {
  return function (state = [], action) {
    switch (action.type) {
    case actionTypes.add:
      return [...state, reducer(undefined, action)];
    case actionTypes.remove:
      return [...state.slice(0, action.index), ...state.slice(action.index + 1)];
    default:
      const { index, ...rest } = action;
      if (typeof index !== 'undefined') {
        return state.map(item => reducer(item, rest));
      }
      return state;
    }
  }
}

function counter(state = 0, action) {
  switch (action.type) {
  case 'INCREMENT':
    return counter + 1;
  case 'DECREMENT':
    return counter - 1;
  }
}

const listOfCounters = list(counter, {
  add: 'ADD_COUNTER',
  remove: 'REMOVE_COUNTER'
});

const store = createStore(listOfCounters);
store.dispatch({
  type: 'ADD_COUNTER'
});
store.dispatch({
  type: 'ADD_COUNTER'
});
store.dispatch({
  type: 'INCREMENT',
  index: 0
});
store.dispatch({
  type: 'INCREMENT',
  index: 1
});
store.dispatch({
  type: 'REMOVE_COUNTER',
  index: 0
});

（私はそれを実行していませんが、最小限の変更で動作するはずです。）

ありがとう-私はこのアプローチを機能させるように努めます。

combineReducersを介してリスト機能を再利用して、カウンターのリストとToDoアイテムのリストの両方を取得できるかどうかはまだ疑問です。 そしてそれが理にかなっているなら。 しかし、私は間違いなくそれを試してみます。

CombineReducersを介してリスト機能を再利用して、カウンターのリストとToDoアイテムのリストの両方を作成できるかどうかはまだ疑問です。 そしてそれが理にかなっているなら。 しかし、私は間違いなくそれを試してみます。

はい、完全に：

const reducer = combineReducers({
  counterList: list(counter, {
    add: 'ADD_COUNTER',
    remove: 'REMOVE_COUNTER'
  }),
  todoList: list(counter, {
    add: 'ADD_TODO',
    remove: 'REMOVE_TODO'
  }),
});

@gaearonリストアクションはどのようにindexを取得する必要がありますか？

私たちはあなたの指示で高次のレデューサーを作成することができましたが、高次のコンポーネントに苦労しています。 現在、私たちのコンポーネントは、Counter以外のコンポーネントで使用できるほど汎用的ではありません。 私たちの問題は、一般的な方法でアクションにインデックスを追加する方法です。

ここで私たちのソリューションを見ることができます： https ：//github.com/Zeikko/redux/commit/6a222885c8c93950dbdd0d4cf3532cd99a32206c

問題のある部分を強調するために、コミットにコメントを追加しました。

カウンターのリストのリストを実行できる一般的なリストリデューサー+コンポーネントがあると便利です。

現在、私たちのコンポーネントは、Counter以外のコンポーネントで使用できるほど汎用的ではありません。 私たちの問題は、一般的な方法でアクションにインデックスを追加する方法です。

「一般的な方法でインデックスを追加する」とはどういう意味ですか？ アクションのindexキーに異なる名前を付けたいということですか？

私はあなたが今意味することを理解していると思います。

申し訳ありませんが、今はあまりコメントできません。 明日また戻ります。

私は今問題を理解しています。 それを調べます。

ReduxがElmアーキテクチャからどのように逸脱するかに固有のいくつかの制限にすぐにぶつかりました。
今まで理解できなかったのが残念です！

• コンポーネントがラップされるまでに、コールバックではなくdispatchプロップを受け入れる必要があります。 つまり、アクションクリエーターを小道具にするのを避けて、構成されたコンポーネントでdispatch()を使用するか、 connect() bindActionCreators(Component, actionCreators) => Componentを導入する必要があります。ただし、実際にはストアに接続しません。代わりに、action-creator-as-props-wanting-componentをthis.props.dispatch -wanting-componentに置き換えます。
• ラップされたコンポーネントからミドルウェアを必要とするアクションをディスパッチすることはできません。 これは残念です！ カウンターをリストでラップすると、ディスパッチしたばかりのfunction (dispatch, getState) { ... }がリストによって{ action: function (dispatch, getState) { ... } }に変換されるため、$ incrementAsync()をディスパッチできなくなります。 サンクミドルウェアはそれを認識しなくなります。

これには厄介ではない解決策があるかもしれませんが、私はまだそれらを見ていません。
今のところ、このコミットを例として見てください（上記の制限があります）。

コードは次のとおりです。

components / Counter.js

import React, { Component, PropTypes } from 'react';
import { increment, incrementIfOdd, incrementAsync, decrement } from '../actions/counter';

class Counter extends Component {
  render() {
    const { dispatch, counter } = this.props;
    return (
      <p>
        Clicked: {counter} times
        {' '}
        <button onClick={() => dispatch(increment())}>+</button>
        {' '}
        <button onClick={() => dispatch(decrement())}>-</button>
        {' '}
        <button onClick={() => dispatch(incrementIfOdd())}>Increment if odd</button>
        {' '}
        <button onClick={() => dispatch(incrementAsync())}>Increment async</button>
      </p>
    );
  }
}

Counter.propTypes = {
  dispatch: PropTypes.func.isRequired,
  counter: PropTypes.number.isRequired
};

export default Counter;

components / list.js

import React, { Component, PropTypes } from 'react';
import { addToList, removeFromList, performInList } from '../actions/list';

export default function list(mapItemStateToProps) {
  return function (Item) {
    return class List extends Component {
      static propTypes = {
        dispatch: PropTypes.func.isRequired,
        items: PropTypes.array.isRequired
      };

      render() {
        const { dispatch, items } = this.props;
        return (
          <div>
            <button onClick={() =>
              dispatch(addToList())
            }>Add counter</button>

            <br />
            {items.length > 0 &&
              <button onClick={() =>
                dispatch(removeFromList(items.length - 1))
              }>Remove counter</button>
            }
            <br />
            {this.props.items.map((item, index) =>
              <Item {...mapItemStateToProps(item)}
                    key={index}
                    dispatch={action =>
                      dispatch(performInList(index, action))
                    } />
            )}
          </div>
        )
      }
    }
  };
}

アクション/counter.js

export const INCREMENT_COUNTER = 'INCREMENT_COUNTER';
export const DECREMENT_COUNTER = 'DECREMENT_COUNTER';

export function increment() {
  return {
    type: INCREMENT_COUNTER
  };
}

export function decrement() {
  return {
    type: DECREMENT_COUNTER
  };
}

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

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

    dispatch(increment());
  };
}

export function incrementAsync(delay = 1000) {
  return dispatch => {
    setTimeout(() => {
      dispatch(increment());
    }, delay);
  };
}

アクション/list.js

export const ADD_TO_LIST = 'ADD_TO_LIST';
export const REMOVE_FROM_LIST = 'REMOVE_FROM_LIST';
export const PERFORM_IN_LIST = 'PERFORM_IN_LIST';

export function addToList() {
  return {
    type: ADD_TO_LIST
  };
}

export function removeFromList(index) {
  return {
    type: REMOVE_FROM_LIST,
    index
  };
}

export function performInList(index, action) {
  return {
    type: PERFORM_IN_LIST,
    index,
    action
  };
}

レデューサー/counter.js

import { INCREMENT_COUNTER, DECREMENT_COUNTER } from '../actions/counter';

export default function counter(state = 0, action) {
  switch (action.type) {
  case INCREMENT_COUNTER:
    return state + 1;
  case DECREMENT_COUNTER:
    return state - 1;
  default:
    return state;
  }
}

レデューサー/list.js

import { ADD_TO_LIST, REMOVE_FROM_LIST, PERFORM_IN_LIST } from '../actions/list';

export default function list(reducer) {
  return function (state = [], action) {
    const {
      index,
      action: innerAction
    } = action;

    switch (action.type) {
    case ADD_TO_LIST:
      return [
        ...state,
        reducer(undefined, action)
      ];
    case REMOVE_FROM_LIST:
      return [
        ...state.slice(0, index),
        ...state.slice(index + 1)
      ];
    case PERFORM_IN_LIST:
      return [
        ...state.slice(0, index),
        reducer(state[index], innerAction),
        ...state.slice(index + 1)
      ];
    default:
      return state;
    }
  }
}

レデューサー/index.js

import { combineReducers } from 'redux';
import counter from './counter';
import list from './list'

const counterList = list(counter);

const rootReducer = combineReducers({
  counterList
});

export default rootReducer;

コンテナ/App.js

import { bindActionCreators } from 'redux';
import { connect } from 'react-redux';

import Counter from '../components/Counter';
import list from '../components/list';

const CounterList = list(function mapItemStateToProps(itemState) {
  return {
    counter: itemState
  };
})(Counter);

export default connect(function mapStateToProps(state) {
  return {
    items: state.counterList
  };
})(CounterList);

cc @acdlite —これは現在のミドルウェア+ ReactReduxの設計が多少壊れている例です。
これをwontfixとして宣言することはできますが、これを回避する方法があるかどうかを確認することをお勧めします。

だろう
https://github.com/erikras/multireducer/ヘルプ？

私はReact用のサービス（IoC）コンテナーの使用を実験しており、昨日このテストリポジトリを作成しました： https ：//github.com/magnusjt/react-ioc

CounterListが知らないうちに、アクションクリエーターをカウンターに渡すことができるので、問題の一部を解決できる可能性があると思います。 これが可能なのは、アクションの作成者が小道具ではなく、Counterのコンストラクターに入るからです。

作成する新しいCounterコンポーネントごとに、異なるアクションクリエーターを渡すことができます（おそらく、インデックス値をアクションクリエーターにバインドすることによって）。 もちろん、データをカウンターに渡すことにはまだ問題があります。 それがサービスコンテナで解決できるものかどうかはまだわかりません。

@gaearon 、あなたの例は私には正しいように見えます。 アクションクリエーターをパスして、最後までディスパッチする必要があります。 このようにして、高階関数を使用してアクションを祭壇に置くことができます。

ただし、2番目のポイントが必要かどうかはわかりません。 新しいメッセージ形式のためにミドルウェアを見逃すことになりますが、 performInListの大きな問題は、抽象化を1つのリストだけに制限していることです。 @ pe3は、カウンターのリストのリストについて言及しました。 そのような恣意的な抽象化のためには、何らかの形でアクションをネストする必要があると思います。

このチケットでは、タイプをネストする方法を考え出します。
https://github.com/rackt/redux/issues/897

しかし、もっと根本的には、アクションを完全にネストしたいと思うでしょう。

わかりました、私はちょうどそれを試してみました。

私は物事をかなり単純化しました。 これは、この派手なことをする前のカウンターアプリです：

https://github.com/ccorcos/redux-lifted-reducers/blob/80295a09c4d04654e6b36ecc8bc1bfac4ae821c7/index.js#L49

そしてここにそれは後です：

https://github.com/ccorcos/redux-lifted-reducers/blob/1fdafe8ed29303822018cde4973fda3305b43bb6/index.js#L57

「リフト」が適切な用語かどうかはわかりません。関数型プログラミングで何か意味があることは知っていますが、私には問題ないと感じました。

基本的に、アクションを解除することで、アクションを別のアクション内にネストすることになります。

const liftActionCreator = liftingAction => actionCreator => action => Object.assign({}, liftingAction, { nextAction: actionCreator(action) })

そして、ネストされたアクションは、レデューサーを持ち上げることによって剥がされます。 リフティングレデューサーは基本的に、サブリデューサー（適切なアクションで部分的に適用されます）をいくつかのサブステートに適用します。

const liftReducer = liftingReducer => reducer => (state, action) => liftingReducer(state, action)((subState) => reducer(subState, action.nextAction))

したがって、コンポーネントレデューサーのリストには、サブアクションが適用されるインデックスのコンポーネントを指定するアクションがあります。

// list actions
const LIST_INDEX = 'LIST_INDEX'
function actOnIndex(i) {
  return {
    type: LIST_INDEX,
    index: i
  }
}

そして、私は「高次」（ちょうど正しいと感じた別の派手な用語、ハハ;）レデューサーを持っています。これはサブレデューサーを適切なサブステートに適用します。

const list = (state=[], action) => (reduce) => {
  switch (action.type) {
    case LIST_INDEX:
      let nextState = state.slice(0)
      nextState[action.index] = reduce(nextState[action.index])
      return nextState
    default:
      return state;
  }
}

そして、残っているのは、カウントレデューサーをリストレデューサーに「持ち上げる」ことだけです。

const reducer = combineReducers({
  counts: liftReducer(list)(count)
});

そして、カウンターのリストについては、アクションをカウンターに渡すときにアクションを解除する必要があります。

class App extends Component {
  render() {
    const counters = [0,1,2,3,4].map((i) => {
      return (
        <Counter count={this.props.state.counts[i]}
                 increment={liftActionCreator(actOnIndex(i))(increment)}
                 decrement={liftActionCreator(actOnIndex(i))(decrement)}
                 dispatch={this.props.dispatch}
                 key={i}/>
      )
    })
    return (
      <div>
        {counters}
      </div>
    );
  }
}

これは適切な用語でより形式化できると思います。 ここでは高次レデューサーにもレンズが使えると思いますが、うまく使ったことがありません。

そして、最後のコメントで言ったことを取り戻します- @ gaearonは正しいです。 このようにアクションをネストすると、ミドルウェアを見逃すことになり、アクションクリエーターを操作できるように、ディスパッチを最後まで渡す必要があります。 おそらくこれをサポートするために、Reduxはミドルウェアを介してすべてのサブアクションを適用する必要があります。 また、別の問題は、リスト内の状態を初期化することです...

あなたが説明しているのはElmArchitectureとして知られています。 こちらをご覧ください： https ：//github.com/gaearon/react-elmish-example

おい、あなたはいつも一歩先を行っています！ クールなものへのリンクで私にシャワーを浴びてください：+1：

ラップされたコンポーネントからミドルウェアを必要とするアクションをディスパッチすることはできません。 これは残念です！ カウンターをリストでラップすると、関数（dispatch、getState）{...}が{action：function（dispatch、getState）{...}}に変換されるため、incrementAsync（）をディスパッチできなくなります。リスト—そしてバム！ サンクミドルウェアはそれを認識しなくなります。

@gaearonこのソリューションはどうですか？ 一般的なレデューサーが自分自身をこのような子レデューサーと呼ぶ代わりに

case PERFORM_IN_LIST:
      return [
        ...state.slice(0, index),
        reducer(state[index], innerAction),
        ...state.slice(index + 1)
      ];

dispatchのように機能する特別なメソッドdispatchTo(reducer, state, action, callback)をストアに提供します。ただし、子レデューサーに直接ディスパッチし（構成されているすべてのミドルウェアを介して）、子の状態が変更されるたびにコールバックに通知します。

export default function list(reducer, dispatchTo) {
  return function (state = [], action) {
    ...
    case PERFORM_IN_LIST:
      dispatchTo(reducer, state[index], innerAction, newState =>
         [
           ...state.slice(0, index),
           newState,
           ...state.slice(index + 1)
        ]);
       default:
          return state;
    }
  }
}

これがReduxで実行可能かどうかはわかりません。 アイデアは、いくつかのミドルウェアをルートストアとして構成された状態ツリーのその部分の子ストアを返す内部store.derive(reducer, state)メソッドを使用してdispatchToを実装することです。 例えば

function dispatchTo(reducer, state, action, callback) {
  const childStore = store.derive(reducer, state)
  childStore.subscribe(() => setRootState( callback(getState() ))
  childStore.dispatch(action)
}

Reduxの内部を知らないと言ったので、これは単なるアイデアなので、何かを逃したかもしれません

編集
_おそらく、レデューサーメソッドは同期的であると想定されているため、これは厄介なことになります。 メソッドを非同期にするということは、すべてのチェーンアップも非同期でなければならないことを意味します。
おそらく最善の解決策は、 store.derive(reducer)メソッドを直接公開し、ある種のストア構成を使用して汎用レデューサーを構築することです_

それはあまりにも複雑で、IMOの価値はありません。 この方法で実行したい場合は、ミドルウェアを使用しないでください（または、 applyMiddlewareの代替実装を使用してください）。これで準備は完了です。

また、これに対応する予定がないため、締め切ります。

議論のために@gaearon ：
このコミットで添付したコード例： https ：//github.com/rackt/redux/commit/a83002aed8e36f901ebb5f139dd14ce9c2e4cab4

カウンターのリストが2つ（または別々の「モデル」）ある場合、アクションタイプが同じであるため、 addToListをディスパッチすると、両方のリストにアイテムが追加されます。

// reducers/index.js

import { combineReducers } from 'redux';
import counter from './counter';
import list from './list'

const counterList = list(counter);
const counterList2 = list(counter);

const rootReducer = combineReducers({
  counterList,
  counterList2
});

export default rootReducer;

では、 reducers/listはここでどのように役立ちますか？ アクションタイプなどのプレフィックスを付ける必要はありませんか？

カウンターのリストが2つ（または別々の「モデル」）ある場合、アクションタイプが同じであるため、addToListをディスパッチすると両方のリストにアイテムが追加されます。

a83002aed8e36f901ebb5f139dd14ce9c2e4cab4をよく見てください。 アクションをネストします。 コンテナコンポーネントから渡されるdispatchは、アクションをperformInListアクションにラップします。 次に、内部アクションがレデューサーで取得されます。 これは、Elmアーキテクチャの動作とほぼ同じです。

@gaearon何かが足りないかもしれませんが、上記の追加のcounterList2レデューサーとともに、このUIは各アクションの両方のリストを更新します（これは、ビルド方法に応じて予想されますが、解決策は何ですか？）：

// reducers/index.js

import { combineReducers } from 'redux';
import counter from './counter';
import list from './list'

const counterList = list(counter);
const counterList2 = list(counter);

const rootReducer = combineReducers({
  counterList,
  counterList2
});

export default rootReducer;


// containers/App.js

import React from 'react';

import { bindActionCreators } from 'redux';
import { connect } from 'react-redux';

import counter from '../components/Counter';
import list from '../components/list';

let CounterList = list(function mapItemStateToProps(itemState) {
  return {
    counter: itemState
  };
})(counter);

CounterList = connect(function mapStateToProps(state) {
  return {
    items: state.counterList
  };
})(CounterList);

let CounterList2 = list(function mapItemStateToProps(itemState) {
  return {
    counter: itemState
  };
})(counter);

CounterList2 = connect(function mapStateToProps(state) {
  return {
    items: state.counterList2
  };
})(CounterList2);


export default class App extends React.Component {
  render() {
    return (
      <div>
        <CounterList />
        <CounterList2 />
      </div>
    )
  }
}

@eladoカウンターのリストで行ったのと同じように、2つのリストでアクションが衝突しないように、リストで再度ラップする必要があります。

@ccorcos

もう一度リストにラップします

正確に何をラップしますか？

@ccorcos
ここに例をアップロードしました：http： //elado.s3-website-us-west-1.amazonaws.com/redux-counter/
ソースマップがあります

あなたが何を意味したのかまだ完全にはわかりません。 私が言ったように、アクション名は同じであり、どのリストで実行するかがアクションクリエーターに示されていないため、現在の動作は予想どおりです。したがって、すべてのレデューサーでアクションが実行され、最終的に両方のリストに影響します。

そのため、実際のReduxの機能はよくわかりませんが、elmについてはよく知っています。

この新しい例では、トップレベルのアクションクリエーターを拘束していません。 代わりに、ディスパッチ関数を下位コンポーネントに渡し、それらの下位コンポーネントはアクションをディスパッチ関数に渡すことができます。

抽象化をうまく機能させてアクションの衝突を起こさないようにするために、「listOf」コンポーネントがディスパッチをその子に渡すとき、実際には、リストコンポーネントが理解できる形式でアクションをラップする関数を渡します。

children.map((child, i) => {
  childDispatch = (action) => dispatch({action, index: i})
  // ...

これで、 listOf(counter)またはlistOf(listOf(counter))を作成できます。また、 pairOfというコンポーネントを作成する場合は、アクションを渡すときに必ずラップする必要があります。 現在、 Appコンポーネントは、ディスパッチ関数をラップせずにそれらを並べてレンダリングするだけなので、アクションの衝突が発生します。

@ccorcos

ありがとう。 したがって、結論として、明らかに「魔法」は発生していません。アクションには、アクションを実行するインスタンスをレデューサーに指示するために必要なすべての情報が必要です。 listOf(listOf(counter))の場合、アクションには2次元配列の両方のインデックスが必要になります。 listOf(listOf(counter))は機能しますが、アクションで渡される唯一のものである一意のIDでインデックス付けされた単一のフラットリスト内のすべてのカウンターを使用する方が柔軟性が高いようです。

柔軟で複雑なReduxアプリを構築する唯一の方法は、システム内のすべてのエンティティをストア内のIDでインデックス化することです。 例で示されることもある他のより単純なアプローチは、すぐに限界に達します。 このインデックスは、ほとんどリレーショナルDBのミラーです。

アクションには、2次元配列の両方のインデックスが必要です

あなたの思考と行動は次のように聞こえます：

{type: 'increment', index:[0 5]}

しかし、実際には次のようになります。

{type:'child', index: 0, action: {type: 'child', index: 5, action: {type: 'increment'}}}

そうすれば、 listOf(listOf(listOf(...listOf(counter)...)))永遠に行うことができます！

これはすべてエルムから来ています、ところで。 Elmアーキテクチャチュートリアルをご覧ください

パーティーには少し時間がかかりますが、これが「ミドルウェアで機能しない」場所がわかりません。 @ccorcosとして無限のネストを提供している場合、ネストを処理するためにミドルウェアを接続するだけではいけませんか？ それとも、ネストされたアクションが奇妙さを意味するredux-thunkについてのみ話しているのでしょうか？

ミドルウェアは、アクションをそのまま解釈するか、ネストされたアクションを探すかをどのように判断しますか？

そうですか。

@gaearon

こんにちは。

私はこの問題の解決策を理解したとは思っていません。簡単な答えをいただければ幸いです。

同じページにコンポーネントの複数のコピーがある場合、_ミドルウェア（および基本的にほとんどのReduxエコシステム）を使用しないでください_？ また、誰かがマルチレデューサーの提案に応答したかどうかもわかりませんでした。

どんな説明でも役に立ちます。

いいえ、これは解決策ではありません。 スレッドは、ページ上にコンポーネントの複数のIDを持つことについてではありません。 これを実装するには、アクションでIDを渡すだけです。 スレッドは_それを行うためのジェネリック関数を書くこと_についてでした。 残念ながら、これはミドルウェアの概念と衝突します。

ありがとう。

こんにちは、みんな、
たぶん私はこの問題を解決しました、しかし私はreact $よりもdekuを使うことを好みます^^

この実験、特にtaskMiddlewareのアイデアについて、誰かが私に洞察を与えてくれたら嬉しいです。 @gaearonチェックする時間はありますか？ ：舌：

カウンターのリスト

ありがとう！

これらのソリューションはいずれも初期状態の処理を目的としていないことを明確にしておきたいだけです。
これはどういうわけか@gaearonで達成できますか？ 上記のリストレデューサーがカウンターの初期リストを持つことを許可しますか？

なぜそれが問題になるのでしょうか？ undefined状態の子レデューサーを呼び出して、それらの値を使用できると思います。

ストアが最初のディスパッチで初期化されるとき、（内部ロジックの場合）そのリストの初期状態が必要です。これは、事前定義されたカウンターのリスト（リストのアイテムのタイプ）である必要があります。

このようなもの？

export default function list(reducer) {
  return function (state = [

    // e.g. 2 counters with default values
    reducer(undefined, {}),
    reducer(undefined, {}),

      ], action) {
    const {
      index,
      action: innerAction
    } = action;
   // ...
  }
}

必要に応じて、これをlistの引数にすることもできます

これは本当に複雑に思えるので、1ページに同じコンポーネントを複数持つことができます。

私はまだReduxに頭を悩ませていますが、推奨されるReduxの使用パターンでなくても、複数のストアを作成する方がはるかに簡単なようです。

@deevus ：これらの議論のいくつかを怖がらせないでください。 Reduxコミュニティには、関数型プログラミングを非常に重視している人がたくさんいます。このスレッドや他の同様の概念で説明されている概念のいくつかには価値がありますが、それらは「完璧な」ものを目指す試みのようなものになる傾向があります。 、単に「良い」ではなく。

一般に、1つのページにコンポーネントの複数のインスタンスを完全に含めることができます。 この議論が目指しているのは、ネストされたコンポーネントの任意の構成です。これは興味深いものですが、ほとんどのアプリが行う必要のあることでもありません。

それ以外に特定の懸念がある場合は、通常、スタックオーバーフローが質問をするのに適した場所です。 また、DiscordのReactifluxコミュニティには、Reactと関連テクノロジーについて話し合うためのチャットチャネルがたくさんあり、話したり助けたりすることをいとわない人が常にいます。

@markeriksonありがとう。 Reactiflux onDiscordから助けを求めてみます。

これのフォローアップ：
プロジェクトでレデューサーを再利用するスケーラブルな方法を見つけました。レデューサー内でレデューサーを再利用することもできます。

名前空間パラダイム

多くの「部分的な」レデューサーの1つに作用するアクションは、同じアクションtypeをリッスンするため、レデューサーが処理するすべてのレデューサーとは逆に、どのレデューサーがアクションを処理するかを決定する「名前空間」プロパティを保持するという概念です（例https://github.com/reactjs/redux/issues/822#issuecomment-172958967）

ただし、名前空間を保持しないアクションは、他のレデューサー内のすべての部分レデューサーに伝播されます。

部分レデューサーAがあり、初期状態がA(undefined, {}) === Saで、レデューサーBが初期状態がB(undefined, {}) === { a1: Sa, a2: Sa }で、キーがa1であるとします。 a2は、 Aのインスタンスです。

['a1']の名前空間を持つアクション（*名前空間は常に部分レデューサーに対する状態のキーに似た文字列の順序付けられた配列です） Bにキャストすると、次の結果が生成されます

const action = {
  type: UNIQUE_ID,
  namespace: ['a1']
};

B(undefined, action) == { a1: A(undefined, action*), a2: Sa }

そして、名前空間のないアクションの反例

const action = {
  type: UNIQUE_ID
};


B(undefined, action) == { a1: A(undefined, action), a2: A(undefined, action) }

警告

• Aが指定されたアクションを処理しない（レデューサーを使い果たす）場合、同じ状態を返す必要があります。これは、レデューサーAでは処理できないアクションpの場合を意味します。 B(undefined, p) { a1: Sa, a2: Sa }になるはずです。これは、ちなみにBの初期状態と同じです。
• 部分的なレデューサー（上記でaction*として示されている）に渡されるアクションは、スコープを絞り込むために使用される名前空間を削除する必要があります。 したがって、 Bに渡されたアクションが{ type: UNIQUE_ID, namespace: ['a1'] }だった場合、 Aに渡されたアクションは{ type: UNIQUE_ID, namespace: [] }なります。
• この構造を実現するには、ストア内のすべてのレデューサーが名前空間アクションを処理する必要があります。このポイントが満たされた場合、使用する名前空間の数とネストできる部分レデューサーの数に制限はありません。

これを実現するために、レデューサーで名前空間を処理するためのいくつかの擬似コードを考え出しました。 これが機能するためには、レデューサーがアクションを処理できるかどうか、およびレデューサーに存在する部分的なレデューサーの量を事前に知っておく必要があります。

(state = initialState, { ...action, namespace = [] }) => {
    var partialAction = { ...action, namespace: namespace.slice(1) };
    var newState;
    if (reducerCanHandleAction(reducer, action) and namespaceExistsInState(namespace, state)) {
        // apply the action to the matching partial reducer
        newState = {
            ...state,
            [namespace]: partialReducers[namespace](state[namespace], partialAction)
        };
    } else if (reducerCantHandleAction(reducer, action) {
        // apply the action to all partial reducers
        newState = Object.assign(
            {},
            state,
            ...Object.keys(partialReducers).map(
                namespace => partialReducers[namespace](state[namespace], action)
            )
        );
    } else {
        // can't handle the action
        return state;
    }

    return reducer(newState, action);
}

レデューサーがアクションを処理できるかどうかを事前に判断する方法はあなた次第です。アクションタイプがキーで、ハンドラー関数が値であるオブジェクトマップを使用します。

私はゲームに少し遅れるかもしれませんが、役立つかもしれないいくつかの汎用レデューサーを書きました：
https://gist.github.com/crisu83/42ecffccad9d04c74605fbc75c9dc9d1

mutilreducerは素晴らしい実装だと思います

@jeffhtli multireducerは、未定義の量のレデューサーを許可しないため、適切なソリューションではありません。代わりに、静的レデューサーリストを作成するように先制的に要求します。
代わりに、コンポーネントのインスタンスごとにUUIDを使用し、UUIDごとに一意の状態を使用して、この問題を解決する小さなプロジェクトを作成しました。
https://github.com/eloytoro/react-redux-uuid