Redux: 작업이 여러 감속기와 관련된 경우 combineReducer에 대한 우려

이 경우 combineReducers 이 도움이되지 않는다고 생각하는 이유를 설명해 주시겠습니까? 실제로 데이터베이스와 같은 상태의 경우 단일 리듀서 (그리고 UI 상태에 대한 다른 리듀서 (예 : 선택된 항목 등))가 필요한 경우가 많습니다.

또한보십시오:

https://github.com/rackt/redux/tree/master/examples/real-world/reducers
https://github.com/rackt/redux/blob/master/examples/async/reducers

영감을 얻기 위해.

당신이 지적한 첫 번째 예는 내 경우와 비슷합니다. requestType 는 두 감속기에서 모두 처리됩니다.
https://github.com/rackt/redux/blob/master/examples/real-world/reducers/paginate.js#L28

감속기를 분할하면 두 감속기가 다른 감속기와 분리 될 때 유지 관리가 더 쉬워집니다. 그러나 그들이 동일한 행동을하게되면 다음과 같은 결과가 발생합니다.

• 이러한 작업을 위해서는 여러 감속기 (또는 앱이 커진 후 파일)에서 유지해야합니다. 현재 코드베이스에서 우리는 이미 동일한 작업을 처리하는 5 개의 상점을 보았습니다. 유지 관리가 약간 어렵습니다.
• 일부 경우에서, 하나의 감속기에서 메시지를 이동 (같은 다른 데이터에 의존 할 수있다 unread 로 message , 심지어에서 새로운 스레드와 같은 메시지 촉진 message 에 thread ). 그래서 지금 다른 감속기에서 데이터를 가져와야 할 수도 있습니다.

이 두 가지 문제에 대한 좋은 해결책을 찾지 못했습니다. 사실 저는이 두 가지 문제에 대해 완전히 확신하지 못합니다.

이러한 작업을 위해서는 여러 감속기 (또는 앱이 커진 후 파일)에서 유지해야합니다. 현재 코드베이스에서 우리는 이미 동일한 작업을 처리하는 5 개의 상점을 보았습니다. 유지 관리가 약간 어렵습니다.

이것이 좋은지 나쁜지 여부는 앱에 따라 다릅니다. 내 경험상 동일한 작업을 처리하는 많은 상점 (또는 Redux 감속기)이있는 것은 실제로 매우 편리합니다. 이는 책임을 나누고 사람들이 나머지 팀과 충돌하지 않고 기능 분기에서 작업 할 수 있기 때문입니다. 내 경험상 하나의 거대한 돌연변이보다 관련되지 않은 돌연변이를 별도로 유지하는 것이 더 쉽습니다.

그러나 이것이 너무 잘 작동하지 않는 경우가 있습니다. 나는 그들이 종종 차선 상태 모델의 증상이라고 말하고 싶습니다. 예를 들면

어떤 경우에는 한 리듀서가 다른 리듀서의 데이터에 의존 할 수 있습니다 (메시지를 읽지 않은 상태에서 메시지로 이동하거나 메시지를 새 스레드로 메시지를 메시지에서 스레드로 승격하는 등).

문제의 증상입니다. 상태 내에서 물건을 많이 이동해야하는 경우 상태 모양을 더 표준화해야 할 수 있습니다. 대신 { readMessages, unreadMessages } 당신은 할 수 있습니다 { messagesById, threadsById, messageIdsByThreadIds } . 메시지를 읽었습니까? 좋습니다. state.messagesById[id].isRead 합니다. 스레드에 대한 메시지를 읽고 싶습니까? state.threadsById[threadId].messageIds 를 선택한 다음 messageIds.map(id => state.messagesById[id]) 하세요.

데이터가 정규화되면 한 배열에서 다른 배열로 항목을 복사 할 필요가 없습니다. 대부분의 경우 플래그를 뒤집거나 ID를 추가 / 제거 / 연결 / 연결 해제합니다.

나는 그것을 시도하고 싶습니다.

redux를 시도하기 위해 데모 페이지를 작성했습니다. 나는 combineReducer 가 나에게 상당히 복잡하다고 생각합니다. 그리고 리포지토리의 모든 예제는 combineReducer 를 사용하고 있습니다. 여전히 내 데이터를 포함하는 JavaScript 개체가 아닌 단일 불변 데이터 개체를 모델로 사용할 수 있습니까?

@jiyinyiyong 당신이 말하는 복잡성이 무엇인지 잘 모르겠지만 combineReducers 사용하지 않아도됩니다. 도우미 일뿐입니다. 대신 Immutable을 사용하는 유사한 도우미를 확인하십시오. 물론 자신 만의 글을 쓰세요.

나는 주로 Immutable.js를 지원하기 위해 combineReducers() 도우미를 작성했지만 루트 감속기처럼 취급되는 추가 감속기가 필요할 수 있습니다.
https://github.com/jokeyrhyme/wow-healer-bootcamp/blob/master/utils/combineReducers.js

첫 번째 인수는 상태의 모양과 일치하고 최상위 하위 상태를 제공하는 일치하는 하위 감소기에 전달합니다. 이것은 공식 버전과 거의 동일합니다.

그러나 0 개 이상의 추가 인수를 추가하는 것은 선택 사항이며 다른 루트 리듀서처럼 취급됩니다. 이 감속기는 완전한 상태로 전달됩니다. 이를 통해 권장되는 하위 감소 기 패턴보다 더 많은 액세스가 필요한 방식으로 작업을 전달할 수 있습니다.

이것을 남용하는 것은 분명히 좋은 생각은 아니지만 여러 개의 하위 감속기와 여러 개의 루트 감속기를 갖는 것이 좋은 이상한 경우를 발견했습니다.

여러 루트 리듀서를 추가하는 대신 중간 단계에서 추가 인수를 사용하여 더 광범위한 액세스가 필요한 하위 리듀서를 정의 할 수 있습니다 (여전히 전체 액세스보다 적음). 예를 들면 :

function a (state, action) { /* only sees within a */ return state; }
function b (state, action) { /* only sees within b */ return state; }
function c (state, action) { /* only sees within c */ return state; }

function ab (state, action) { /* partial state containing a and b */ return state; }
function bc (state, action) { /* partial state containing b and c */ return state; }

let rootReducer = combineReducers(
  { a, b, c },
  [ 'a', 'b', ab ],
  [ 'b', 'c', bc ]
);

부분 리듀서 및 추가 루트 리듀서에 대한 PR을 제출할 가치가 있습니까? 이것은 끔찍한 아이디어입니까, 아니면 충분한 다른 사람들에게 유용 할 수 있습니까?

할로겐 과 느릅 나무 가 이러한 문제를 어떻게 처리하는지 배우고 싶습니다. JavaScript는 여러 progammig 다이어그램이 혼합되어 있으며 우리를 여러 가지 방법으로 안내합니다. 나는 이제 FRP와 단방향 데이터 흐름 중 올바른 것이 혼란 스럽습니다.

나는 이것이 나에게도 혼란의 지점이라는 것을 알았다. 내 사용 사례 / 솔루션을 여기에 게시하십시오.

세 가지 리소스 유형 (클라이언트, 프로젝트, 작업)의 배열을 처리하는 세 가지 하위 감소 기가 있습니다. 클라이언트 ( REMOVE_CLIENT )를 삭제할 때 모든 관련 프로젝트와 작업을 삭제해야합니다. 작업은 프로젝트를 통해 클라이언트와 관련되어 있으므로 작업 감속기는 조인 논리를 수행하기 위해 프로젝트에 액세스 할 수 있어야합니다. 작업 감속기는 삭제중인 클라이언트에 속한 모든 프로젝트 ID의 목록을 가져온 다음 저장소에서 일치하는 작업을 제거해야합니다.

다음 미들웨어로이 문제를 해결했습니다.

export default store => next => action => {
  next({ ...action, getState: store.getState });
}

따라서 모든 작업은 action.getState() 를 통해 루트 저장소에 액세스 할 수 있습니다.

@ rhys-vdw 감사합니다! 정말 유용한 미들웨어 :)

@ rhys-vdw 감사합니다 – 좋은 해결책 인 것 같습니다. 예를 들어 엔터티가 두 개 이상의 다른 엔터티에서 공유되거나 삭제 중 존재하지 않는 레코드를 가리키는 경우와 같이 에지 케이스 / 참조 무결성을 어떻게 처리합니까? 이것에 대한 당신의 생각을 듣고 싶어요.
@gaearon 정규화 된 엔티티의 이러한 종류의 참조 무결성 문제를 해결하는 방법을 Redux에 문서화 한 방법이 있습니까?

특별한 방법은 없습니다. 스키마를 정의하고이 스키마를 기반으로 감속기를 생성하여이를 자동화 할 수 있다고 생각합니다. 그런 다음 항목이 삭제 될 때 "쓰레기"를 수집하는 방법을 "알게"됩니다. 그러나 이것은 모두 매우 손으로 흔들리고 구현 노력이 필요합니다 :-). 개인적으로 나는 삭제가 실제 정리를 보장하기에 충분할 정도로 자주 발생한다고 생각하지 않습니다. 일반적으로 모델의 status 필드를 뒤집고 항목을 선택할 때 삭제 된 항목을 표시하지 않도록합니다. 물론 일반적인 작업이 아닌 경우 삭제시 새로 고칠 수 있습니다.

@gaearon 초고속 답장을 하나의 가치라고 생각합니다. 특히 해당 주에 CRUD 작업이 많은 경우 해당 유령 항목이 당신을 넘어 뜨릴 수 있는지 확실하지 않습니다.

그러나 Redux 가 정규화 된 엔티티와 임베디드 엔티티를 모두 지원한다면 에이스가 될 것이라고 생각합니다. 그리고 목적에 맞는 전략을 선택할 수 있습니다. 그러나 임베디드 엔티티의 경우 Redux 문서에 따라 안티 패턴 인 nested reducers 을 사용해야한다고 생각합니다.

감속기에서 나머지 저장 상태에 액세스하는 것이 어려웠습니다. 일부 경우에는 중첩 된 combineReducers를 사용하기가 정말 어렵습니다. .parent() 또는 .root() 또는 이와 동등한 상태와 같은 나머지 상태에 액세스하는 방법이 있으면 좋을 것입니다.

감속기에서 다른 감속기의 상태에 액세스하는 것은 대부분 안티 패턴입니다.
일반적으로 다음 방법으로 해결할 수 있습니다.

• 감속기에서 해당 로직을 제거하고 선택기로 이동합니다.
• 조치에 추가 정보 전달
• 뷰 코드가 두 가지 작업을 수행하도록합니다.

감사! 동의합니다. 루트 상태를 감속기에 전달하려고 시도한 후 더 복잡해졌습니다. :-)

예, 루트 상태를 전달하는 문제는 리팩터링이 서로의 상태 모양에 결합되어 상태 구조의 리팩토링이나 변경을 복잡하게 만든다는 것입니다.

좋아, 나는 정규화 된 상태를 갖는 것의 이점을 분명히보고 내 상태 종류의 redux 부분을 DB처럼 취급한다.

나는 여전히 @gaearon (삭제를 위해 엔티티 플래그 지정) 또는 @ rhys-vdw의 접근 방식이 더 나은지 (참조를 해결하고 관련 참조를 제자리에서 제거) 생각하고 있습니다.

아이디어 / 실제 경험이 있습니까?

redux가 elm과 더 비슷하고 상태가 정규화되지 않은 경우 감속기를 상태 모양에서 분리하면 의미가 있습니다. 그러나 상태가 정규화 되었기 때문에 리듀서는 종종 앱 상태의 다른 부분에 액세스해야하는 것 같습니다.

감속기는 동작에 의존하기 때문에 이미 응용 프로그램에 전 이적으로 결합되어 있습니다. 다른 redux 애플리케이션에서 리듀서를 사소하게 재사용 할 수 없습니다.

상태 액세스를 작업으로 푸시하고 미들웨어를 사용하여 문제를 해결하는 작업은 훨씬 더 추악한 형태의 커플 링으로 보이며 감속기가 루트 상태에 직접 액세스 할 수 있습니다. 이제는 필요하지 않은 작업도 상태 모양과 결합되며 리듀서보다 더 많은 작업이 있고 변경할 곳이 더 많습니다.

상태를 뷰로 전달하는 것이 상태 모양 변경을 차단하는 것이 더 좋지만, 기능이 추가됨에 따라 추가 상태가 필요한 경우 업데이트해야하는 많은 작업만큼이나 마찬가지입니다.

리듀서가 루트 상태에 액세스하도록 허용하는 IMHO는 현재의 해결 방법보다 전체적인 커플 링이 적습니다.

@kurtharriger : 일반적인 권장 패턴은 도메인별로 Redux 상태를 구성하고 combineReducers 를 사용하여 각 도메인을 개별적으로 관리하는 것이지만 권장 사항입니다. 전체 상태를 특정 하위 리듀서 함수로 전달하는 것을 포함하여 상황을 다르게 관리하는 자신 만의 최상위 리듀서를 작성하는 것이 전적으로 가능합니다. 궁극적으로, 당신은 정말로 _ 하나의 _ 감속기 기능만을 가지고 combineReducers 는 일반적인 사용 사례에 유용한 유틸리티입니다.

비즈니스 로직 분할에 대한 Redux FAQ 답변에도이 주제에 대한 좋은 토론이 있습니다.

예, 또 다른 옵션은 하나의 거대한 함수에서 단일 감속기를 사용하거나 내장 된 것을 사용하는 대신 자신 만의 combineReducer 함수를 작성하는 것입니다.
추가 루트 상태 인수를 추가하는 내장형 combineReducers 메소드가 있으면 유용 할 수 있지만이 기능을 추가하려고 시도한 PR은 안티 패턴으로 닫혔습니다. 나는 IMHO를 제안한 대안이 훨씬 더 전체적인 결합을 초래한다는 점을 주장하고 싶었고 아마도 이것은 안티 패턴으로 간주되어서는 안됩니다. 또한 루트 상태가 추가 인수로 추가 된 경우 강제로 사용해야하는 것과는 다르므로 커플 링은 여전히 ​​옵트 인입니다.

우리는이 결합이 명시 적이기를 원합니다. 수동으로 할 때 명시 적이며 문자 그대로 N 줄의 코드이며 N은 얼마나 많은 감속기를 가지고 있는지입니다. CombineReducers를 사용하지 말고 부모 감속기를 손으로 작성하십시오.

나는 redux / react에 익숙하지 않지만 겸손하게 이것을 묻습니다. 서로의 상태에 액세스하는 구성된 감속기가 상태 모양의 서로 다른 영역 사이에 결합을 추가하기 때문에 안티 패턴이라면이 결합은 이미 mapStateToProps ( )의 연결 (), 그 함수는 루트 상태를 제공하고 구성 요소는 모든 곳에서 / 어디에서나 가져와 소품을 얻습니다.

상태 하위 트리를 캡슐화해야하는 경우 구성 요소는 해당 하위 트리를 숨기는 접근자를 통해 상태에 액세스해야합니다. 그래야 리팩토링없이 해당 범위 내부의 상태 모양을 관리 할 수 ​​있습니다.

내가 redux를 배우면서 나는 내 앱에서 장기적인 문제가 될 것이라고 생각하고 있는데, 이것은 감속기가 아니라 mapStateToProps에 의해 앱 전체에 걸쳐 상태 모양이 긴밀하게 결합되어 있습니다. 인증 사용자의 이름 (예를 들어 주석 감속기 대 인증 감속기에 의해 각각 축소됨) 저는 mapStateToProps에서도 이러한 종류의 캡슐화를 수행하는 접근 자 메서드에서 모든 상태 액세스를 래핑하려고 시도하고 있지만 잘못 짖는 것처럼 느껴집니다. 나무.

@jwhiting : 이는 특히 mapStateToProps 에서 필요한 데이터를 상태에서 추출하기 위해 "선택기 함수"를 사용하는 여러 목적 중 하나입니다. state.some.nested.field 의 위치를 ​​실제로 알아야하는 최소한의 장소 만 있도록 도형의 상태를 숨길 수 있습니다. 아직 보지 못했다면 Reselect 유틸리티 라이브러리와 Redux 문서의 Computing Derived Data 섹션을 확인하십시오.

네. 데이터 볼륨이 작지만 여전히 (손으로 쓴) 선택기를 사용하는 경우에는 다시 선택을 사용할 필요가 없습니다. 이 접근 방식에 대한 shopping-cart 예제를 확인하십시오.

@markerikson @gaearon 이 의미가 있으며 탐색하겠습니다. 감사합니다. 해당 구성 요소의 주요 관심사 (또는 모든 상태 액세스)에 대해 mapStateToProps의 선택기를 사용하면 외부 상태 모양의 변경으로부터 구성 요소를 보호 할 수 있습니다. 하지만 내 프로젝트에서 상태 캡슐화를보다 엄격하게 시행 할 수있는 방법을 찾고 싶습니다. 그래야 코드 규율이 유일한 가드가 아니며 거기에서 제안을 환영합니다.

모든 코드를 단일 감속기에 보관하는 것은
우려. 감속기가 루트에 의해 호출되면 수동으로 호출 할 수 있습니다.
내가 제안한대로 루트 상태를 명시 적으로 전달하지만
부모 감속기 계층에는 결합 감속기가 포함되어 있습니다.
밖. 그러니 찢을 필요가 없도록 좀 더 합성 가능하게 만드는 것은 어떻습니까?
나중에 나가거나 대부분의 사람들이하는 것처럼 썽크에 의지합니까?
2016 년 4 월 16 일 토요일 오후 8:27 Josh Whiting [email protected]
썼다 :

@markerikson https://github.com/markerikson @gaearon
https://github.com/gaearon 이해가되며 살펴 보겠습니다.
감사합니다. 그 밖의 모든 것에 대해 mapStateToProps에서 선택기 사용
구성 요소의 주요 관심사 (또는 모든 상태 액세스에 대한)는
이물질 모양의 변화로 인한 구성 요소. 방법을 찾고 싶습니다
하지만 내 프로젝트에서 상태 캡슐화를 더 엄격하게 시행하기 위해
그래서 코드 규율 만이 그것을 보호하고 환영합니다.
거기에 제안.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/reactjs/redux/issues/601#issuecomment -210940305

@kurtharriger : 우리 모두는 리듀서 로직의 마지막 부분을 하나의 함수로 유지하는 것은 나쁜 생각이며 작업이 어떤 식 으로든 하위 함수로 위임되어야한다는 데 동의합니다. 그러나 모든 사람은이를 수행하는 방법에 대해 서로 다른 아이디어를 갖고 있으며 자신의 응용 프로그램에 대해 서로 다른 요구를 갖게 될 것입니다. Redux는 일반적인 사용 사례에 대한 내장 유틸리티로 combineReducers 를 제공합니다. 현재 존재하는 유틸리티를 사용하고 싶지 않다면 그럴 필요가 없습니다. 모든 것을 손으로 작성하든, 아니면 combineReducers 의 변형을 직접 작성하든 상관없이 자신 만의 방식으로 감속기를 구성 할 수 있습니다.

우리는 패턴과 우려의 분리에 대해 이야기하고 있기 때문에 실제로는 관련이 있지만 대신 행동을 취하고 있습니다.

즉, 내가 여러 곳에서 볼 수있는 ajax shouldFetch 패턴은 상태 모양과 밀접하게 연결되어있는 것 같다. 예를 들어 여기 . 이 예에서 감속기를 재사용하지만 상태의 루트에 엔티티 객체가 없으면 어떻게됩니까? 그러면 해당 작업이 실패합니다. 여기서 권장하는 것은 무엇입니까? 케이스 별 조치를 추가해야합니까? 아니면 선택자를 받아들이는 액션?

@shadowii 액션 크리에이터가 선택기를 가져 오는 것은 괜찮은 것 같습니다. 선택기와 감속기를 함께 배치하여 상태 모양에 대한 지식이 해당 파일에 지역화됩니다.

다른 감속기가 동일한 작업 유형을 처리하는 데 문제가 있습니까?
예를 들어, account 및 auth 감속기가있는 경우 둘 다 LOGIN_SUCCESS 작업 유형 (인증 토큰 및 페이로드의 계정 데이터 포함)을 처리합니다. 하나는 관리하는 상태 조각 만 업데이트합니다. 나는 행동이 국가의 다른 부분에 영향을 미칠 때이 접근법을 꽤 많이 사용하는 것을 발견했습니다.

다른 감속기가 동일한 작업 유형을 처리하는 데 문제가 있습니까?

문제가 없습니다. 매우 일반적이고 유용한 패턴입니다. 사실 그것은 _reason_ 액션이 존재합니다. 만약 액션이 리듀서 1 : 1에 매핑된다면, 액션을 갖는 것은 거의 의미가 없을 것입니다.

@ rhys-vdw 게시 한 미들웨어를 사용해 보았습니다.

customMiddleare.js

const customMiddleware =  store => next => action => {
  next({ ...action, getState: store.getState });
};

그리고 내 상점 생성에는

import customMiddleware from './customMiddleware';

var store = createStore(
        rootReducer,
        initialState,
        applyMiddleware(
            reduxPromise,
            thunkMiddleware,
            loggerMiddleware,
            customMiddleware
        )
    );
return store;

다음과 같은 오류가 발생합니다.

applyMiddleware.js? ee15 : 49 Uncaught TypeError : 미들웨어는 함수가 아닙니다 (…)
(익명 함수) @ applyMiddleware.js? ee15 : 49
(익명 함수) @ applyMiddleware.js? ee15 : 48
createStore @ createStore.js? fe4c : 65
configureStore @ configureStore.js? ffde : 45
(익명 함수) @ index.jsx? fdd7 : 25
(익명 함수) @ bundle.js : 1639
webpack_require @ bundle.js : 556
fn @ bundle.js : 87 (익명 함수) @ bundle.js : 588
webpack_require @ bundle.js : 556
(익명 함수) @ bundle.js : 579
(익명 함수) @ bundle.js : 582

@ mars76 : 아마도 무언가를 올바르게 가져 오지 않았을 가능성이 높습니다. 이것이 실제로 customMiddleware.js 의 전체 내용이라면 _anything_을 내 보내지 않는 것입니다. 일반적으로 4 개의 미들웨어를 applyMiddleware 에 전달하고 있으며 그중 하나는 유효한 참조가 아닐 수 있습니다. 뒤로 물러나서 모두 제거하고 한 번에 하나씩 다시 추가하고 어떤 것이 유효하지 않은지 확인하고 이유를 파악하십시오. 가져 오기 및 내보내기 문을 확인하고 항목을 초기화하는 방법을 다시 확인하십시오.

안녕하세요,

감사합니다 @markerikson

구문을 아래와 같이 변환했는데 이제 괜찮습니다.

customMiddleware.js

export function customMiddleware(store) { return function (next) { return function (action) { next(Object.assign({}, action, { getState: store.getState })); }; }; } console.log(customMiddleware);

어떻게 내가 Action Creator 자체 (Reducer가 아님)에서 상점에 액세스하려고 시도하고 있습니다. Async 호출을해야하고 다양한 감속기에 의해 관리되는 상점 상태의 다른 부분을 전달해야합니다.

이것이 내가하는 일입니다. 이것이 올바른 접근 방식인지 확실하지 않습니다.

저는 데이터와 함께 액션을 전달하고 감속기 내부에서 이제 전체 State에 액세스 할 수 있으며 필요한 부분을 추출하고 Object를 생성하고이 데이터로 다른 액션을 전달합니다.이 데이터는 내 Action Creator에서 사용할 수 있습니다. 해당 데이터를 사용하여 Asyn 호출을하고 있습니다.

내 가장 큰 관심사는 Reducer가 이제 액션 생성기 메서드를 호출하고 있다는 것입니다.

의견을 감사합니다.

감사

@ mars76 : 다시 말하지만, 감속기 내에서 디스패치를 ​​시도해서는 안됩니다 .

액션 제작자 내부의 상점에 액세스하려면 redux-thunk 미들웨어를 사용할 수 있습니다. 또한 감속기 간의 데이터 공유에 대한 과 일반적인 썽크 사용 예제 와 함께 작성한 요점을 읽을 수도 있습니다.

@markerikson에 감사드립니다.

내 잘못이야 redux-thunk의 getState ()에 대해 몰랐습니다. 그것은 내 일을 훨씬 쉽게 만들고 내 감속기를 순수하게 만듭니다.

@gaearon 액션 생성자가 선택자를 가져 오는 것을 언급했을 때 전체 상태가 선택자에게 전달되도록 액션 생성자에게 전달된다는 것을 염두에 두 셨나요? 아니면 뭔가 빠졌나요?

@tacomanator : 참고로 Dan은 요즘 Redux 문제에서 무작위 핑에 일반적으로 응답하지 않습니다. 다른 우선 순위가 너무 많습니다.

대부분의 경우 액션 제작자에서 선택기를 사용하는 경우 썽크 내에서 수행합니다. Thunk는 getState 에 액세스 할 수 있으므로 전체 상태 트리에 액세스 할 수 있습니다.

import {someSelector} from "./selectors";

function someThunk(someParameter) {
    return (dispatch, getState) => {
        const specificData = someSelector(getState(), someParameter);

        dispatch({type : "SOME_ACTION", payload : specificData});    
    }
}

@markerikson 감사합니다. 참고로 내가 묻는 이유는 주로 리듀서로 보내는 것과는 대조적으로 유효성 검사 비즈니스 로직을 위해 선택자에서 파생 된 데이터를 사용하는 것에 관한 것이지만, 생각할 수있는 음식도 제공합니다.

감속기를 하나로 결합하는 데 사용한 빠른 해킹은

const reducers = [ reducerA, reducerB, ..., reducerZ ];

let reducer = ( state = initialState, action ) => {
    return reducers.reduce( ( state, reducerFn ) => (
        reducerFn( state, action )
    ), state );
};

여기서 reducerA 에서 reducerZ 는 개별 감속기 기능입니다.

@brianpkelley : 네, 기본적으로 https://github.com/acdlite/reduce-reducers 입니다.

@markerikson 아, 처음으로 react / redux / etc를 사용하고이 문제를 조사하는 동안이 스레드를 찾았습니다. 반쯤 끝까지 건너 뛰었습니다.

헤, 물론입니다.

참고로 " combineReducers 를) 사용해야합니까?" 라는 . 및 문서의 구조화 감속기 섹션. 또한 저의 "Practical Redux"튜토리얼 시리즈 에는 몇 가지 고급 감속기 기술을 보여주는 몇 가지 게시물이 있습니다 (7 부 및 8 부 참조).

redux-logic을 사용할 때 내 두 센트는 transform 함수의 루트 상태에서 작업을 늘리는 것입니다.

예:

const formInitLogic = createLogic({
  type: 'FORM_INIT',
  transform({ getState, action }, next) {
    const state = getState();
    next({
      ...action,
      payload: {
        ...action.payload,
        property1: state.branch1.someProperty > 5,
        property2: state.branch1.anotherProperty + state.branch2.yetAnotherProperty,
      },
    });
  },
});

나는 그것이 코드 구조에 관한 것이라고 생각합니다.
"하위 상태 작업에 직접 액세스하지 마십시오"
많은 프로젝트에서 redux를 사용한 후 가장 좋은 코드 구조는 모든 하위 상태를 완전히 분리 된 구성 요소로 처리하는 것임을 알았습니다.이 구성 요소 중 하나는 자체 폴더와 논리를 가지고 있으며이 아이디어를 구현하기 위해 다음 파일 구조를 사용합니다.

• redux 루트
  
  
  
  • reducers.js 내보내기는 모든 상태의 감속기를 결합합니다.
  
  
  • middleware.js export applyMiddleware for all middleware
  
  
  • configureStore.js createStore 사용 (reducers.js, middleware.js)
  
  
  • actions.js 는 상태 폴더에서 작업을 전달하는 작업 내보내기 <== THIS
  
  
  • state1
  
  
  • initial.js 이 파일은 초기 상태를 포함합니다 (나는 레코드를 만들기 위해 불변을 사용합니다)
  
  
  • action-types.js 이 파일에는 작업 유형이 포함되어 있습니다 (dacho를 키 미러로 사용).
  
  
  • actions.js 이 파일에는 상태 작업이 포함됩니다.
  
  
  • reducer.js 이 파일에는 상태 감속기가 포함되어 있습니다.
  
  
  • state2
  
  
  • initial.js
  
  
  • action-types.js
    
    ....
  
  

왜 ?
1- 모든 응용 프로그램에는 두 가지 유형의 작업이 있습니다.

• 상태 작업 (redux / state1 / actions.js) 이러한 작업은 상태 변경에만 책임이 있습니다. 이러한 작업을 직접 실행해서는 안됩니다. 항상 앱 작업을 사용합니다.
  
  
  
  • 앱 작업 (redux / actions.js) 이러한 작업은 일부 앱 로직을 수행하고 상태 작업을 실행할 수 있습니다.
  
  

2- 추가로이 구조를 사용하면 폴더를 복사하여 붙여넣고 이름을 변경하여 새 상태를 만들 수 있습니다.)

2 개의 감속기가 동일한 속성을 변경해야하는 경우는 어떻습니까?

다른 파일로 분할하고 싶은 감속기가 있고 http 요청이 어떤 이유로 실패 할 때 변경하는 'error'라는 속성이 있다고 가정 해 보겠습니다.

이제 어느 시점에서 감속기가 커져서 여러 감속기로 분할하기로 결정했지만 모두 '오류'속성을 변경해야합니다.

그리고 뭐?

@ Wassap124 두 감속기가 동일한 상태를 관리하는 것은 불가능합니다. 동일한 속성을 변경하려면 두 가지 작업이 필요합니까?

더 자세한 정보가 없으면 썽크를 사용하여 "오류 설정"작업을 전달하는 것이 좋습니다.

@ rhys-vdw 나는 꽤 긴 감속기를 나누려고 노력하고 있습니다.
그리고 당신의 제안과 관련하여 부작용이 없다는 규칙과 모순되지 않습니까?

@ Wassap124 , @ rhys-vdw : 명확히하기 위해, combineReducers _ 만 사용하는 경우 두 개의 감속기가 동일한 상태를 관리하는 것은 불가능합니다. 그러나 자신의 사용 사례에 맞게 다른 리듀서 로직을 작성할 수 있습니다. https://redux.js.org/recipes/structuringreducers/beyondcombinereducers를 참조

빠른 소스 설명을한다면 ...

combineReducers 는 다음과 같은 함수 서명을 반환합니다.

return function combination(state = {}, action) {

https://github.com/reduxjs/redux/blob/master/src/combineReducers.js#L145 참조

실제 감속기 객체를 참조하기 위해 클로저를 만든 후.

따라서 저장소에서 상태를 수화하고 다시로드해야하는 경우 작업을 전역 적으로 처리 할 수 ​​있도록 간단한 것을 추가 할 수 있습니다.

const globalReducerHandler = () => {
  return (state = {}, action) => {
    if (action.type === 'DO_GLOBAL_THING') {
      return globallyModifyState(state)
    }
    return reducers(state, action)
  }
}

이것은 반 패턴 일 수도 있고 아닐 수도 있지만 실용주의는 항상 더 중요했습니다.

다른 감속기에서 감속기를 호출하는 대신 (globalReducerHandler가 호출하는 감속기와 관련이 없기 때문에 안티 패턴입니다) reduceReducers 사용합니다. 이는 감속기의 경우 본질적으로 compose 입니다 문자 그대로 (Action ->) 모나드에서 구성).