Redux: 감속기 및 구성 요소 향상기로 일반 목록을 만드는 방법은 무엇입니까?

나는 이것이 좋은 예라는 데 동의합니다.
Redux는 여기에서 Elm Architecture 와 유사하므로 자유롭게 예제에서 영감을 얻을 수 있습니다.

모든 종류의 엔터티를 수집하기 위해 일반화된 목록 저장소+구성 요소를 어떻게 만들 수 있습니까? todomvc-example에서 카운터와 할 일 항목을 모두 가져오기 위해 목록 저장소+구성 요소를 더욱 일반화할 수 있습니까?

예, 확실히 가능합니다.
고차 감속기와 고차 구성 요소를 만들고 싶습니다.

고차 감속기의 경우 여기에서 접근 방식을 참조하십시오.

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 를 통해 목록 기능을 재사용하여 카운터 목록과 할 일 항목 목록을 둘 다 가질 수 있는지 궁금합니다. 그리고 그것이 의미가 있다면. 그러나 나는 확실히 그것을 시도 할 것입니다.

나는 여전히 카운터 목록과 할 일 항목 목록을 모두 갖기 위해 CombineReducers를 통해 목록 기능을 재사용할 수 있는지 궁금합니다. 그리고 그것이 의미가 있다면. 그러나 나는 확실히 그것을 시도 할 것입니다.

예, 완전히:

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() 를 발송할 수 없습니다. 그리고 bam! 썽크 미들웨어는 더 이상 그것을 인식하지 못합니다.

이것에 대한 어색하지 않은 솔루션이 있을 수 있지만 아직 보지 못했습니다.
지금은 이 커밋 을 예시로 보십시오(위에 설명된 제한 사항 포함).

코드는 다음과 같습니다.

구성 요소/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;

구성 요소/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);
  };
}

작업/목록.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 — 현재 미들웨어 + React Redux 디자인이 다소 무너진 예입니다.
이것을 wontfix로 선언할 수 있지만 우리가 이것을 피할 수 있는 방법이 있는지 살펴보고 싶을 수도 있습니다.

일 것이다
https://github.com/erikras/multireducer/ 도움말?

저는 React용 서비스(IoC) 컨테이너 사용을 실험해 왔으며 어제 이 테스트 리포지토리를 만들었습니다. https://github.com/magnusjt/react-ioc

CounterList가 알지 못하는 상태에서 작업 생성자를 Counter에 전달할 수 있기 때문에 잠재적으로 문제의 일부를 해결할 수 있다고 생각합니다. 이것은 액션 생성자가 props가 아닌 Counter의 생성자에 들어가기 때문에 가능합니다.

새로 만드는 모든 Counter 구성 요소에 대해 다른 작업 작성자를 전달할 수 있습니다(아마도 인덱스 값을 작업 작성자에 바인딩하여). 물론 데이터를 카운터로 가져오는 데 여전히 문제가 있습니다. 그것이 서비스 컨테이너로 해결할 수 있는 것인지는 아직 확실하지 않습니다.

@gaearon , 당신의 예는 나에게 딱 맞는 것 같습니다. 액션 생성자를 전달하고 아래로 파견해야 합니다. 이런 식으로 고차원 기능으로 액션을 제단할 수 있습니다.

나는 당신의 두 번째 요점이 필요한지 잘 모르겠습니다. 새로운 메시지 형식으로 인해 미들웨어를 놓칠 수 있지만 performInList 의 더 큰 문제는 추상화를 하나의 목록으로 제한했다는 것입니다. @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는 미들웨어를 통해 모든 하위 작업을 적용해야 합니다. 또한, 또 다른 문제는 목록 내의 상태를 초기화하는 것입니다...

당신이 설명하는 것은 Elm Architecture로 알려져 있습니다. 여기를 참조하십시오: https://github.com/gaearon/react-elmish-example

친구, 당신은 항상 한발 앞서 있습니다! 멋진 것들에 대한 링크로 저에게 샤워하세요 :+1:

래핑된 구성 요소에서 미들웨어가 필요한 작업을 전달할 수 없습니다. 이것은 부끄러운 일입니다! 목록으로 카운터를 래핑하면 function (dispatch, getState) { ... } 방금 디스패치한 것이 { action: function (dispatch, getState) { ... } }로 바뀌었기 때문에 더 이상 incrementAsync()를 디스패치할 수 없습니다. 목록과 bam! 썽크 미들웨어는 더 이상 그것을 인식하지 못합니다.

@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) 메서드를 직접 노출하고 일종의 Store 구성을 사용하여 일반 감속기를 빌드하는 것입니다.

그것은 너무 많은 합병증이며 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 Architecture가 작동하는 방식입니다.

@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 카운터 목록과 동일한 방식으로 두 목록에 대해 작업이 충돌하지 않도록 목록으로 다시 래핑해야 합니다.

@ccorcos

목록으로 다시 포장하려면

정확히 무엇을 포장?

@ccorcos
여기에 예제를 업로드했습니다: http://elado.s3-website-us-west-1.amazonaws.com/redux-counter/
소스 맵이 있습니다.

여전히 당신이 의미하는 바를 완전히 확신하지 못합니다. 내가 말했듯이 - 현재 동작은 예상되는 동작입니다. 동작 이름이 동일하고 동작 생성자에 이를 수행할 목록이 없기 때문에 결국 두 목록에 모두 영향을 미치는 모든 감속기에서 동작을 실행하기 때문입니다.

그래서 나는 실제 Redux의 기능을 잘 모르지만 느릅나무에 대해서는 아주 잘 알고 있습니다.

이 새 예에서는 최상위 수준에서 작업 생성자를 바인딩하지 않습니다. 대신 디스패치 함수를 하위 구성 요소로 전달하고 해당 하위 구성 요소는 작업을 디스패치 함수로 전달할 수 있습니다.

추상화가 잘 작동하도록 하여 작업 충돌이 없도록 하려면 "listOf" 구성 요소가 디스패치를 ​​자식에게 전달할 때 실제로 목록 구성 요소가 이해할 수 있는 형식으로 작업을 래핑하는 함수를 전달합니다.

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

이제 listOf(counter) 또는 listOf(listOf(counter)) 를 작성할 수 있으며 pairOf 라는 구성 요소를 생성하려면 액션을 전달할 때 랩핑해야 합니다. 현재 App 구성 요소는 디스패치 함수를 래핑하지 않고 나란히 렌더링하므로 작업 충돌이 발생합니다.

@ccorcos

감사 해요. 따라서 결론적으로 "마법"이 발생하지 않습니다. 작업에는 작업을 수행할 인스턴스를 감속기에 알려주는 데 필요한 모든 정보가 필요합니다. listOf(listOf(counter)) 인 경우 작업에는 2D 배열의 두 인덱스가 모두 필요합니다. listOf(listOf(counter)) 는 작동할 수 있지만 단일 플랫 목록의 모든 카운터가 작업에서 전달되는 유일한 ID로 인덱싱되도록 하는 것이 더 유연해 보입니다.

유연하고 복잡한 Redux 앱을 빌드하는 유일한 방법은 시스템의 모든 엔터티가 스토어의 ID로 인덱싱되도록 하는 것 같습니다. 때때로 예제에서 제공되는 다른 간단한 접근 방식은 한계에 빠르게 도달합니다. 이 인덱스는 거의 관계형 DB의 미러입니다.

작업에는 2d 배열의 두 인덱스가 모두 필요합니다.

당신의 생각과 행동은 다음과 같습니다.

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

하지만 실제로는 다음과 같아야 합니다.

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

그렇게 하면 listOf(listOf(listOf(...listOf(counter)...))) 영원히 할 수 있습니다!

이것은 모두 느릅나무에서 옵니다. btw. 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 에 대한 인수로 만들 수도 있습니다.

이것은 페이지에 동일한 구성 요소를 여러 개 가질 수 있도록 정말 복잡해 보입니다.

나는 여전히 Redux에 대해 머리를 싸매고 있지만 권장되는 Redux 사용 패턴이 아니더라도 여러 저장소를 만드는 것이 훨씬 간단해 보입니다.

@deevus : 이러한 토론 중 일부가 당신을 놀라게 하지 마십시오. Redux 커뮤니티에는 함수형 프로그래밍을 지향하는 많은 사람들이 있습니다. 이 스레드와 다른 유사한 개념에서 논의된 개념 중 일부는 가치가 있지만 "완벽한" 것을 추구하는 경향이 있습니다. , 단순히 "좋은"이 아니라.

일반적으로 한 페이지에 여러 구성 요소 인스턴스가 있을 수 있습니다. 이 토론의 목표는 중첩된 구성 요소의 임의 구성입니다. 이는 흥미롭지만 대부분의 앱에서 수행해야 하는 것은 아닙니다.

그 외에 특정 문제가 있는 경우 일반적으로 스택 오버플로가 질문하기에 좋은 곳입니다. 또한 Discord의 Reactiflux 커뮤니티에는 React 및 관련 기술에 대한 토론 전용 채팅 채널이 있으며, 항상 대화하고 도움을 주고자 하는 사람들이 있습니다.

@markerikson 감사합니다. Discord에서 Reactiflux의 도움을 받으려고 합니다.

이에 대한 후속 조치:
프로젝트에서 리듀서를 재사용하는 확장 가능한 방법을 찾았습니다. 리듀서 내에서 리듀서를 재사용할 수도 있습니다.

네임스페이스 패러다임

많은 "부분" 리듀서 중 하나에 작용하는 액션이 ​​동일한 액션 type (예 https://github.com/reactjs/redux/issues/822#issuecomment-172958967)

그러나 네임스페이스를 보유하지 않는 작업은 여전히 ​​다른 리듀서 내의 모든 부분 리듀서로 전파됩니다.

부분 감속기가 A A(undefined, {}) === Sa 이고 초기 상태가 B(undefined, {}) === { a1: Sa, a2: Sa } 이고 키가 a1 인 감속기 B 가 있다고 가정합니다. 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 가 주어진 작업을 처리하지 않으면(리듀서를 소진) 동일한 상태를 반환해야 합니다. 이는 p 작업에 대해 A 에 대해 처리할 수 없음을 의미합니다. 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