Redux: 중첩 된 엔티티를 업데이트 할 때 상용구를 자르는 방법은 무엇입니까?

https://github.com/gaearon/normalizr 과 같이 중첩 된 JSON을 정규화하는 것이 좋습니다.

예, 데이터를 정규화하는 것이 좋습니다.
이렇게하면 "깊이"갈 필요가 없습니다. 모든 엔티티가 동일한 수준에 있습니다.

그래서 당신의 상태는

{
  entities: {
    plans: {
      1: {title: 'A', exercises: [1, 2, 3]},
      2: {title: 'B', exercises: [5, 1, 2]}
     },
    exercises: {
      1: {title: 'exe1'},
      2: {title: 'exe2'},
      3: {title: 'exe3'}
    }
  },
  currentPlans: [1, 2]
}

감속기는 다음과 같이 보일 수 있습니다.

import merge from 'lodash/object/merge';

const exercises = (state = {}, action) => {
  switch (action.type) {
  case 'CREATE_EXERCISE':
    return {
      ...state,
      [action.id]: {
        ...action.exercise
      }
    };
  case 'UPDATE_EXERCISE':
    return {
      ...state,
      [action.id]: {
        ...state[action.id],
        ...action.exercise
      }
    };
  default:
    if (action.entities && action.entities.exercises) {
      return merge({}, state, action.entities.exercises);
    }
    return state;
  }
}

const plans = (state = {}, action) => {
  switch (action.type) {
  case 'CREATE_PLAN':
    return {
      ...state,
      [action.id]: {
        ...action.plan
      }
    };
  case 'UPDATE_PLAN':
    return {
      ...state,
      [action.id]: {
        ...state[action.id],
        ...action.plan
      }
    };
  default:
    if (action.entities && action.entities.plans) {
      return merge({}, state, action.entities.plans);
    }
    return state;
  }
}

const entities = combineReducers({
  plans,
  exercises
});

const currentPlans = (state = [], action) {
  switch (action.type) {
  case 'CREATE_PLAN':
    return [...state, action.id];
  default:
    return state;
  }
}

const reducer = combineReducers({
  entities,
  currentPlans
});

그래서 여기서 무슨 일이 일어나고 있습니까? 먼저 상태가 정규화되었습니다. 우리는 다른 엔티티 안에 엔티티가 없습니다. 대신 ID로 서로를 참조합니다. 따라서 일부 개체가 변경 될 때마다 업데이트해야하는 단일 위치 만 있습니다.

둘째, plans 감속기에 적절한 엔티티를 추가하고 currentPlans 감속기에 ID를 추가하여 CREATE_PLAN 에 어떻게 반응하는지 확인합니다. 이건 중요하다. 더 복잡한 앱에서는 관계가있을 수 있습니다. 예를 들어 plans 감속기는 계획 내의 배열에 새 ID를 추가하여 동일한 방식으로 ADD_EXERCISE_TO_PLAN 를 처리 할 수 ​​있습니다. 그러나 운동 자체가 업데이트되면 _ID가 변경되지 않았으므로 plans 감속기가이를 알 필요가 없습니다 _.

셋째, 엔티티 감속기 ( plans 및 exercises )에는 action.entities 감시하는 특수 절이 있습니다. 이것은 우리가 반영하기 위해 모든 엔티티를 업데이트하고자하는 "알려진 진실"을 가진 서버 응답이있는 경우입니다. 작업을 전달하기 전에 이러한 방식으로 데이터를 준비하려면 normalizr 을 사용할 수 있습니다. Redux repo의 "real world"예제에서 사용 된 것을 볼 수 있습니다.

마지막으로 엔티티 감속기가 어떻게 유사한 지 확인하십시오. 이를 생성하는 함수를 작성할 수 있습니다. 내 대답의 범위를 벗어났습니다. 때로는 더 많은 유연성을 원하고 때로는 더 적은 상용구를 원합니다. 유사한 감속기를 생성하는 예를 보려면 "실제"감속기 예제에서 페이지 매김 코드를 확인할 수 있습니다.

아, 그리고 { ...a, ...b } 구문을 사용했습니다. Babel 2 단계에서 ES7 제안으로 활성화됩니다. "객체 확산 연산자"라고하며 Object.assign({}, a, b) 를 쓰는 것과 같습니다.

라이브러리의 경우 Lodash를 사용할 수 있습니다 (예를 들어 merge({}, a, b} 는 정확하지만 merge(a, b) 은 올바르지 않음), updeep , react-addons-update 또는 다른 것을 사용할 수 있습니다. 그러나 심층 업데이트가 필요한 경우 상태 트리가 충분히 평평하지 않고 기능 구성을 충분히 활용하지 않았 음을 의미합니다. 첫 번째 예도 :

case 'UPDATE_PLAN':
  return {
    ...state,
    plans: [
      ...state.plans.slice(0, action.idx),
      Object.assign({}, state.plans[action.idx], action.plan),
      ...state.plans.slice(action.idx + 1)
    ]
  };

다음과 같이 쓸 수 있습니다.

const plan = (state = {}, action) => {
  switch (action.type) {
  case 'UPDATE_PLAN':
    return Object.assign({}, state, action.plan);
  default:
    return state;
  }
}

const plans = (state = [], action) => {
  if (typeof action.idx === 'undefined') {
    return state;
  }
  return [
    ...state.slice(0, action.idx),
    plan(state[action.idx], action),
    ...state.slice(action.idx + 1)
  ];
};

// somewhere
case 'UPDATE_PLAN':
  return {
    ...state,
    plans: plans(state.plans, action)
  };

이것을 조리법으로 바꾸면 좋을 것입니다.

이상적으로 우리는 간판 보드 예제를 원합니다.
"레인"내부에 "카드"가있을 수 있기 때문에 중첩 된 엔티티에 적합합니다.

@ andre0799 또는 Immutable.js를 사용할 수 있습니다))

이상적으로 우리는 간판 보드 예제를 원합니다.

나는 하나를 썼다. 아마도 당신은 그것을 포크하고 원하는대로 조정할 수 있습니다.

Immutable.js가 항상 좋은 해결책은 아닙니다. 변경 한 노드에서 시작하여 상태의 모든 상위 노드의 해시를 다시 계산하며 이는 특정 경우에 병목 현상이됩니다 (이것은 매우 일반적인 경우가 아닙니다). 따라서 이상적으로는 Immutable.js를 애플리케이션에 통합하기 전에 몇 가지 벤치 마크를 만들어야합니다.

귀하의 답변, 훌륭한 설명에 대해 @gaearon 에게 감사드립니다!

따라서 CREATE_PLAN 을 수행하면 자동으로 기본 운동을 생성하고 추가해야합니다. 이와 같은 경우를 어떻게 처리해야합니까? 그런 다음 3 개의 작업을 연속으로 호출해야합니까? CREATE_PLAN, CREATE_EXERCISE, ADD_EXERCISE_TO_PLAN 경우 어디에서 전화를해야합니까?

따라서 CREATE_PLAN을 수행 할 때 기본 운동을 자동으로 생성하고 추가해야합니다. 이와 같은 경우를 어떻게 처리해야합니까?

일반적으로 동일한 작업을 처리하는 많은 리듀서를 선호하지만 관계가있는 엔티티에는 너무 복잡해질 수 있습니다. 실제로 나는 이것들을 별개의 행동으로 모델링 할 것을 제안하고 있습니다.

Redux Thunk 미들웨어를 사용하여 둘 다 호출하는 액션 생성자를 작성할 수 있습니다.

function createPlan(title) {
  return dispatch => {
    const planId = uuid();
    const exerciseId = uuid();

    dispatch({
      type: 'CREATE_EXERCISE',
      id: exerciseId,
      exercise: {
        id: exerciseId,
        title: 'Default'
      }
    });

    dispatch({
      type: 'CREATE_PLAN',
      id: planId,
      plan: {
        id: planId,
        exercises: [exerciseId],
        title
      }
    });
  };
}

그런 다음 Redux Thunk 미들웨어를 적용하면 정상적으로 호출 할 수 있습니다.

store.dispatch(createPlan(title));

백엔드 어딘가에 그러한 관계 (게시물, 작성자, 태그, 첨부 파일 등)가있는 게시물 편집기가 있다고 가정 해 보겠습니다.

currentPlans 키 배열과 유사한 currentPosts 표시하려면 어떻게해야합니까? currentPosts 각 키를 mapStateToProps 함수의 entities.posts 에있는 해당 객체에 매핑해야합니까? currentPosts 정렬

이 모든 것이 감속기 구성에 속합니까?

여기 뭔가 빠졌어요 ...

원래 질문과 관련하여 React Immutability Helpers 가 그 목적을 위해 만들어 졌다고 생각합니다

currentPlans 키 배열과 유사한 currentPosts를 표시하려면 어떻게해야합니까? currentPosts의 각 키를 mapStateToProps 함수의 entity.posts에있는 해당 객체에 매핑해야합니까? currentPosts를 정렬하는 것은 어떻습니까?

맞습니다. 데이터를 검색 할 때 모든 작업을 수행합니다. Redux 저장소와 함께 제공되는 "장바구니"및 "실제 세계"예제를 참조하십시오.

감사합니다. 문서에서 파생 데이터 계산 을 읽은 후 이미 아이디어를 얻기 시작했습니다.

이 예제를 다시 확인하겠습니다. 처음 읽었을 때 무슨 일이 벌어 졌는지 이해하지 못했을 것입니다.

뿡 빵뀨

모든 connect() ed 구성 요소에는 기본적으로 dispatch 가 prop으로 삽입됩니다.

this.props.dispatch(createPlan(title));

이 스레드와 관련이없는 사용 질문입니다. 이에 대한 예제를 참조하거나 StackOverflow 질문을 만드는 것이 좋습니다.

저는 Dan이 데이터를 정규화하고 가능한 한 상태 구조를 평탄화하는 것에 동의합니다. 그것은 나에게 약간의 두통을 덜어 주었을 것이므로 문서에 레시피 / 모범 사례로 넣을 수 있습니다.

내 상태에서 약간의 깊이를 갖는 실수를했기 때문에 Redux를 사용하여 깊은 상태를 개조하고 관리하는 데 도움이되도록이 lib를 만들었습니다. https://github.com/baptistemanson/immutable-path
아마 모든 것이 잘못되었지만 귀하의 의견에 관심이 있습니다. 누군가를 도울 수 있기를 바랍니다.

이것은 도움이되었습니다. 모두에게 감사합니다.

실제 예제와 동일한 구조를 사용하여 계획에 운동을 추가하는 방법은 무엇입니까? 운동을 추가하면 planId 필드와 함께 새로 생성 된 운동 항목이 반환되었다고 가정 해 보겠습니다. 계획에 대한 감속기를 작성하지 않고 해당 계획에 새 운동을 추가하고 특별히 CREATE_EXERCISE 작업을들을 수 있습니까?

여기에 훌륭한 토론과 정보가 있습니다. 내 프로젝트에 normalizr을 사용하고 싶지만 업데이트 된 데이터를 원격 서버에 다시 저장하는 것과 관련하여 질문이 있습니다. 주로, 업데이트 후 정규화 된 모양을 원격 API에서 제공하는 중첩 모양으로 되 돌리는 간단한 방법이 있습니까? 이는 클라이언트가 변경을 수행하고 업데이트 요청의 형태를 제어 할 수없는 원격 API로 피드백해야 할 때 중요합니다.

예 : 클라이언트가 중첩 된 운동 데이터를 가져옴-> 클라이언트가이를 정규화하여 redux에 저장-> 사용자가 클라이언트 측에서 정규화 된 데이터를 변경-> 사용자가 저장을 클릭-> 클라이언트 앱이 업데이트 된 정규화 된 데이터를 중첩 된 형태로 다시 변환 그래서 그것은 원격 서버에 제출할 수 있습니다 -> 클라이언트가 서버에 제출

normalizr을 사용했다면 굵은 단계에 대한 사용자 지정 변환기를 작성해야합니까? 아니면이를 위해 권장 할 라이브러리 또는 도우미 메서드가 있습니까? 모든 권장 사항을 많이 주시면 감사하겠습니다.

감사

https://github.com/gpbl/denormalizr 이라는 것이 있지만 normalizr 업데이트를 얼마나 밀접하게 추적하는지 잘 모르겠습니다. 내가 작업 한 앱에 대해 몇 시간 만에 normalizr을 작성했습니다. 포크하고 비정규 화를 추가 할 수 있습니다 😄.

멋지다. 비정규 화를 살펴보고 무언가가 있으면 프로젝트에 다시 기여할 것입니다. 몇 시간 동안 대단한 일을했습니다 ;-) 다시 연락해 주셔서 감사합니다.

나는 깊이 중첩 된 데이터를 변경하는 것과 같은 상황에 있지만 immutable.js를 사용하여 작동하는 솔루션을 찾았습니다.

여기에서 솔루션에 대한 피드백을 요청한 StackOverflow 게시물에 링크해도 괜찮습니까?

지금 링크하고 있습니다. 내 게시물을 삭제하거나 여기에 링크하는 것이 부적절하다고 말 해주세요 :
http://stackoverflow.com/questions/37171203/manipulating-data-in-nested-arrays-in-redux-with-immutable-js

이 접근 방식이 과거에 권장되는 것을 보았습니다. 그러나이 방법은 중첩 된 개체를 제거해야하는 경우 제대로 작동하지 않는 것 같습니다. 이 경우 리듀서는 객체 자체를 제거하기 전에 객체에 대한 모든 참조를 살펴보고이를 제거해야합니다.이 작업은 O (n)이됩니다. 누구든지 비슷한 문제가 발생하여 해결 했습니까?

@ariofrio : 아 ...

당신이 가지고있는 특정한 우려 사항이 있습니까, 아니면 당신이 다루고있는 성가신 시나리오가 있습니까?

제가 의미하는 바는 다음과 같습니다. 현재 상태는 다음과 같습니다.

{
  entities: {
    plans: {
      1: {title: 'A', exercises: [1, 2, 3]},
      2: {title: 'B', exercises: [5, 6]}
     },
    exercises: {
      1: {title: 'exe1'},
      2: {title: 'exe2'},
      3: {title: 'exe3'}
      5: {title: 'exe5'}
      6: {title: 'exe6'}
    }
  },
  currentPlans: [1, 2]
}

이 예에서 각 운동은 하나의 계획에서만 참조 할 수 있습니다. 사용자가 "운동 제거"를 클릭하면 다음과 같은 메시지가 표시 될 수 있습니다.

{type: "REMOVE_EXERCISE", payload: 2}

그러나 이것을 올바르게 구현하려면 매달린 참조를 피하기 위해 모든 계획을 반복 한 다음 각 계획 내의 모든 연습을 반복하여 id 2로 연습을 참조하는 하나를 찾아야합니다. 이것이 제가 걱정했던 O (n) 작업입니다.

이를 피하는 방법은 REMOVE_EXERCISE의 페이로드에 계획 ID를 포함하는 것입니다. 그러나이 시점에서 구조 중첩을 사용하는 것보다 이점이 없다고 생각합니다. 대신 중첩 상태를 사용하면 상태는 다음과 같을 수 있습니다.

{
   plans: [
    {title: 'A', exercises: [{title: 'exe1'}, {title: 'exe2'},{title: 'exe3'}]},
    {title: 'B', exercises: [{title: 'exe5'}, {title: 'exe6'}]}
   ]
}

운동을 제거하라는 메시지는 다음과 같습니다.

{type: "REMOVE_EXERCISE", payload: {plan_index: 0, exercise_index: 1}}

몇 가지 생각 :

• 해당 시나리오를 단순화 할 계획을 세우기 위해 연습의 역방향 조회를 유지할 수 있습니다. 마찬가지로 Redux-ORM 라이브러리가하는 일은 많은 유형의 관계에 대해 "테이블을 통해"자동 생성하는 것입니다. 따라서이 경우에는 {id, planId, exerciseId} 트리플렛이 포함 된 "PlanExercise" "테이블"이 상점에 있습니다. 확실히 O (n) 스캔이지만 간단합니다.
• O (n) 연산은 본질적으로 나쁜 것이 아닙니다. 그것은 전적으로 N이 얼마나 큰지, 용어 앞의 상수 요소, 발생 빈도 및 응용 프로그램에서 진행되는 다른 작업에 따라 다릅니다. 10 개 또는 15 개의 항목 목록을 반복하고 사용자 버튼 클릭에 대한 동등성 검사를 수행하는 것은 500ms마다 시스템에 들어오는 1,000 만 항목 목록을 반복하고 각각에 대해 비용이 많이 드는 작업을 수행하는 것과는 완전히 다른 일입니다. 안건. 이 경우 수천 개의 계획을 확인하는 것조차 의미있는 병목 현상이되지 않을 가능성이 있습니다.
• 이것이 실제 성능 문제입니까, 아니면 가능한 이론적 문제를 예상하고 있습니까?

궁극적으로 중첩 및 정규화 된 상태는 모두 규칙입니다. Redux와 함께 정규화 된 상태를 사용하는 데에는 좋은 이유가 있으며 상태를 정규화 된 상태로 유지해야하는 좋은 이유가있을 수 있습니다. 당신에게 맞는 것을 선택하십시오 :)

내 솔루션은 다음과 같습니다.

function deepCombinReducer(parentReducer, subReducer) {
    return function (state = parentReducer(void(0) /* get parent reducer initial state */, {}) {
        let finalState = {...state};

        for (var k in subReducer) {
          finalState[k] = subReducer(state[k], action);
        }

       return parentReducer(finalState, action);
    };
}

const parentReducer = function(state = {}, action) {
    return state;
}

const subReducer = function(state = [], action) {
    state = Immutable.fromJS(state).toJS();
    switch(action.type) {
       case 'ADD':
          state.push(action.sub);
           return state;
       default:
          return state;
   }
}

export default combineReducers({
   parent: deepCombinReducer(parentReducer, {
       sub: subReducer
   })
})

그런 다음 다음과 같은 상점을 얻을 수 있습니다.

{
    parent: {
       sub: []
    }
}

dispatch({
    type: 'ADD',
    sub: '123'
});

// the store will change to:
{
    parent: {
       sub: ['123']
    }
}

@smashercosmo immutable.js 깊은 중첩 상태? 어떻게 궁금해

@gaearon

우리는 다른 엔티티 안에 엔티티가 없습니다.

이해가 안 돼요. 여기에는 최소한 세 가지 수준의 중첩이 있습니다.

{
  entities: {
    plans: {
      1: {title: 'A', exercises: [1, 2, 3]},
      2: {title: 'B', exercises: [5, 1, 2]}
     },
    exercises: {
      1: {title: 'exe1'},
      2: {title: 'exe2'},
      3: {title: 'exe3'}
    }
  },
  currentPlans: [1, 2]
}

entities.plans[1] - three levels
entities.exercises[1] - three levels

이것은 중첩되지 않은 개체입니다. 한 수준 만.

{
   plans: [1,2, 3],
   exercises: [1,2,3],
   'so forth': [1,2,3]
}

@wzup : 참고로 Dan은 요즘 Redux 문제를 보는 데 많은 시간을 소비하지 않습니다. 그는 React에서 작업하는 데 충분한 시간을 가지고 있습니다.

여기서 "중첩"의 의미는 이전 스레드의 다음 예제와 같이 데이터 자체가 중첩 된 경우입니다.

{
   plans: [
    {title: 'A', exercises: [{title: 'exe1'}, {title: 'exe2'},{title: 'exe3'}]},
    {title: 'B', exercises: [{title: 'exe5'}, {title: 'exe6'}]}
   ]
}

이 예제에서 연습 "exe6"에 액세스하는 유일한 방법은 plans[1].exercises[2] 와 같은 구조를 파헤치는 것입니다.

@tmonte 의 질문에 관심이 있습니다.

실제 예제와 동일한 구조를 사용하여 계획에 운동을 추가하는 방법은 무엇입니까? 운동을 추가하면 planId 필드와 함께 새로 생성 된 운동 항목이 반환되었다고 가정 해 보겠습니다. 계획에 대한 감속기를 작성하지 않고 해당 계획에 새 연습을 추가하고 구체적으로 CREATE_EXERCISE 작업을들을 수 있습니까?

엔티티가 많은 경우 각 엔티티에 대해 하나의 감속기를 만드는 것이 어려울 수 있지만이 접근 방식으로 해결할 수 있습니다. 지금까지 해결책을 찾지 못했습니다.

더 많은 유연성을 위해 merge 대신 mergeWith 사용합니다.

import mergeWith from 'lodash/mergeWith';

// Updates an entity cache in response to any action with `entities`.
function entities(state = {}, action) {
  // Here where we STORE or UPDATE one or many entities
  // So check if the action contains the format we will manage
  // wich is `payload.entities`
  if (action.payload && action.payload.entities) {
    // if the entity is already in the store replace
    // it with the new one and do not merge. Why?
    // Assuming we have this product in the store:
    //
    // products: {
    //   1: {
    //     id: 1,
    //     name: 'Awesome product name',
    //     rateCategory: 1234
    //   }
    // }
    //
    // We will updated with
    // products: {
    //   1: {
    //     id: 1,
    //     name: 'Awesome product name',
    //   }
    // }
    //
    // The result if we were using `lodash/merge`
    // notice the rate `rateCategory` hasn't changed:
    // products: {
    //   1: {
    //     id: 1,
    //     name: 'Awesome product name',
    //     rateCategory: 1234
    //   }
    // }
    // for this particular use case it's safer to use
    // `lodash/mergeWith` and skip the merge
    return mergeWith({}, state, action.payload.entities, (oldD, newD) => {
      if (oldD && oldD.id && oldD.id === newD.id) {
        return newD;
      }
      return undefined;
    });
  }

  // Here you could register other handlers to manipulate 
  // the entities
  switch (action.type) {
    case ActionTypes.SOME_ACTION:
      // do something;
    default:
      return state;
  }
}

const rootReducer = combineReducers({
  entities,
});
export default rootReducer;