Immutable.js 또는 기타를 사용하는지 궁금합니다. REDUX 것들의 소수에서 나는 내가 불변을 사용하지 상상할 수 없었다 내장했지만, 불변가 순종을하는 데 도움이 나는 꽤 많이 중첩 된 구조를 가지고 _do_.

우와. 그것을 언급하는 것은 _not_ 저에게 있어 얼마나 간과된 일입니까? 예! 우리는 불변을 사용합니다! 당신이 말했듯이, 상당한 것을 위해 그것을 사용하지 _아닌_ 상상하기 어렵습니다.

@bvaughn 내가 고심했던 영역 중 하나는 Immutable과 구성 요소 사이에 선을 그릴 위치입니다. 변경할 수 없는 개체를 구성 요소에 전달하면 순수 렌더링 데코레이터/믹스인을 매우 쉽게 사용할 수 있지만 구성 요소에 IMmutable 코드(내가 좋아하지 않는)가 생깁니다. 지금까지 나는 그냥 굴복하고 그것을 해냈지만 Immutable.js의 메소드에 직접 액세스하는 대신 render() 메소드에서 선택기를 사용하는 것 같습니까?

솔직히 이것은 우리가 아직 엄격한 정책을 정의하지 않은 것입니다. 종종 우리는 "스마트" 컨테이너에서 선택기를 사용하여 변경할 수 없는 개체의 기본 값을 추가한 다음 기본 값을 문자열, 부울 등으로 구성 요소에 전달합니다. 때때로 우리는 불변 개체를 전달하지만 그렇게 할 때 거의 항상 Record 유형을 전달하여 구성 요소가 이를 기본 개체(게터 포함)처럼 취급할 수 있도록 합니다.

나는 반대 방향으로 움직여서 액션 제작자를 더 하찮게 만듭니다. 하지만 저는 이제 막 redux를 사용하기 시작했습니다. 접근 방식에 대한 몇 가지 질문:

1) 액션 제작자를 어떻게 테스트합니까? 나는 테스트하기 쉽기 때문에 외부 서비스에 의존하지 않는 순수 동기 함수로 가능한 한 많은 논리를 이동하는 것을 좋아합니다.
2) 핫 리로딩과 함께 시간 여행을 사용합니까? react redux devtools의 깔끔한 점 중 하나는 핫 리로딩이 설정되면 스토어가 새 리듀서에 대해 모든 작업을 다시 실행한다는 것입니다. 내 논리를 액션 제작자로 옮기면 잃어 버릴 것입니다.
3) 액션 생성자가 여러 번 디스패치하여 효과를 가져온다면 상태가 잠시 동안 유효하지 않은 상태에 있다는 의미입니까? (나중에 비동기식으로 디스패치하는 것이 아니라 여러 동기식 디스패치를 ​​생각하고 있습니다.)

모든 곳에서 선택기 사용

예, 감속기가 상태의 구현 세부 사항이며 쿼리 API를 통해 구성 요소에 상태를 노출한다고 말하는 것처럼 보입니다.
다른 인터페이스와 마찬가지로 분리가 가능하고 상태를 쉽게 리팩토링할 수 있습니다.

ImmutableJS 사용

새로운 JS 구문을 사용하는 IMO에서는 일반 JS로 목록과 개체를 쉽게 수정할 수 있으므로 ImmutableJS를 더 이상 사용하는 것이 그다지 유용하지 않습니다. 속성이 많은 매우 큰 목록과 개체가 있고 성능상의 이유로 구조적 공유가 필요하지 않는 한 ImmutableJS는 엄격한 요구 사항이 아닙니다.

더 많은 일을 하세요크리에이터

@bvaughn 당신은 정말로 이 프로젝트를 봐야 합니다: https://github.com/yelouafi/redux-saga
내가 @yelouafi 에게

1) 액션 제작자를 어떻게 테스트합니까? 나는 테스트하기 쉽기 때문에 외부 서비스에 의존하지 않는 순수 동기 함수로 가능한 한 많은 논리를 이동하는 것을 좋아합니다.

위에서 이것을 설명하려고 했지만 기본적으로... "오리"와 같은 접근 방식으로 액션 제작자를 테스트하는 것이 (지금까지 나에게) 가장 의미가 있다고 생각합니다. action-creator의 결과를 디스패치하여 테스트를 시작한 다음 선택기를 사용하여 상태를 확인합니다. 이렇게 하면 단일 테스트로 액션 생성기, 해당 감속기 및 모든 관련 선택기를 다룰 수 있습니다.

2) 핫 리로딩과 함께 시간 여행을 사용합니까? react redux devtools의 깔끔한 점 중 하나는 핫 리로딩이 설정되면 스토어가 새 리듀서에 대해 모든 작업을 다시 실행한다는 것입니다. 내 논리를 액션 제작자로 옮기면 잃어 버릴 것입니다.

아니요, 우리는 시간 여행을 사용하지 않습니다. 그러나 왜 당신의 비즈니스 로직이 액션-크리에이터에 있는 것이 여기에 어떤 영향을 미치겠습니까? 애플리케이션의 상태를 업데이트하는 유일한 것은 감속기입니다. 따라서 생성된 작업을 다시 실행하면 어느 쪽이든 동일한 결과를 얻을 수 있습니다.

3) 액션 생성자가 여러 번 디스패치하여 효과를 가져온다면 상태가 잠시 동안 유효하지 않은 상태에 있다는 의미입니까? (나중에 비동기식으로 디스패치하는 것이 아니라 여러 동기식 디스패치를 ​​생각하고 있습니다.)

일시적인 무효 상태는 어떤 경우에는 실제로 피할 수 없는 것입니다. 최종 일관성이 있는 한 일반적으로 문제가 되지 않습니다. 그리고 다시 말하지만, 비즈니스 로직이 action-creators 또는 reducers에 있는지에 관계없이 상태가 일시적으로 유효하지 않을 수 있습니다. 그것은 부작용 및 상점의 특성과 더 관련이 있습니다.

새로운 JS 구문을 사용하는 IMO에서는 일반 JS로 목록과 개체를 쉽게 수정할 수 있으므로 ImmutableJS를 더 이상 사용하는 것이 그다지 유용하지 않습니다. 속성이 많은 매우 큰 목록과 개체가 있고 성능상의 이유로 구조적 공유가 필요하지 않는 한 ImmutableJS는 엄격한 요구 사항이 아닙니다.

Immutable을 사용하는 주된 이유는 업데이트를 위한 성능이나 구문상의 설탕이 아닙니다. 주된 이유는 사용자(또는 다른 사람)가 감속기 내에서 들어오는 상태를 _우연하게_ 변경하는 것을 방지하기 때문입니다. 그것은 불가능하며 불행히도 일반 JS 객체로 쉽게 수행할 수 있습니다.

@bvaughn 당신은 정말로 이 프로젝트를 봐야 합니다: https://github.com/yelouafi/redux-saga
내가 @yelouafi 에게

나는 실제로 그 프로젝트를 전에 체크 아웃했습니다 :) 비록 아직 그것을 사용하지 않았지만. 깔끔해 보입니다.

위에서 이것을 설명하려고 했지만 기본적으로... "오리"와 같은 접근 방식으로 액션 제작자를 테스트하는 것이 (지금까지 나에게) 가장 의미가 있다고 생각합니다. action-creator의 결과를 디스패치하여 테스트를 시작한 다음 선택기를 사용하여 상태를 확인합니다. 이렇게 하면 단일 테스트로 액션 생성기, 해당 감속기 및 모든 관련 선택기를 다룰 수 있습니다.

죄송합니다, 그 부분을 얻었습니다. 내가 궁금한 것은 비동기성과 상호 작용하는 테스트 부분입니다. 다음과 같은 테스트를 작성할 수 있습니다.

var store = createStore();
store.dispatch(actions.startRequest());
store.dispatch(actions.requestResponseReceived({...});
strictEqual(isLoaded(store.getState());

그러나 당신의 시험은 어떻게 생겼습니까? 이 같은?

var mock = mockFetch();
store.dispatch(actions.request());
mock.expect("/api/foo.bar").andRespond("{status: OK}");
strictEqual(isLoaded(store.getState());

아니요, 우리는 시간 여행을 사용하지 않습니다. 그러나 왜 당신의 비즈니스 로직이 액션-크리에이터에 있는 것이 여기에 어떤 영향을 미치겠습니까? 애플리케이션의 상태를 업데이트하는 유일한 것은 감속기입니다. 따라서 생성된 작업을 다시 실행하면 어느 쪽이든 동일한 결과를 얻을 수 있습니다.

코드가 변경되면 어떻게 되나요? 감속기를 변경하면 동일한 작업이 재생되지만 새 감속기가 사용됩니다. 반면에 액션 생성자를 변경하면 새 버전이 재생되지 않습니다. 따라서 두 가지 시나리오를 고려하십시오.

감속기 사용:

1) 내 앱에서 작업을 시도합니다.
2) 내 리듀서에 버그가 있어서 잘못된 상태가 됩니다.
3) 감속기의 버그를 수정하고 저장합니다.
4) 시간 여행은 새로운 감속기를 로드하고 내가 있어야 했던 상태로 나를 둡니다.

액션 크리에이터와 함께라면

1) 내 앱에서 작업을 시도합니다.
2) 액션 생성자에 버그가 있어 잘못된 액션이 생성되는 경우
3) 액션 생성기에서 버그를 수정하고 저장합니다.
4) 나는 여전히 잘못된 상태에 있습니다. 최소한 작업을 다시 시도해야 하며, 완전히 망가진 상태가 되면 새로고침해야 합니다.

일시적인 무효 상태는 어떤 경우에는 실제로 피할 수 없는 것입니다. 최종 일관성이 있는 한 일반적으로 문제가 되지 않습니다. 그리고 다시 말하지만, 비즈니스 로직이 action-creators 또는 reducers에 있는지에 관계없이 상태가 일시적으로 유효하지 않을 수 있습니다. 그것은 부작용 및 상점의 특성과 더 관련이 있습니다.

redux에 대한 내 생각은 저장소가 항상 유효한 상태라고 주장하는 것 같습니다. 감속기는 항상 유효한 상태를 취하고 유효한 상태를 생성합니다. 어떤 경우가 일관성이 없는 상태를 허용하도록 강제한다고 생각합니까?

방해해서 죄송합니다. 유효하지 않은 상태는 무엇을 의미합니까?
여기? 로드 중인 데이터 또는 실행 중인 작업이지만 아직 완료되지 않은 모양
나에게 유효한 일시적인 상태처럼.

Redux @bvaughn 및 @sompylasar 에서 일시적인 상태란 무엇을 의미합니까? 디스패치가 완료되거나 던집니다. 던지면 상태가 변경되지 않습니다.

리듀서에 코드 문제가 없는 한 Redux에는 리듀서 논리와 일치하는 상태만 있습니다. 어떻게든 전달된 모든 작업은 트랜잭션에서 처리됩니다. 전체 트리가 업데이트되거나 상태가 전혀 변경되지 않습니다.

전체 트리가 업데이트되지만 적절한 방식이 아닌 경우(예: React가 렌더링할 수 없는 상태), 작업을 올바르게 수행하지 않은 것입니다. :)

Redux에서 현재 상태는 단일 디스패치를 ​​트랜잭션 경계로 간주하는 것입니다.

그러나 동일한 트랜잭션에서 2개의 작업을 동기적으로 전달하려는 것처럼 보이는 @winstonewert 의 우려를 이해합니다. 때로는 actionCreators가 여러 작업을 전달하고 모든 작업이 올바르게 실행되기를 기대하기 때문입니다. 2개의 작업이 전달되고 두 번째 작업이 실패하면 첫 번째 작업만 적용되어 "일관되지 않음"으로 간주할 수 있는 상태가 됩니다. @winstonewert 는 두 번째 작업 디스패치가 실패하면 두 작업을 롤백하기를 원할 것입니다.

@winstonewert 내부 프레임워크에서 이와 같은 것을 구현했으며 지금까지는 잘 작동합니다. https://github.com/stample/atom-react/blob/master/src/atom/atom.js
또한 렌더링 오류를 처리하고 싶었습니다. 상태를 성공적으로 렌더링할 수 없는 경우 UI 차단을 피하기 위해 상태가 롤백되기를 원했습니다. 불행히도 다음 릴리스 까지 React는 렌더 메소드가 오류를 던질 때 매우 나쁜 일을 하므로 그다지 유용하지는 않지만 미래에는 될 수 있습니다.

매장에서 미들웨어를 사용한 트랜잭션에서 여러 동기화 디스패치를 ​​허용할 수 있다고 확신합니다.

그러나 일반적으로 redux 저장소가 상태를 렌더링하려고 할 때 이미 "커밋"되어 있기 때문에 렌더링 오류가 발생한 경우 상태를 롤백할 수 있는지 확신할 수 없습니다. 내 프레임워크에는 렌더링을 트리거하고 결국 모든 렌더링 오류에서 롤백하는 데 사용하는 "beforeTransactionCommit" 후크가 있습니다.

@gaearon 이런 기능을 지원할 계획이 있는지, 현재 API로 가능한지 궁금합니다.

redux-batched-subscribe 는 실제 트랜잭션을 허용하지 않고 렌더링 수를 줄이는 것 같습니다. 내가 보는 것은 구독 수신기가 마지막에 한 번만 실행되는 경우에도 각 디스패치 후에 저장소 "커밋"이 된다는 것입니다.

완전한 거래 지원이 필요한 이유는 무엇입니까? 사용 사례를 이해하지 못하는 것 같습니다.

@gaearon 아직 확실하지 않지만 @winstonewert 사용 사례 에 대해 더 알게 되어

아이디어는 dispatch([a1,a2]) 수행할 수 있고 a2가 실패하면 a1이 발송되기 전의 상태로 롤백한다는 것입니다.

과거에는 여러 작업을 동기적으로 전달하는 경우가 많았고(예: 단일 onClick 수신기에서 또는 actionCreator에서) 주로 전달되는 모든 작업이 끝날 때만 렌더링을 호출하는 방법으로 트랜잭션을 구현했습니다. redux-batched-subscribe 프로젝트에 의해 다른 방식으로 해결되었습니다.

내 사용 사례에서 트랜잭션에서 실행하는 데 사용한 작업은 대부분 불필요한 렌더링을 피하기 위한 것이지만 작업은 독립적으로 의미가 있으므로 두 번째 작업에 대해 디스패치가 실패하더라도 첫 번째 작업을 롤백하지 않으면 여전히 일관된 상태를 제공합니다( 그러나 계획된 것이 아닐 수도 있습니다...). 누군가가 전체 롤백이 유용한 사용 사례를 생각해 낼 수 있는지 잘 모르겠습니다.

그러나 렌더링이 실패하면 렌더링할 수 없는 상태에서 진행을 시도하는 대신 렌더링이 실패하지 않은 마지막 상태로 롤백을 시도하는 것이 합리적이지 않습니까?

간단한 감속기 인핸서가 작동합니까? 예

const enhanceReducerWithTheAbilityToConsumeMultipleActions = (reducer =>
  (state, actions) => (typeof actions.reduce === 'function'
    ? actions.reduce(reducer, state)
    : reducer(state, actions)
  )
)

이를 통해 저장소에 배열을 전달할 수 있습니다. 인핸서는 개별 작업의 압축을 풀고 이를 각 리듀서에 공급합니다.

예, 존재합니다: https://github.com/tshelburne/redux-batched-actions

오 @gaearon 몰랐네요 . 매우 유사한 사용 사례를 다른 방식으로 해결하려고 하는 2개의 고유한 프로젝트가 있다는 것을 알지 못했습니다.

• https://github.com/tshelburne/redux-batched-actions
• https://github.com/tappleby/redux-batched-subscribe

둘 다 불필요한 렌더링을 피할 수 있지만 첫 번째는 모든 일괄 처리된 작업을 롤백하고 두 번째는 실패한 작업만 적용하지 않습니다.

@gaearon 앗 ,

Action Creators는 불순한 코드를 나타냅니다.

나는 아마도 대부분의 사람들만큼 Redux에 대한 실제 경험이 많지 않을 것입니다. 그러나 첫눈에 나는 "액션 크리에이터에서는 더 많이 하고 리듀서에서는 덜 하기"에 동의하지 않을 수 있습니다. 회사.

Flux 패턴이 도입된 Hacker Way: Rethinking Web App Development at Facebook 에서 Flux를 발명하게 된 바로 그 문제는 명령형 코드입니다.

이 경우 I/O를 수행하는 Action Creator는 명령형 코드입니다.

우리는 직장에서 Redux를 사용하지 않지만 내가 일하는 곳에서는 세분화된 작업(물론 모두 자체적으로 의미가 있음)을 사용하고 일괄적으로 트리거했습니다. 예를 들어 메시지를 클릭하면 OPEN_MESSAGE_VIEW , FETCH_MESSAGE , MARK_NOTIFICATION_AS_READ 세 가지 작업이 트리거됩니다.

그런 다음 이러한 "낮은 수준의" 작업은 상점 내부에 어떤 값을 설정하기 위한 "명령" 또는 "설정자" 또는 "메시지"에 불과하다는 것이 밝혀졌습니다. 다시 돌아가서 MVC를 사용하고 계속 이렇게 하면 더 간단한 코드로 끝날 수도 있습니다.

어떤 의미에서 Action Creators는 순수 코드를 나타내는 반면 Reducers(및 Selector)는 순수 코드를 나타냅니다 . Haskell 사람들은 덜 불순한 코드와 더 순수한 코드를 갖는 것이 더 낫다 는 것을 알아냈습니다.

예를 들어 내 사이드 ​​프로젝트(Redux 사용)에서 웹킷의 음성 인식 API를 사용합니다. 말을 하면 onresult 이벤트가 발생합니다. 두 가지 선택이 있습니다. 이러한 이벤트는 어디에서 처리됩니까?

• 액션 생성자가 이벤트를 먼저 처리한 다음 스토어로 보내도록 합니다.
• 이벤트 개체를 저장소로 보내기만 하면 됩니다.

나는 두 번째로 갔다. 그냥 원시 이벤트 객체를 저장소로 보내라.

그러나 Redux dev-tools는 비일반 개체가 저장소로 전송되는 것을 좋아하지 않는 것 같습니다. 그래서 저는 이러한 이벤트 개체를 일반 개체로 변환하기 위해 액션 생성자에 몇 가지 작은 로직을 추가했습니다. (액션 생성기의 코드는 너무 간단하여 잘못될 수 없습니다.)

그런 다음 감속기는 이러한 매우 원시적인 이벤트를 결합하고 말한 내용의 스크립트를 작성할 수 있습니다. 그 로직은 순수 코드 안에 있기 때문에 (리듀서를 핫 리로딩하여) 라이브로 아주 쉽게 조정할 수 있습니다.

@dtinth를 지원하고 싶습니다. 행동은 우리가 이러한 사건에 어떻게 반응하고 싶은지가 아니라 현실 세계에서 일어난 사건을 나타내야 합니다. 특히 CQRS를 참조하십시오. 우리는 실제 사건에 대한 많은 세부 사항을 기록하고 싶고, 앞으로 감속기가 개선되고 새로운 논리로 오래된 사건을 처리할 가능성이 높습니다.

@dtinth @denis-sokolov 저도 그 점에 동의합니다. Btw 내가 redux-saga 프로젝트를 참조할 때 나는 actionCreators를 시간이 지남에 따라 점점 더 복잡하게 만드는 아이디어에 반대한다는 것을 분명히 하지 않았을 수 있습니다.

Redux-saga 프로젝트는 @dtinth에서 설명하는 것을 수행하려는 시도 미묘한 차이가 있습니다. 액션 로그에 발생한 모든 원시 이벤트를 작성하면 이 액션 로그의 리듀서에서 모든 상태를 쉽게 계산할 수 있다고 말하고 싶은 것 같습니다. 이것은 절대적으로 사실이며 작업 로그가 명시적이지 않고 시간이 지남에 따라 감속기가 너무 복잡해져서 앱을 유지 관리하기가 매우 어려워질 때까지 한동안 그 경로를 택했습니다.

Redux 사가 토론으로 이어지는 원래 토론의 이 지점을 볼 수 있습니다. https://github.com/paldepind/functional-frontend-architecture/issues/20#issuecomment -162822909

해결하는 유스케이스

명백한 TodoCreated 이벤트가 있는 Todo 앱이 있다고 상상해 보십시오. 그런 다음 앱 온보딩을 코딩하도록 요청합니다. 사용자가 할 일을 생성하면 팝업으로 축하해야 합니다.

"불순한" 방법:

이것은 @bvaughn 이 선호하는 것입니다.

function createTodo(todo) {
   return (dispatch, getState) => {
       dispatch({type: "TodoCreated",payload: todo});
       if ( getState().isOnboarding ) {
         dispatch({type: "ShowOnboardingTodoCreateCongratulation"});
       }
   }
}

나는 이 접근 방식이 앱 보기의 레이아웃과 밀접하게 결합된 액션 생성기를 만들기 때문에 마음에 들지 않습니다. actionCreator가 결정을 내리기 위해 UI 상태 트리의 구조를 알아야 한다고 가정합니다.

"원시 이벤트에서 모든 것을 계산" 방식:

이것은 @denis-sokolov @dtinth 가 선호하는 것입니다:

function onboardingTodoCreateCongratulationReducer(state = defaultState, action) {
  var isOnboarding = isOnboardingReducer(state.isOnboarding,action);
  switch (action) {
    case "TodoCreated": 
        return {isOnboarding: isOnboarding, isCongratulationDisplayed: isOnboarding}
    default: 
        return {isOnboarding: isOnboarding, isCongratulationDisplayed: false}
  }
}

예, 축하 메시지를 표시해야 하는지 아는 감속기를 만들 수 있습니다. 그러나 팝업이 표시되었다는 조치도 없이 표시되는 팝업이 있습니다. 내 자신의 경험에 따르면(그리고 여전히 그렇게 하는 레거시 코드가 있음) 매우 명시적으로 만드는 것이 항상 더 좋습니다. DISPLAY_CONGRATULATION 작업이 실행되지 않으면 축하 팝업을 표시하지 마십시오. 명시적은 암시적보다 유지 관리가 훨씬 쉽습니다.

단순화된 사가 방식.

redux-saga는 생성기를 사용하며 익숙하지 않은 경우 약간 복잡해 보일 수 있지만 기본적으로 다음과 같은 간단한 구현을 사용하면 다음과 같이 작성할 수 있습니다.

function createTodo(todo) {
   return (dispatch, getState) => {
       dispatch({type: "TodoCreated",payload: todo});
   }
}

function onboardingSaga(state, action, actionCreators) {
  switch (action) {
    case "OnboardingStarted": 
        return {onboarding: true, ...state};
    case "OnboardingStarted": 
        return {onboarding: false, ...state};
    case "TodoCreated": 
        if ( state.onboarding ) dispatch({type: "ShowOnboardingTodoCreateCongratulation"});
        return state;
    default: 
        return state;
  }
}

saga는 이벤트를 수신하고 효과를 생성할 수 있는 상태 저장 액터입니다. 여기에서 이것이 무엇인지에 대한 아이디어를 제공하기 위해 불순한 감속기로 구현되지만 실제로는 redux-saga 프로젝트에 없습니다.

약간 복잡한 규칙:

초기 규칙을 처리하면 모든 것에 대해 매우 명시적이지 않습니다.
위의 구현을 보면 온보딩 중에 할 일을 만들 때마다 축하 팝업이 열리는 것을 알 수 있습니다. 대부분의 경우 온보딩 중에 발생하는 첫 번째 생성된 할일에 대해서만 열리길 원하고 모든 할일이 아니라 열리길 원할 것입니다. 또한 사용자가 결국 처음부터 온보딩을 다시 할 수 있도록 하고 싶습니다.

온보딩이 점점 더 복잡해짐에 따라 시간이 지남에 따라 3가지 구현 모두에서 코드가 어떻게 지저분해졌는지 알 수 있습니까?

redux-saga 방식

redux-saga와 위의 온보딩 규칙을 사용하면 다음과 같이 작성할 수 있습니다.

function* onboarding() {
  while ( true ) {
    take(ONBOARDING_STARTED)
    take(TODO_CREATED)
    put(SHOW_TODO_CREATION_CONGRATULATION)
    take(ONBOARDING_ENDED)
  }
}

위의 솔루션보다 훨씬 간단한 방법으로 이 사용 사례를 해결한다고 생각합니다. 내가 틀렸다면 더 간단한 구현을 알려주십시오. :)

당신은 불순한 코드에 대해 이야기했고 이 경우에는 테이크/풋 효과가 실제로 데이터이기 때문에 Redux-saga 구현에 불순함이 없습니다. take() 가 호출되면 실행되지 않고 실행할 효과의 설명자를 반환하고 어느 시점에서 인터프리터가 시작되므로 무용담을 테스트하기 위해 모의가 필요하지 않습니다. 당신이 Haskell을 하는 기능적인 개발자라면 Free / IO 모나드를 생각하십시오.

이 경우 다음을 허용합니다.

• 복잡한 actionCreator를 피하고 getState 에 의존하게 만드십시오.
• 암시적을 더 명시적으로 만들기
• 횡단 논리(위의 온보딩과 같은)를 핵심 비즈니스 도메인(할 일 생성)에 결합하지 마십시오.

또한 해석 계층을 제공하여 원시 이벤트를 보다 의미 있고 높은 수준의 이벤트로 변환할 수 있습니다(ELM이 이벤트를 버블링할 때 래핑하는 것과 약간 유사).

예:

• "TIMELINE_SCROLLED_NEAR-BOTTOM"이(가) "NEXT_PAGE_LOADED"로 이어질 수 있습니다.
• 오류 코드가 401인 경우 "REQUEST_FAILED"로 인해 "USER_DISCONNECTED"가 발생할 수 있습니다.
• "HASHTAG_FILTER_ADDED"가 "CONTENT_RELOADED"로 이어질 수 있음

오리를 사용하여 모듈식 앱 레이아웃을 달성하려는 경우 오리를 함께 결합하는 것을 방지할 수 있습니다. 사가는 연결점이 됩니다. 오리는 원시 이벤트를 알아야 하고 무용담은 이러한 원시 이벤트를 해석합니다. 이것은 duck1 프로젝트를 다른 컨텍스트에서 더 쉽게 재사용할 수 있도록 하기 때문에 duck1이 duck2의 직접 작업을 디스패치하는 것보다 훨씬 낫습니다. 그러나 결합 지점이 actionCreators에서도 가능하다고 주장할 수 있으며 이것이 오늘날 대부분의 사람들이 하고 있는 일입니다.

@slorber 이것은 훌륭한 예입니다! 시간을 내어 각 접근 방식의 장점과 단점을 명확하게 설명해주셔서 감사합니다. (나는 그것이 문서에 있어야한다고 생각합니다.)

나는 비슷한 아이디어를 탐구하곤 했습니다. 기본적으로 이것은 아무 것도 렌더링하지 않지만( render: () => null ) 이벤트를 수신하고(예: 상점에서) 다른 부작용을 유발하는 React 구성 요소입니다. 그런 다음 해당 작업자 구성 요소는 응용 프로그램 루트 구성 요소 내부에 배치됩니다. 복잡한 부작용을 처리하는 또 다른 미친 방법입니다. :stuck_out_tongue:

내가 자는 동안 여기에서 많은 토론을 했습니다.

@winstonewert , 당신은 시간 여행과 버그가 있는 코드 재생에 대해 좋은 지적을 했습니다. 특정 유형의 버그/변경 사항은 어느 쪽이든 시간 여행에서 작동하지 않을 것이라고 생각하지만 전반적으로 당신이 옳다고 생각합니다.

@dtinth , 죄송합니다만, 귀하의 의견 대부분을 따르고 있지 않습니다. action-creator/reducer "ducks" 코드의 일부는 데이터를 가져와야 한다는 점에서 불순해야 합니다. 그 이상으로 당신은 나를 잃었습니다. 내 초기 게시물의 주요 목적 중 하나는 실용주의 중 하나였습니다.

@winstonewert 는 "redux에 대한 내 생각은 저장소가 항상 유효한 상태라고 주장하는 것 같습니다."라고 말했습니다.
@slorber 는 "Redux @bvaughn 및 @sompylasar 에서 일시적인 상태란 무엇을 의미합니까? 디스패치가 완료되거나 던집니다. 던지면 상태가 변경되지 않습니다."

나는 우리가 다른 것에 대해 생각하고 있다고 확신합니다. 내가 "일시적인 무효 상태"라고 말할 때 나는 다음과 같은 유스 케이스를 언급하고 있었습니다. 예를 들어, 나와 동료는 최근 redux-search 를 출시했습니다. 이 검색 미들웨어는 검색 가능한 항목 모음에 대한 변경 사항을 수신한 다음 검색을 위해 (재)인덱싱합니다. 사용자가 필터 텍스트를 제공하면 redux-search는 사용자의 텍스트와 일치하는 리소스 uid 목록을 반환합니다. 따라서 다음을 고려하십시오.

응용 프로그램 저장소에 [{id: 1, name: "Alex"}, {id: 2, name: "Brian"}, {id: 3, name: "Charles"}] 같은 몇 가지 검색 가능한 개체가 포함되어 있다고 상상해 보십시오. 사용자가 필터 텍스트 "e"를 입력했으므로 검색 미들웨어에는 ID 1과 3의 배열이 포함됩니다. 이제 사용자 1(Alex)이 로컬에서 사용자 작업에 대한 응답으로 삭제되거나 더 이상 해당 사용자 레코드를 포함하지 않습니다. 리듀서가 사용자 컬렉션을 업데이트하는 시점에서 redux-search가 컬렉션에 더 이상 존재하지 않는 ID를 참조하기 때문에 스토어가 일시적으로 유효하지 않습니다. 미들웨어가 다시 실행되면 잘못된 상태를 수정합니다. 이러한 종류의 일은 트리의 한 노드가 다른 노드와 관련되어 있을 때마다 발생할 수 있습니다.

@slorber 는 "액션 작성자가 앱 보기의 레이아웃과 밀접하게 연결되기 때문에 이 접근 방식이 마음에 들지 않습니다. 이는 actionCreator가 결정을 내리기 위해 UI 상태 트리의 구조를 알아야 한다고 가정합니다."라고 말했습니다.

액션 생성자를 "앱 보기의 레이아웃에" 결합하는 접근 방식이 의미하는 바를 이해하지 못합니다. 상태 트리는 UI에 _drives_(또는 알려줍니다). 이것이 Flux의 주요 목적 중 하나입니다. 그리고 액션 생성자와 리듀서는 정의에 따라 해당 상태와 연결되어 있습니다(UI와는 연결되지 않음).

내가 선호하는 것으로 작성한 예제 코드는 내가 염두에 둔 것이 아닙니다. 어쩌면 내가 나 자신을 잘 설명하지 못했을 수도 있습니다. 이와 같은 논의의 어려움은 일반적으로 단순하거나 일반적인 예에서 나타나지 않는다는 것입니다. (예를 들어 표준 TODO MVC 앱은 이와 같은 미묘한 논의를 하기에 충분히 복잡하지 않습니다.)

마지막 요점을 명확하게 하기 위해 편집 했습니다.

Btw @slorber 는 내가 염두에 두었던 것의 예입니다. 약간 인위적입니다.

상태에 많은 노드가 있다고 가정해 보겠습니다. 이러한 노드 중 하나는 공유 리소스를 저장합니다. ("공유"란 로컬로 캐시되고 애플리케이션 내의 여러 페이지에서 액세스하는 리소스를 의미합니다.) 이러한 공유 리소스에는 고유한 작업 생성자와 감속기("덕")가 있습니다. 다른 노드는 특정 애플리케이션 페이지에 대한 정보를 저장합니다. 귀하의 페이지에는 자체 오리도 있습니다.

귀하의 페이지가 최신의 가장 뛰어난 것을 로드하고 사용자가 편집할 수 있도록 허용해야 한다고 가정해 보겠습니다. 다음은 이러한 상황에 사용할 수 있는 액션 생성자 접근 방식의 예입니다.

import { fetchThing, thingSelector } from 'resources/thing/duck'
import { showError } from 'messages/duck'

export function fetchAndProcessThing ({ params }): Object {
  const { id } = params
  return async ({ dispatch, getState }) => {
    try {
      await dispatch(fetchThing({ id }))

      const thing = thingSelector(getState())

      dispatch({ type: 'PROCESS_THING', thing })
    } catch (err) {
      dispatch(showError(`Invalid thing id="${id}".`))
    }
  }
}

@winstonewert 는 두 번째 작업 디스패치가 실패하면 두 작업을 롤백하기를 원할 것입니다.

아니요. 두 가지 작업을 전달하는 작업 작성자를 작성하지 않을 것입니다. 두 가지를 수행하는 단일 작업을 정의합니다. OP는 내가 싫어하는 일시적인 유효하지 않은 상태를 허용하는 더 작은 작업을 전달하는 작업 작성자를 선호하는 것 같습니다.

리듀서가 사용자 컬렉션을 업데이트하는 시점에서 redux-search가 컬렉션에 더 이상 존재하지 않는 ID를 참조하기 때문에 스토어가 일시적으로 유효하지 않습니다. 미들웨어가 다시 실행되면 잘못된 상태를 수정합니다. 이러한 종류의 일은 트리의 한 노드가 다른 노드와 관련되어 있을 때마다 발생할 수 있습니다.

이것은 실제로 나를 괴롭히는 종류의 케이스입니다. 내 생각에 인덱스는 이상적으로는 감속기 또는 선택기에 의해 완전히 처리되는 것입니다. 검색을 최신 상태로 유지하기 위해 추가 작업을 보내야 하는 것은 덜 순수한 redux 사용으로 보입니다.

OP는 내가 싫어하는 일시적인 유효하지 않은 상태를 허용하는 더 작은 작업을 전달하는 작업 작성자를 선호하는 것 같습니다.

정확히. 상태 트리의 작업 생성자의 노드와 관련하여 단일 작업을 선호합니다. 그러나 단일 개념적 사용자 "작업"이 상태 트리의 여러 노드에 영향을 미치는 경우 여러 작업을 전달해야 합니다. 각 작업을 개별적으로 호출하거나(_bad_라고 생각함) 단일 작업 생성자가 작업을 발송하도록 할 수 있습니다(보기 레이어에서 해당 정보를 숨기기 때문에 _better_라고 생각하는 redux-thunk 방식).

이것은 실제로 나를 괴롭히는 종류의 케이스입니다. 내 생각에 인덱스는 이상적으로는 감속기 또는 선택기에 의해 완전히 처리되는 것입니다. 검색을 최신 상태로 유지하기 위해 추가 작업을 보내야 하는 것은 덜 순수한 redux 사용으로 보입니다.

추가 작업을 발송하지 않습니다. 검색은 미들웨어입니다. 자동입니다. 그러나 트리의 두 노드가 일치하지 않을 때 일시적인 상태가 존재합니다.

@bvaughn 아, 순수주의자

음, 순수 코드는 데이터 가져오기 및 기타 부작용/IO와 관련이 있는 반면 순수 코드는 부작용을 유발할 수 없습니다. 순수 코드와 순수 코드를 비교하려면 이 표 를 참조하세요.

Flux 모범 사례에 따르면 작업은 "사용자의 작업을 설명해야 하며 설정자가 아닙니다." Flux 문서 는 또한 이러한 작업이 어디에서 왔는지 추가로 암시했습니다.

응용 프로그램과 상호 작용하는 사람을 통해 또는 웹 API 호출을 통해 새 데이터가 시스템에 입력되면 해당 데이터는 새 데이터 필드와 특정 작업 유형을 포함하는 개체 리터럴인 작업으로 패키징됩니다.

기본적으로 조치는 "발생해야 할 일"이 아니라 "일어난 일"을 설명하는 사실/데이터입니다. 상점은 다른 부작용 없이 동기적이고 예측 가능하게 이러한 조치에만 대응할 수 있습니다. 다른 모든 부작용은 액션 제작자(또는 sagas :wink:)에서 처리해야 합니다.

예시

나는 이것이 최선의 방법이거나 다른 어떤 방법보다 더 낫다거나 심지어 좋은 방법이라고 말하는 것이 아닙니다. 그러나 이것이 내가 현재 가장 좋은 방법이라고 생각하는 것입니다.

예를 들어 사용자가 원격 서버에 연결해야 하는 스코어보드를 보고 싶어한다고 가정해 보겠습니다. 다음은 발생해야 하는 일입니다.

• 사용자가 스코어보드 보기 버튼을 클릭합니다.
• 스코어보드 보기는 로딩 표시기와 함께 표시됩니다.
• 스코어보드를 가져오기 위해 서버에 요청이 전송됩니다.
• 응답을 기다리십시오.
• 성공하면 스코어보드를 표시합니다.
• 실패하면 스코어보드가 닫히고 오류 메시지와 함께 메시지 상자가 나타납니다. 사용자가 닫을 수 있습니다.
• 사용자는 스코어보드를 닫을 수 있습니다.

액션이 사용자의 액션이나 서버 응답의 결과로만 스토어에 도달할 수 있다고 가정하면 5개의 액션을 생성할 수 있습니다.

• SCOREBOARD_VIEW (사용자가 스코어보드 보기 버튼을 클릭한 결과)
• SCOREBOARD_FETCH_SUCCESS (서버의 성공적인 응답 결과)
• SCOREBOARD_FETCH_FAILURE (서버의 오류 응답 결과)
• SCOREBOARD_CLOSE (사용자가 닫기 버튼을 클릭한 결과)
• MESSAGE_BOX_CLOSE (사용자가 메시지 상자의 닫기 버튼을 클릭한 결과)

이 5가지 작업은 위의 모든 요구 사항을 처리하기에 충분합니다. 처음 4개의 작업은 "오리"와 아무 관련이 없음을 알 수 있습니다. 모든 작업 은 외부 세계에서 발생한 일만 설명 MESSAGE_BOX_OPEN 액션을 가지고 있지 않습니다. 왜냐하면 그것은 "일어난 일"이 아니기 때문입니다(비록 그것이 일어나야 하지만).

상태 트리를 변경하는 유일한 방법은 발생한 일을 설명하는 객체인 작업을 내보내는 Redux의 README

그들은 다음 액션 제작자와 함께 붙어 있습니다.

function viewScoreboard () {
  return async function (dispatch) {
    dispatch({ type: 'SCOREBOARD_VIEW' })
    try {
      const result = fetchScoreboardFromServer()
      dispatch({ type: 'SCOREBOARD_FETCH_SUCCESS', result })
    } catch (e) {
      dispatch({ type: 'SCOREBOARD_FETCH_FAILURE', error: String(e) })
    }
  }
}
function closeScoreboard () {
  return { type: 'SCOREBOARD_CLOSE' }
}

그러면 저장소의 각 부분(리듀서로 관리)이 다음 작업에 반응할 수 있습니다.

| 저장/감속기의 일부 | 행동 |
| --- | --- |
| 스코어보드보기 | SCOREBOARD_VIEW 에 대한 가시성 업데이트, SCOREBOARD_CLOSE 및 SCOREBOARD_FETCH_FAILURE 에 대한 false |
| 스코어보드 로딩 표시기 | SCOREBOARD_VIEW 에 대한 가시성 업데이트, SCOREBOARD_FETCH_* 에 대한 false |
| 스코어보드데이터 | SCOREBOARD_FETCH_SUCCESS 에 매장 내 데이터 업데이트 |
| 메시지 상자 | 사실 및 저장에 대한 메시지에 대한 업데이트 가시성 SCOREBOARD_FETCH_FAILURE , 그리고 거짓으로 업데이트 가시성 MESSAGE_BOX_CLOSE |

보시다시피, 단일 작업은 상점의 많은 부분에 영향을 줄 수 있습니다. 상점에는 명령(무엇을 해야 합니까?)보다는 작업(무슨 일이 일어났습니까?)에 대한 높은 수준의 설명만 제공됩니다. 결과적으로:

1. 오류를 찾아내는 것이 더 쉽습니다.

아무 것도 메시지 상자의 상태에 영향을 줄 수 없습니다. 어떤 이유로든 열라고 말할 수 있는 사람은 아무도 없습니다. 구독한 항목(사용자 작업 및 서버 응답)에만 반응합니다.

예를 들어 서버가 점수판을 가져오지 않고 메시지 상자가 나타나지 않으면 SHOW_MESSAGE_BOX 액션이 디스패치되지 않는 이유를 찾을 필요가 없습니다. 메시지 상자가 SCOREBOARD_FETCH_FAILURE 작업을 제대로 처리하지 못한 것이 분명해집니다.

수정은 사소하고 핫 리로드되고 시간 여행이 될 수 있습니다.

1. 액션 생성자와 리듀서는 별도로 테스트할 수 있습니다.

상점의 반응에 상관없이 액션 제작자가 외부 세계에서 일어나는 일을 올바르게 설명했는지 테스트할 수 있습니다.

같은 방식으로 리듀서는 외부 세계의 동작에 적절하게 반응하는지 여부를 간단히 테스트할 수 있습니다.

(통합 테스트는 여전히 매우 유용합니다.)

걱정 마. :) 추가 설명에 감사드립니다. 실제로 우리가 여기에 동의하는 것처럼 들립니다. 예제 action-creator viewScoreboard 를 보면 바로 위의 예제 action-creator fetchAndProcessThing 와 매우 유사합니다.

액션 생성자와 리듀서는 별도로 테스트할 수 있습니다.

나는 이것에 동의하지만 종종 함께 테스트하는 것이 더 실용적인 의미가 있다고 생각합니다. 당신의 행동이나 감속기(둘 다)가 매우 간단할 가능성이 높기 때문에 간단한 것을 단독으로 테스트할 때의 노력 대비 수익은 다소 낮습니다. 그래서 액션 생성기, 감속기 및 관련 선택기를 함께 테스트할 것을 제안했습니다("오리"로).

그러나 단일 개념적 사용자 "작업"이 상태 트리의 여러 노드에 영향을 미치는 경우 여러 작업을 전달해야 합니다.

그것이 바로 당신이하는 일이 redux에 대한 모범 사례로 간주되는 것과 다르다고 생각하는 부분입니다. 표준 방법은 상태 트리의 여러 노드가 응답하는 하나의 작업을 갖는 것입니다.

아, 흥미로운 관찰 @winstonewert. 우리는 각 "ducks" 번들에 대해 고유한 유형 상수를 사용하는 패턴을 따르고 있으므로 확장자는 형제 작업 생성자가 전달한 작업에만 응답합니다. 처음에는 액션에 반응하는 임의의 리듀서에 대해 어떻게 느끼는지 솔직히 잘 모르겠습니다. 약간 나쁜 캡슐화 같은 느낌이 듭니다.

우리는 각 "ducks" 번들에 대해 고유한 유형 상수를 사용하는 패턴을 따랐습니다.

문서의 어느 곳에서도 이를 보증하지 않는다는 점에 유의하십시오. ;-) 그것이 나쁘다고 말하지는 않지만 사람들에게 Redux에 대해 때때로 잘못된 아이디어를 제공합니다.

따라서 확장자는 형제 작업 생성자가 전달한 작업에만 응답합니다.

Redux에는 감속기/액션 생성기 페어링과 같은 것이 없습니다. 그것은 순전히 오리의 일입니다. 어떤 사람들은 그것을 좋아하지만 Redux/Flux 모델의 근본적인 강점을 흐리게 합니다. 상태 돌연변이는 서로 분리되고 이를 일으키는 코드에서 분리됩니다.

처음에는 액션에 반응하는 임의의 리듀서에 대해 어떻게 느끼는지 솔직히 잘 모르겠습니다. 약간 나쁜 캡슐화 같은 느낌이 듭니다.

캡슐화 경계를 고려하는 항목에 따라 다릅니다. 액션은 앱에서 전역이고 괜찮은 것 같아요. 복잡한 제품 요구 사항 때문에 앱의 한 부분이 다른 부분의 작업에 반응하기를 원할 수 있으며 우리는 이것이 괜찮다고 생각합니다. 커플링은 최소화됩니다. 사용자가 의존하는 것은 문자열과 작업 개체 모양뿐입니다. 이점은 액션 제작자와 많은 연결을 만들지 않고도 앱의 다른 부분에서 액션의 새로운 파생물을 쉽게 도입할 수 있다는 것입니다. 컴포넌트는 액션이 ​​디스패치될 때 정확히 무슨 일이 일어나는지 알지 못합니다. 이것은 리듀서 쪽에서 결정됩니다.

따라서 공식 권장 사항은 먼저 동일한 작업에 다른 리듀서가 응답하도록 하는 것입니다. 어색해지면 반드시 별도의 액션 크리에이터를 만드세요. 그러나 이 접근 방식으로 시작하지 마십시오.

선택기를 사용하는 것이 좋습니다. 사실 상태에서 읽는 유지 기능("선택기")을 감속기와 함께 내보내고 구성 요소의 상태 구조를 하드코딩하는 대신 항상 mapStateToProps 사용하는 것이 좋습니다. 이렇게 하면 내부 상태 모양을 쉽게 변경할 수 있습니다. 성능을 위해 reselect 를 사용할 수 있지만(꼭 그런 것은 아니지만) shopping-cart 예제와 같이 순진하게 선택기를 구현할 수도 있습니다.

아마도 그것은 당신이 명령형 스타일로 프로그래밍하는지 아니면 반응형 스타일로 프로그래밍하는지에 달려 있습니다. 오리를 사용하면 액션과 리듀서가 고도로 결합되어 더 명령적인 액션을 장려할 수 있습니다.

• 명령형 스타일에서 상점은 SHOW_MESSAGE_BOX 또는 SHOW_ERROR 와 같이 "할 일"이 제공됩니다.
• 반응형 스타일에서 상점에는 "발생한 사실"이 제공됩니다(예: DATA_FETCHING_FAILED 또는 USER_ENTERED_INVALID_THING_ID . 그에 따라 매장이 반응합니다.

이전 예에서는 사실이 아니기 때문에 SHOW_MESSAGE_BOX action 또는 showError('Invalid thing id="'+id+'"') action creator가 없습니다. 명령입니다.

그 사실이 저장소에 들어오면 그 사실을 순수 리듀서 내에서 명령으로 변환할 수 있습니다. 예를 들어

// type Command = State → State
// :: Action → Command
function interpretAction (action) {
  switch (action.type) {
  case 'DATA_FETCHING_FAILED':
    return showErrorMessage('Data fetching failed')
    break
  case 'USER_ENTERED_INVALID_THING_ID':
    return showErrorMessage('User entered invalid thing ID')
    break
  case 'CLOSE_ERROR_MESSAGE':
    return hideErrorMessage()
    break
  default:
    return doNothing()
  }
}

// :: (State, Action) → State
function errorMessageReducer (state, action) {
  return interpretAction(action)(state)
}

const showErrorMessage = message => state => ({ visible: true, message })
const hideErrorMessage = () => state => ({ visible: false })
const doNothing = () => state => state

행동이 "명령"이 아닌 "사실"로 상점에 들어갈 때 잘못될 가능성이 적습니다. 글쎄요, 사실이기 때문입니다.

이제 감속기가 그 사실을 잘못 해석하면 쉽게 수정할 수 있으며 수정 사항은 시간이 지남에 따라 이동할 수 있습니다. 그러나 액션 제작자가 그 사실을 잘못 해석하면 액션 제작자를 다시 실행해야 합니다.

USER_ENTERED_INVALID_THING_ID 가 실행될 때 사물 ID 텍스트 필드가 재설정되도록 감속기를 변경할 수도 있습니다. 그리고 그 변화는 또한 시간을 통해 이동합니다. 페이지를 새로 고치지 않고도 오류 메시지를 현지화할 수도 있습니다. 이는 피드백 루프를 강화하고 디버깅 및 조정을 훨씬 쉽게 만듭니다.

(여기서 나는 단지 장점에 대해 이야기하고 있습니다. 물론 단점도 있습니다. 귀하의 상점이 이러한 사실에 동기적으로 그리고 부작용 없이 응답할 수 있다는 점을 감안할 때 그 사실을 표현하는 방법에 대해 더 많이 생각해야 합니다. 에 대한 토론을 참조하십시오. 이 질문을 StackOverflow에 게시했습니다 . 아직 그 부분을 파악하지 못한 것 같습니다.)

처음에는 액션에 반응하는 임의의 리듀서에 대해 어떻게 느끼는지 솔직히 잘 모르겠습니다. 약간 나쁜 캡슐화 같은 느낌이 듭니다.

여러 구성 요소가 동일한 저장소에서 데이터를 가져오는 것도 매우 일반적입니다. 또한 단일 구성 요소가 저장소의 여러 부분에서 가져온 데이터에 의존하는 경우가 많습니다. 너무 나쁜 캡슐화처럼 들리지 않습니까? 진정한 모듈화가 되려면 React 컴포넌트도 "duck" 번들 안에 있어야 하지 않을까요? ( Elm 아키텍처가 이를 수행합니다 .)

React는 스토어의 데이터를 사실로 처리

같은 방식으로 Redux/Flux는 액션을 사실로 취급

@dtinth, 시간을 내어 글을 작성하고 생각을 공유해 주셔서 감사합니다. 또한 이 토론에 참여해 주신

여러 구성 요소가 동일한 저장소에서 데이터를 가져오는 것도 매우 일반적입니다. 또한 단일 구성 요소가 저장소의 여러 부분에서 가져온 데이터에 의존하는 경우가 많습니다. 너무 나쁜 캡슐화처럼 들리지 않습니까?

음... 주관적인 부분도 있지만 아닙니다. 내보낸 action-creators와 selectors를 모듈의 API로 생각합니다.

어쨌든 좋은 토론이었다고 생각합니다. 이전 답변에서 언급한 Thai와 마찬가지로 우리가 논의하고 있는 이러한 접근 방식에는 장단점이 있습니다. 다른 접근 방식에 대한 통찰력을 얻는 것이 좋습니다. :)

그건 그렇고 메시지 상자는 표시를 위해 별도의 작업 작성자가 있는 것을 선호하는 좋은 예입니다. 주로 생성된 시간을 전달하여 자동으로 해제할 수 있도록 하고 싶기 때문에(그리고 액션 생성기는 impure Date.now() 호출하는 곳입니다), 이를 해제하는 타이머를 설정하고 싶기 때문에 해당 타이머 등을 디바운스하고 싶습니다. 따라서 메시지 상자의 "작업 흐름"이 개인적인 작업을 보증할 만큼 충분히 중요한 경우를 고려합니다. 내가 설명한 내용은 https://github.com/yelouafi/redux-saga에서 더 우아하게 해결할 수 있습니다

처음에 Discord Reactiflux 채팅에 이것을 썼지만 여기에 붙여넣으라는 요청을 받았습니다.

나는 최근에 같은 것에 대해 많이 생각하고 있다. 상태 업데이트가 세 부분으로 나누어져 있는 것 같습니다.

1. 작업 생성자에게 업데이트를 실행하는 데 필요한 최소한의 정보가 전달됩니다. 즉, 현재 상태에서 계산할 수 있는 것은 그 안에 있으면 안 됩니다.
2. 상태는 업데이트를 수행하는 데 필요한 정보에 대해 쿼리됩니다(예: id X로 Todo를 복사하려는 경우 복사할 수 있도록 id X로 Todo의 속성을 가져옴). 이것은 작업 생성자에서 수행할 수 있으며 해당 정보는 작업 개체에 포함됩니다. 결과적으로 뚱뚱한 작업 개체가 생성됩니다. 또는 감속기 - 얇은 작업 개체에서 계산할 수 있습니다.
3. 해당 정보를 기반으로 순수 리듀서 로직이 적용되어 다음 상태를 얻습니다.

이제 문제는 액션 생성자에 무엇을 넣고 리듀서에 무엇을 넣을지, 뚱뚱한 액션 객체와 얇은 액션 객체 중 선택입니다. 모든 로직을 액션 생성자에 넣으면 기본적으로 상태 업데이트를 선언하는 뚱뚱한 액션 객체가 생깁니다. 리듀서는 순수하고, 멍청하고, 추가하고, 제거하고, 이러한 기능을 업데이트합니다. 그들은 작곡하기 쉬울 것입니다. 그러나 비즈니스 로직의 대부분은 거기에 없을 것입니다.

리듀서에 더 많은 로직을 넣으면 멋지고 얇은 액션 객체가 생기고 대부분의 데이터 로직이 한 곳에 있지만 다른 브랜치의 정보가 필요할 수 있기 때문에 리듀서는 구성하기가 더 어렵습니다. 상태의 상위에서 추가 인수를 취하는 대형 감속기 또는 감속기로 끝납니다.

이 문제에 대한 답이 무엇인지 모르며 아직 있는지 확실하지 않습니다.

이러한 생각을 공유해 주셔서 감사합니다 @tommikaikkonen. 나는 여기에 "대답"이 무엇인지 아직 결정하지 못했습니다. 나는 당신의 요약에 동의합니다. "모든 논리를 작업 생성자에 넣기..." 섹션에 작은 메모 하나를 추가하겠습니다. 이 섹션에서는 일부 경우에 유용할 수 있는 데이터를 읽기 위해 (공유) 선택기를 사용할 수 있습니다.

이것은 흥미로운 스레드입니다! redux 앱에서 코드를 배치할 위치를 파악하는 것은 우리 모두가 직면한 문제인 것 같습니다. 나는 일어난 일을 기록하는 CQRS 아이디어를 좋아합니다.
그러나 CQRS에서 아이디어의 불일치를 볼 수 있습니다. AFAIK 모범 사례는 보기에서 직접 소비할 수 있는 작업/이벤트에서 비정규화된 상태를 구축하는 것입니다. 그러나 redux에서 가장 좋은 방법은 완전히 정규화된 상태를 구축하고 선택기를 통해 뷰의 데이터를 파생시키는 것입니다.
뷰에서 직접 소비할 수 있는 비정규화 상태를 빌드하면 리듀서가 다른 리듀서에 데이터를 저장하려는 문제가 사라집니다(각 리듀서가 정규화에 신경 쓰지 않아도 되는 모든 데이터를 저장할 수 있기 때문). 그러나 데이터를 업데이트할 때 다른 문제가 발생합니다. 이것이 토론의 핵심이 아닐까요?

수년간의 객체 지향 개발에서 비롯된 것입니다. Redux는 크게 후퇴한 것처럼 느껴집니다. 나는 이벤트(액션 생성자)와 비즈니스 로직을 캡슐화하는 클래스를 만들어달라고 애원합니다. 나는 여전히 의미 있는 타협을 찾으려고 노력하고 있지만 아직 그렇게 할 수 없습니다. 다른 사람도 같은 기분이 들까요?

객체 지향 프로그래밍은 읽기와 쓰기를 함께 사용하도록 권장합니다. 이로 인해 스냅샷 및 롤백, 중앙 집중식 로깅, 잘못된 상태 변형 디버깅, 세분화된 효율적인 업데이트 등 많은 문제가 발생합니다. 그것이 당신에게 문제라고 생각하지 않는다면, 전통적인 객체 지향 MVC 코드를 작성하면서 그것들을 피하는 방법을 알고 있고, Redux가 당신의 앱에서 해결하는 것보다 더 많은 문제를 도입한다면, Redux를 사용하지 마십시오 :wink: .

@jayesbe 객체 지향 프로그래밍 배경에서 https://www.leaseweb.com/labs/2015/08/object-oriented-programming-is-exceptionally-bad/.

데이터 변환에서 작업을 분리하면 비즈니스 규칙의 적용 테스트가 더 간단해집니다. 변환은 애플리케이션 컨텍스트에 덜 의존합니다.

그렇다고 자바스크립트에서 객체나 클래스를 포기하는 것은 아닙니다. 예를 들어 React 구성 요소는 객체로 구현되고 이제는 클래스로 구현됩니다. 그러나 React 구성 요소는 단순히 제공된 데이터의 투영을 생성하도록 설계되었습니다. 상태를 저장하지 않는 순수 구성 요소를 사용하는 것이 좋습니다.

이것이 Redux가 등장하는 곳입니다. 애플리케이션 상태를 구성하고 작업과 애플리케이션 상태의 해당 변환을 함께 가져옵니다.

@johnsoftek 링크 주셔서 감사합니다. 그러나 지난 10년 동안의 내 경험에 따르면. 나는 그것에 동의하지 않지만 우리는 여기서 OO와 non-OO 사이의 논쟁에 들어갈 필요가 없습니다. 내가 가진 문제는 코드와 추상화를 구성하는 것입니다.

내 목표는 구성 값만 사용하여 100개의 앱을 만드는 데 사용할 수 있는 단일 앱/단일 아키텍처를 만드는 것입니다. 내가 처리해야 하는 사용 사례는 많은 클라이언트가 사용하는 화이트 레이블 소프트웨어 솔루션을 처리하는 것입니다. 각각은 응용 프로그램을 자체적으로 호출합니다.

나는 흥미로운 절충안이라고 생각하는 것을 생각해 냈습니다. 그리고 충분히 잘 처리한다고 생각하지만 함수형 프로그래밍 군중 표준을 충족하지 못할 수도 있습니다. 나는 여전히 그것을 거기에 넣고 싶습니다.

내 서버 측 응용 프로그램과 인터페이스하는 데 필요한 모든 비즈니스 논리, API 래퍼 등이 포함된 단일 응용 프로그램 클래스가 있습니다.

예시..

export default Application {
    constructor(config) {
        this.config = config;
    } 

    config() {
        return this.config;
    }

    login(data, cb) {
        const url = [
            this.config.url,
            '?client=' + this.config.client,
            '&username=' + data.username,
            ....
        ].join('');

        fetch(url).then((responseText) => {
            cb(responseText);
        })
    }

    ... more business logic 
}

이 객체의 단일 인스턴스를 만들고 컨텍스트에 배치했습니다. Redux 공급자를 확장하여

import { Provider } from 'react-redux';

export default class MyProvider extends Provider {
    getChildContext() {
        return Object.assign({}, Provider.prototype.getChildContext.call(this), {
            app: this.props.app
        });
    }

    render() {
        return this.props.children;
    }
}
MyProvider.childContextTypes = {
    store: React.PropTypes.object,
    app: React.PropTypes.object
}

그런 다음이 공급자를 다음과 같이 사용했습니다.

import Application from './application';
import config from './config';

class MyApp extends Component {
  render() {
    return (
      <MyProvider store={store} app={new Application(config)}>
        <Router />
      </MyProvider>
    );
  }
}

AppRegistry.registerComponent('MyApp', () => MyApp);

마침내 내 구성 요소에서 내 앱을 사용했습니다.

class Login extends React.Component {
    render() {
        const { app } = this.context;
        const { state, actions } = this.props;
        return (
              <View style={style.transparentContainer}>
                <Form ref="form" type={User} options={options} />
                <Button 
                  onPress={() => {
                    value = this.refs.form.getValue();
                    if (value) {
                      app.login(value, actions.login);
                    }
                  }}
                >
                  Login
                </Button>
              </View>
        );
    }
};
Login.contextTypes = {
  app: React.PropTypes.object,
};

function mapStateToProps(state) {
  return {
      state: state.default.auth
  };
};

function mapDispatchToProps(dispatch) {
  return {
    actions: bindActionCreators(authActions, dispatch),
    dispatch
  };
}

export default connect(mapStateToProps, mapDispatchToProps)(Login);

따라서 Action Creator는 내 비즈니스 로직에 대한 콜백 함수일 뿐입니다.

                      app.login(value, actions.login);

이 솔루션은 인증으로만 시작했지만 현재 잘 작동하는 것 같습니다.

스토어를 내 Application 인스턴스에 전달할 수도 있다고 생각하지만 스토어가 우연한 돌연변이를 겪는 것을 원하지 않기 때문에 그렇게 하고 싶지 않습니다. 상점에 액세스하는 것이 편리할 수 있습니다. 필요하면 더 생각하겠습니다.

나는 흥미로운 절충안이라고 생각하는 것을 생각해 냈습니다. 그리고 충분히 잘 처리한다고 생각하지만 함수형 프로그래밍 군중 표준을 충족하지 못할 수도 있습니다.

여기에서 "기능적인 군중"을 찾을 수 없습니다 :wink: . Redux에서 기능적 솔루션을 선택하는 이유는 우리가 독단적이기 때문이 아니라 사람들이 수업 때문에 종종 만드는 몇 가지 문제를 해결하기 때문입니다. 예를 들어 리듀서를 액션 생성자와 분리하면 버그를 기록하고 재생하는 데 중요한 읽기와 쓰기를 분리할 수 있습니다. 일반 개체인 작업은 직렬화 가능하기 때문에 기록 및 재생을 가능하게 합니다. 마찬가지로 상태가 MyAppState 의 인스턴스가 아닌 일반 객체이므로 서버에서 직렬화하고 서버 렌더링을 위해 클라이언트에서 역직렬화하거나 localStorage 에 일부를 유지하는 것이 매우 쉽습니다. 리듀서를 함수로 표현하면 시간 여행과 핫 리로딩을 구현할 수 있고, 셀렉터를 함수로 표현하면 메모이제이션을 쉽게 추가할 수 있습니다. 이러한 모든 이점은 우리가 "기능적 군중"이 되는 것과 아무 관련이 없으며 이 라이브러리가 해결하기 위해 생성된 특정 작업을 해결하는 것과 관련이 있습니다.

이 객체의 단일 인스턴스를 만들고 컨텍스트에 배치했습니다. Redux 공급자를 확장하여

이것은 나에게 완전히 합리적으로 보입니다. 우리는 수업을 비합리적으로 싫어하지 않습니다. 요점은 그것들이 심각하게 제한되는 경우(예: 감속기 또는 작업 개체의 경우)에는 사용하지 않는 것이 좋지만 예를 들어 작업 개체를 생성하는 데 사용하는 것은 괜찮습니다.

그러나 Provider 를 확장하는 것은 깨지기 쉬우므로 피합니다. 그럴 필요가 없습니다. React는 구성 요소의 컨텍스트를 병합하므로 대신 감싸기만 하면 됩니다.

import { Component } from 'react';
import { Provider } from 'react-redux';

export default class MyProvider extends Component {
    getChildContext() {
        return {
            app: this.props.app
        };
    }

    render() {
        return (
            <Provider store={this.props.store}>
                {this.props.children}
            </Provider>
        );
    }
}
MyProvider.childContextTypes = {
    app: React.PropTypes.object
}
MyProvider.propTypes = {
    app: React.PropTypes.object,
    store: React.PropTypes.object
}

실제로 내 보기에는 더 읽기 쉽고 덜 깨지기 쉽습니다.

따라서 전반적으로 귀하의 접근 방식은 완전히 의미가 있습니다. 이 경우 클래스를 사용하는 것은 createActions(config) 와 같은 것과 크게 다르지 않습니다. 이는 액션 생성자를 매개변수화해야 하는 경우에도 권장하는 패턴입니다. 전혀 문제가 없습니다.

클래스 인스턴스는 직렬화를 매우 까다롭게 만들기 때문에 상태 및 작업 개체에 대해 클래스 인스턴스를 사용하지 않는 것이 좋습니다. 감속기의 경우 다른 감속기를 호출하는 감속기 구성, 즉 감속기를 사용하는 것이 더 어렵기 때문에 클래스 사용도 권장하지 않습니다. 다른 모든 것에는 클래스를 포함한 모든 코드 구성 수단을 사용할 수 있습니다.

애플리케이션과 구성이 변경 불가능한 경우(그리고 그래야 한다고 생각하지만 아마도 기능적인 쿨 에이드를 너무 많이 마신 것 같습니다) 다음 접근 방식을 고려할 수 있습니다.

const appSelector = createSelector(
   (state) => state.config,
   (config) => new Application(config)
)

그런 다음 mapStateToProps에서:

function mapStateToProps(state) {
  return {
      app: appSelector(state)
  };
};

그런 다음 채택한 공급자 기술이 필요하지 않으며 상태에서 응용 프로그램 개체를 가져오기만 하면 됩니다. reselect 덕분에 Application 개체는 구성이 변경될 때만 구성되며, 이는 아마도 한 번일 것입니다.

이 접근 방식이 장점이 있을 수 있다고 생각하는 경우 이러한 개체가 여러 개 있고 해당 개체가 상태의 다른 부분에 종속되도록 하는 아이디어를 쉽게 확장할 수 있다는 점입니다. 예를 들어 구성과 상태의 일부에 모두 액세스할 수 있는 로그인/로그아웃/etc 메서드가 있는 UserControl 클래스가 있을 수 있습니다.

따라서 전반적으로 귀하의 접근 방식은 완전히 의미가 있습니다.

:+1: 도움이 되었습니다. 감사합니다. MyProvider의 개선 사항에 동의합니다. 따르도록 코드를 업데이트하겠습니다. Redux를 처음 배울 때 겪었던 가장 큰 문제 중 하나는 "Action Creators"의 의미론적 개념이었습니다. 이벤트와 동일시할 때까지는 의미가 없었습니다. 나에게 그것은 .. 이것들이 파견되는 이벤트와 같은 일종의 깨달음이었습니다.

@winstonewert 는 react-native에서 createSelector를 사용할 수 있습니까? 나는 그것을 믿지 않는다. 동시에 일부 구성 요소의 mapStateToProps에 연결할 때마다 새 응용 프로그램을 만드는 것처럼 보입니다. 내 목표는 응용 프로그램에 대한 모든 비즈니스 논리를 제공하고 해당 개체가 전역적으로 액세스할 수 있도록 하는 단일 개체를 인스턴스화하는 것입니다. 제안이 효과가 있는지 잘 모르겠습니다. 필요한 경우 추가 개체를 사용할 수 있다는 아이디어가 좋지만.. 기술적으로 Application 인스턴스를 통해 필요에 따라 인스턴스화할 수도 있습니다.

Redux를 처음 배울 때 겪었던 가장 큰 문제 중 하나는 "Action Creators"의 의미론적 개념이었습니다. 이벤트와 동일시할 때까지는 의미가 없었습니다. 나에게 그것은 .. 이것들이 파견되는 이벤트와 같은 일종의 깨달음이었습니다.

Redux에는 Action Creators의 의미론적 개념이 전혀 없다고 말하고 싶습니다. Actions의 의미론적 개념이 있습니다(일어난 일을 설명하고 이벤트와 대략 동일하지만 완전히 같지는 않습니다. 예를 들어 #351의 토론 참조). 액션 생성자는 코드를 구성하기 위한 패턴일 뿐입니다. 같은 유형의 작업이 일관된 구조를 갖고 전달되기 전에 동일한 부작용이 있는지 등을 확인하고 싶기 때문에 작업을 위한 팩토리를 갖는 것이 편리합니다. 그러나 Redux의 관점에서 볼 때 작업 생성자는 존재하지 않습니다. Redux 행동만 보입니다.

react-native에서 createSelector를 사용할 수 있습니까?

종속성이 없는 일반 JavaScript이며 웹, 기본, 서버 등에서 작동할 수 있는 Reselect 에서 사용할 수 있습니다.

아. 알았어. 상황이 훨씬 더 명확해졌습니다. 건배.

mapStateToProps 및 mapDispatchToProps에 개체를 중첩하지 마십시오.

최근 Redux가 mapStateToProps와 mapDispatchToProps를 병합할 때 중첩된 객체가 손실되는 문제에 부딪쳤습니다(reactjs/react-redux#324 참조). @gaearon 은 중첩 객체를 사용할 수 있는 솔루션을 제공하지만

이와 같이 객체를 그룹화하면 불필요한 할당이 발생하고 성능 최적화가 더 어려워집니다. 결과 props가 변경되었는지 여부를 알려주는 방법으로 더 이상 결과 props의 얕은 동등성에 의존할 수 없기 때문입니다. 따라서 문서에서 권장하는 네임스페이스가 없는 단순한 접근 방식보다 더 많은 렌더링을 볼 수 있습니다.

@bvaughn이 말했다

감속기는 어리 석고 단순해야합니다.

그리고 우리는 대부분의 비즈니스 로직을 액션 생성자에게 넣어야 합니다. 저는 그것에 전적으로 동의합니다. 그러나 모든 것이 실행으로 옮겨졌다면 왜 여전히 수동으로 감속기 파일과 기능을 만들어야 합니까? 액션에서 조작된 데이터를 직접 저장하지 않겠습니까?

한동안 저를 혼란스럽게 만들었습니다...

왜 여전히 감속기 파일과 기능을 수동으로 만들어야 합니까?

리듀서는 순수 함수이기 때문에 상태 업데이트 로직에 오류가 있는 경우 리듀서를 핫 리로드할 수 있습니다. 그런 다음 개발 도구는 앱을 초기 상태로 되감고 새 감속기를 사용하여 모든 작업을 재생할 수 있습니다. 즉, 수동으로 롤백하고 작업을 다시 수행하지 않고도 상태 업데이트 버그를 수정할 수 있습니다. 이것은 리듀서에 상태 업데이트 로직의 대부분을 유지하는 이점입니다.

이것은 리듀서에 상태 업데이트 로직의 대부분을 유지하는 이점입니다.

@dtinth "상태 업데이트 논리"라고 말하면 "비즈니스 논리"를 의미합니까?

나는 대부분의 논리를 액션 생성자에게 적용하는 것이 좋은 생각인지 잘 모르겠습니다. 모든 리듀서가 ADD_X 와 같은 작업을 허용하는 사소한 기능이라면 오류가 발생할 가능성이 없습니다. 좋습니다! 그러나 모든 오류가 작업 작성자에게 푸시되고 @dtinth가 암시하는 훌륭한 디버깅 경험을

그러나 @tommikaikkonen이 언급했듯이 복잡한 리듀서를 작성하는 것은 그리 간단하지 않습니다. 내 직감에 따르면 Redux의 이점을 얻고 싶다면 푸시하고 싶을 것입니다. 그렇지 않으면 부작용을 가장자리로 밀어 넣는 대신 가장 사소한 작업만 처리하도록 순수한 기능을 밀어붙이고 대부분의 국가가 몰고 있는 지옥에서 앱의 :)

@sompylasar "비즈니스 로직"과 "상태 업데이트 로직"은 같은 것입니다.

그러나 내 자신의 구현 세부 사항으로 차임하기 위해 .. 내 작업은 주로 작업에 대한 입력에 대한 조회입니다. 실제로 모든 "비즈니스 논리"를 응용 프로그램 컨텍스트로 이동했기 때문에 모든 작업은 순수합니다.

예를 들어 .. 이것은 내 일반적인 감속기

export default function reducer(state = initialState, action = {}) {
  switch (action.type) {
    case 'FOO_REQUEST':
    case 'FOO_RESPONSE':
    case 'FOO_ERROR':
    case 'FOO_RESET':
      return {
        ...state,
        ...action.data
      }; 
    default:
      return state;
  }
}

나의 전형적인 행동:

export function fooRequest( res ) {
  return {
    type: 'FOO_REQUEST',
    data: {
        isFooing: true,
        toFoo: res.saidToFoo
    }
  };
}

export function fooResponse( res ) {
  return {
    type: 'FOO_RESPONSE',
    data: {
        isFooing: false,
        isFooed: true,
        fooData: res.data
    }
  };
}

export function fooError( res ) {
  return {
    type: 'FOO_ERROR',
    data: {
        isFooing: false,
        fooData: null,
        isFooed: false,
        fooError: res.error
    }
  };
}

export function fooReset( res ) {
  return {
    type: 'FOO_RESET',
    data: {
        isFooing: false,
        fooData: null,
        isFooed: false,
        fooError: null,
        toFoo: true
    }
  };
}

내 비즈니스 로직은 컨텍스트에 저장된 개체에 정의되어 있습니다.

export default class FooBar
{
    constructor(store)
    {
        this.actions = bindActionCreators({
            ...fooActions
        }, store.dispatch);
    }

    async getFooData()
    {
        this.actions.fooRequest({
            saidToFoo: true
        });

        fetch(url)
        .then((response) => {
            this.actions.fooResponse(response);
        })
    }
}

위의 내 의견을 보면 나도 최선의 접근 방식으로 고심하고 있었습니다. 결국 리팩토링하고 저장소를 내 응용 프로그램 개체의 생성자에 전달하고 이 중심점에서 모든 작업을 디스패처에 연결하는 것으로 해결했습니다. 내 애플리케이션이 알고 있는 모든 작업이 여기에 할당됩니다.

나는 더 이상 어디에서나 mapDispatchToProps()를 사용하지 않습니다. Redux의 경우 이제 연결된 구성 요소를 생성할 때 mapStateToProps만 사용합니다. 작업을 트리거해야 하는 경우 .. 컨텍스트를 통해 내 응용 프로그램 개체를 통해 작업을 트리거할 수 있습니다.

class SomeComponent extends React.Component {
    componentWillReceiveProps(nextProps) {
        if (nextProps.someFoo != this.props.someFoo) {
            const { app } = this.context;
            app.actions.getFooData();
        }
    }
}
SomeComponent.contextTypes = {
    app: React.PropTypes.object
};

위의 구성 요소는 redux 연결이 필요하지 않습니다. 여전히 작업을 전달할 수 있습니다. 물론 구성 요소 내에서 상태를 업데이트해야 하는 경우 상태 변경이 전파되도록 연결 구성 요소로 전환합니다.

이것이 내가 핵심 "비즈니스 로직"을 구성한 방법입니다. 내 상태가 백엔드 서버에서 실제로 유지되기 때문에 .. 이것은 내 사용 사례에 정말 잘 작동합니다.

"비즈니스 논리"를 저장하는 위치는 실제로 귀하와 사용 사례에 맞는 방법에 달려 있습니다.

@jayesbe 다음 부분은 리듀서에 "비즈니스 로직"이 없고, 게다가 상태 구조가 리듀서를 통해 스토어로 전송되는 페이로드를 생성하는 액션

    case 'FOO_REQUEST':
    case 'FOO_RESPONSE':
    case 'FOO_ERROR':
    case 'FOO_RESET':
      return {
        ...state,
        ...action.data
      }; 

export function fooRequest( res ) {
  return {
    type: 'FOO_REQUEST',
    data: {
        isFooing: true,
        toFoo: res.saidToFoo
    }
  };
}

@jayesbe 내 작업과 감속기는 귀하와 매우 유사하며 일부 작업은 일반 네트워크 응답 개체를 인수로 수신하며 응답 데이터를 작업으로 처리하고 마지막으로 매우 간단한 개체를 반환된 값으로 반환한 다음 전달하는 방법에 대한 논리를 캡슐화했습니다. 호출 dispatch()를 통한 감속기. 당신이 한 일처럼. 문제는 이러한 방식으로 작성된 액션이 거의 모든 작업을 수행했으며 리듀서의 책임이 매우 가볍다면 리듀서가 단순히 액션 객체를 확산하는 경우 수동으로 저장할 데이터를 전송해야 하는 이유가 무엇입니까? Redux가 우리를 위해 자동으로 투여하는 것은 전혀 어려운 일이 아닙니다.

반드시는 아닙니다. 그러나 대부분의 경우 비즈니스 프로세스의 일부인
비즈니스 규칙에 따라 애플리케이션의 상태를 업데이트하는 것을 포함합니다.
그래서 거기에 약간의 비즈니스 로직을 넣어야 할 수도 있습니다.

극단적인 경우 다음을 확인하세요.
"동기식 RTS 엔진과 비동기식 이야기" @ForrestTheWoods
https://blog.forrestthewoods.com/synchronous-rts-engines-and-a-tale-of-desyncs-9d8c3e48b2be

2016년 4월 5일 오후 5시 54분에 "John Babak" [email protected]이 작성했습니다.

이것은 대부분의 상태 업데이트 논리를 유지하는 이점입니다.
감속기.

@dtinth https://github.com/dtinth 명확히 하자면
"상태 업데이트 논리"는 "비즈니스 논리"를 의미합니까?

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

@LumiaSaki 작성자에게 복잡한 로직을 유지하면서 리듀서를 단순하게 유지

그 때문에 Redux는 작업에서 저장소로 데이터를 자동으로 전송하지 않습니다. Redux를 사용해야 하는 방식이 아니기 때문입니다. Redux는 의도한 것과 다른 방식으로 사용하기 쉽게 변경되지 않을 것입니다. 물론, 당신은 당신에게 맞는 일을 하는 것이 절대적으로 자유롭지만 Redux가 그것을 위해 바뀔 것이라고 기대하지 마십시오.

그 가치를 위해 다음과 같은 것을 사용하여 감속기를 생산합니다.

let {reducer, actions} = defineActions({
   fooRequest: (state, res) => ({...state, isFooing: true, toFoo: res.saidToFoo}),
   fooResponse: (state, res) => ({...state, isFooing: false, isFooed: true, fooData: res.data}),
   fooError: (state, res) => ({...state, isFooing: false, fooData: null, isFooed: false, fooError: res.error})
   fooReset: (state, res) => ({...state, isFooing: false, fooData: null, isFooed: false, fooError: null, toFoo: false})
})

defineActions는 리듀서와 액션 생성자를 모두 반환합니다. 이렇게 하면 사소한 작업 생성기를 작성하는 데 많은 시간을 할애하지 않고도 업데이트 논리를 감속기 내부에 유지하는 것이 매우 쉽다는 것을 알 수 있습니다.

액션 생성자에게 논리를 유지해야 한다고 주장한다면 데이터를 직접 자동화하는 데 문제가 없어야 합니다. 감속기는 기능이며 원하는 모든 작업을 수행할 수 있습니다. 따라서 감속기는 다음과 같이 간단할 수 있습니다.

function reducer(state, action) {
    if (action.data) {
        return {...state, ...action.data}
   } else {
        return state;
   }
}

비즈니스 로직에 관한 이전 요점을 확장하여 비즈니스 로직을 두 부분으로 나눌 수 있다고 생각합니다.

• 결정적이지 않은 부분입니다. 이 부분은 외부 서비스, 비동기 코드, 시스템 시간 또는 난수 생성기를 사용합니다. 내 생각에 이 부분은 I/O 기능(또는 작업 생성자)이 가장 잘 처리합니다. 저는 그들을 비즈니스 프로세스라고 부릅니다.

사용자가 실행 버튼을 클릭할 수 있고 앱을 컴파일하고 실행할 수 있는 IDE와 유사한 소프트웨어를 고려하십시오. (여기서는 저장소를 사용하는 비동기 함수를 사용하지만 대신 redux-thunk 를 사용할 수 있습니다.)

js export async function runApp (store) { try { store.dispatch({ type: 'startCompiling' }) const compiledApp = await compile(store) store.dispatch({ type: 'startRunning', app: compiledApp }) } catch (e) { store.dispatch({ type: 'errorCompiling', error: e }) } }

• 결정적인 부분입니다. 이 부분은 완전히 예측 가능한 결과를 가지고 있습니다. 동일한 상태와 동일한 이벤트가 주어지면 결과는 항상 예측 가능합니다. 제 생각에는 이 부분이 감속기에 의해 가장 잘 처리됩니다. 저는 이것을 비즈니스 규칙이라고 부릅니다.

``` js
'updeep'에서 가져오기

내보내기 const 감속기 = createReducer({
// [액션 이름]: 액션 => currentState => nextState
시작 컴파일: () => u({ 컴파일: 참 }),
errorCompiling: ({ 오류 }) => u({ 컴파일: false, compileError: 오류 }),
시작 실행: ({ 앱 }) => u({
실행 중: () => 앱,
컴파일: 거짓
}),
stopRunning: () => u({ 실행 중: false }),
폐기CompileError: () => u({ compileError: null }),
// ...
})
```

나는 가능한 한 많은 코드를 이 결정적인 영역에 넣으려고 노력하지만, 리듀서의 유일한 책임은 들어오는 작업이 주어지면 애플리케이션 상태를 일관되게 유지하는 것이라는 점을 염두에 둡니다. 더 이상 아무것도 없습니다. 그 외에는 Redux가 상태 컨테이너일 뿐이므로 Redux 외부에서 수행합니다.

@dtinth 우수함,에서 앞의 예 때문에 https://github.com/reactjs/redux/issues/1171#issuecomment -205782740은 당신이 쓴 것과 완전히 다른 모습 https://github.com/reactjs/redux/ Issues/1171#issuecomment -205888533 -- 액션 생성자에서 상태를 구성하고 리듀서에 전달하여 업데이트를 퍼뜨릴 수 있도록 제안합니다. https://github.com/reactjs/redux/issues/1171#issuecomment-205865840 ).

@winstonewert

Redux에서 권장하는 패턴은 반대입니다. 리듀서에서 복잡한 논리를 유지하면서 작업 작성자를 단순하게 유지하세요.

어떻게 ruducers에 복잡한 논리를 넣고 여전히 순수하게 유지할 수 있습니까?

예를 들어 fetch()를 호출하고 서버에서 데이터를 로드하는 경우.. 어떤 식으로든 처리합니다. 나는 아직 "복잡한 논리"를 가진 감속기의 예를 보지 못했습니다.

@jayesbe : 어... "복잡한"과 "순수한"은 직교합니다. 감속기 내부에 _정말__ 복잡한 조건부 논리나 조작이 있을 수 있으며, 입력의 기능일 뿐이고 부작용이 없는 한 여전히 순수합니다.

복잡한 로컬 상태(포스트 편집기, 트리 보기 등)가 있거나 낙관적 업데이트와 같은 작업을 처리하는 경우 리듀서에 복잡한 논리가 포함됩니다. 그것은 정말로 앱에 달려 있습니다. 일부에는 복잡한 요청이 있고 다른 일부에는 복잡한 상태 업데이트가 있습니다. 일부는 둘 다 가지고 있습니다 :-)

@markerikson ok 논리 문은 한 가지입니다. 그러나 특정 작업을 실행합니까? 예를 들어 한 경우에는 세 가지 다른 작업을 트리거하거나 다른 경우에는 두 개의 별개의 별도 작업을 트리거하는 하나의 작업이 있습니다. 그 논리 + 작업 실행은 감속기에 들어가야 할 것처럼 들리지 않습니다.

내 상태 데이터/모델 상태는 서버에 있고 보기 상태는 데이터 모델과 다르지만 해당 상태의 관리는 클라이언트에 있습니다. 내 데이터 모델 상태는 단순히 보기로 전달됩니다. 이는 내 감속기와 작업을 매우 간결하게 만듭니다.

@jayesbe : 다른 행동의 트리거링이 감속기에 들어가야 한다고 말한 사람은 아무도 없다고 생각합니다. 그리고 사실, 그러면 안됩니다. 감속기의 작업은 단순히 (currentState + action) -> newState 입니다.

여러 작업을 함께 묶어야 하는 경우 썽크 또는 사가와 같은 방식으로 수행하고 순서대로 실행하거나 상태 변경을 수신하는 작업을 수행하거나 미들웨어를 사용하여 작업을 가로채고 추가 작업을 수행합니다.

솔직히 말해서 이 시점에서 논의가 무엇인지 혼란스럽습니다.

@markerikson 주제는 "비즈니스 로직"과 그것이 어디로

당신이 말했듯이 정말로 중요한 것은 당신에게 효과가 있는 것입니다. 그러나 여기에 귀하가 질문한 문제를 해결하는 방법이 있습니다.

예를 들어 fetch()를 호출하고 서버에서 데이터를 로드하는 경우.. 어떤 식으로든 처리합니다. 나는 아직 "복잡한 논리"를 가진 감속기의 예를 보지 못했습니다.

내 감속기는 내 서버에서 원시 응답을 받아 내 상태를 업데이트합니다. 그렇게하면 귀하가 말하는 처리 응답이 내 감속기에서 수행됩니다. 예를 들어 요청은 리듀서가 로컬 레코드 캐시에 저장하는 내 서버에 대한 JSON 레코드 가져오기일 수 있습니다.

k 논리 문은 한 가지입니다. 그러나 특정 작업을 실행합니까? 예를 들어 한 경우에는 세 가지 다른 작업을 트리거하거나 다른 경우에는 두 개의 별개의 별도 작업을 트리거하는 하나의 작업이 있습니다. 그 논리 + 작업 실행은 감속기에 들어가야 할 것처럼 들리지 않습니다.

그것은 당신이하는 일에 달려 있습니다. 분명히 서버 가져오기의 경우 한 작업이 다른 작업을 트리거합니다. 이는 권장되는 Redux 절차 내에 있습니다. 그러나 다음과 같은 작업을 수행할 수도 있습니다.

function createFoobar(dispatch, state, updateRegistry) {
   dispatch(createFoobarRecord());
   if (updateRegistry) {
      dispatch(updateFoobarRegistry());
   } else {
       dispatch(makeFoobarUnregistered());
   }
   if (hasFoobarTemps(state)) {
      dispatch(dismissFoobarTemps());
   }
}

이것은 Redux를 사용하는 데 권장되는 방법이 아닙니다. Redux에서 권장하는 방법은 이러한 모든 원하는 변경을 일으키는 단일 CREATE_FOOBAR 작업을 사용하는 것입니다.

@winstonewert :

이것은 Redux를 사용하는 데 권장되는 방법이 아닙니다. Redux에서 권장하는 방법은 이러한 모든 원하는 변경을 일으키는 단일 CREATE_FOOBAR 작업을 사용하는 것입니다.

지정된 어딘가에 대한 포인터가 있습니까? 내가 FAQ 페이지에 대한 조사를 할 때 내가 생각해낸 것은 Dan이 직접 제안한 "그것은 의존적"이기 때문입니다. http://redux.js.org/docs/FAQ.html#actions -multiple-actions 및 Dan의 SO on this 답변을 참조하십시오.

"비즈니스 논리"는 실제로 꽤 광범위한 용어입니다. "일어난 일이 있었나요?", "이런 일이 발생했으니 이제 어떻게 합니까?", "이것이 유효한가요?" 등과 같은 내용을 다룰 수 있습니다. Redux의 설계를 기반으로 하여 이러한 질문은 상황에 따라 다양한 위치에서 답변할 수 _수_ 있습니다. 비록 "이런 일이 발생했습니까?"는 액션 생성자의 더 많은 책임으로 보고 "지금은"은 거의 확실히 감속기 책임으로 볼 수 있습니다.

전반적으로, "비즈니스 논리"에 대한 이 _ 전체 질문 _"그것은 _에

내가 동의하는 단호하고 확실한 규칙은 "액션 생성자의 비결정론, 리듀서의 순수한 결정론"입니다. 그것은 주어진 것입니다.

그 이외의? 당신에게 맞는 것을 찾으십시오. 일관성을 유지하십시오. 특정 방식으로 하는 이유를 알 수 있습니다. 함께 가세요.

"발생했습니까?"가 더 많은 작업 작성자 책임으로 간주되지만 "지금은 무엇입니까"는 거의 확실히 감속기 책임입니다.

이것이 바로 부작용, 즉 "what now"의 순수하지 않은 부분을 reducer: #1528에 넣는 방법에 대해 병렬 토론이 있는 이유입니다.

내가 사용한 패턴은 다음과 같습니다.

• 해야 할 일 : 액션/액션 생성기
• 방법 : 미들웨어(예: '비동기' 작업을 수신하고 내 API 개체를 호출하는 미들웨어)
• 결과로 수행할 작업 : 감속기

이 스레드의 앞부분에서 Dan의 진술은 다음과 같습니다.

따라서 공식 권장 사항은 먼저 동일한 작업에 다른 리듀서가 응답하도록 하는 것입니다. 어색해지면 반드시 별도의 액션 크리에이터를 만드세요. 그러나 이 접근 방식으로 시작하지 마십시오.

그런 점에서 권장되는 접근 방식은 이벤트당 하나의 작업을 전달하는 것입니다. 그러나 실용적으로 작동하는 일을 하십시오.

@winstonewert : Dan은 "리듀서 구성" 패턴을 참조합니다. 즉, "하나의 리듀서만 듣는 작업" 대 "많은 리듀서가 동일한 작업에 응답할 수 있음"입니다. Dan은 단일 작업에 응답하는 임의의 리듀서에 대해 매우 관심이 많습니다. 다른 사람들은 리듀서와 액션이 매우 밀접하게 묶이고 오직 하나의 리듀서만이 주어진 액션을 처리하는 "오리" 접근 방식과 같은 것을 선호합니다. 따라서 이 예는 "여러 작업을 순서대로 전달"하는 것이 아니라 "내 감속기 구조의 얼마나 많은 부분이 이에 응답할 것으로 예상되는지"에 관한 것입니다.

그러나 실용적으로 작동하는 일을 하십시오.

:+1:

@sompylasar 내 작업에 상태 구조가 있으면 내 방식의 오류가 표시됩니다. 상태 구조를 내 리듀서로 쉽게 전환하고 내 작업을 단순화할 수 있습니다. 건배.

제가 보기에는 같은 것 같습니다.

여러 상태 변경을 일으키는 여러 감속기를 트리거하는 단일 작업이 있거나 단일 상태 변경을 유발하는 단일 감속기를 각각 트리거하는 여러 작업이 있습니다. 여러 리듀서가 작업에 응답하고 이벤트가 여러 작업을 전달하도록 하는 것은 동일한 문제에 대한 대안 솔루션입니다.

언급한 StackOverflow 질문에서 그는 다음과 같이 말합니다.

가능한 한 사용자 상호 작용의 기록에 가까운 작업 로그를 유지합니다. 그러나 감속기를 구현하기 어렵게 만드는 경우 일부 작업을 여러 개로 분할하는 것을 고려하고 UI 업데이트가 우연히 함께 발생하는 두 개의 개별 작업으로 생각할 수 있다면.

내가 보기에 Dan은 이상적인 방법으로 사용자 상호 작용당 하나의 작업을 유지하는 것을 지지합니다. 그러나 그는 실용적입니다. 감속기를 구현하기 어렵게 만들 때 그는 작업 분할을 지지합니다.

여기에서 유사하지만 다소 다른 사용 사례를 시각화하고 있습니다.

1) 작업을 수행하려면 주의 여러 영역에 대한 업데이트가 필요합니다. 특히 combineReducers 를 사용하여 각 하위 도메인을 처리하는 별도의 감속기 기능을 사용하는 경우에 그렇습니다. 당신은:

• 감속기 A와 감속기 B가 모두 동일한 작업에 응답하고 상태 비트를 독립적으로 업데이트하도록 합니다.
• 모든 리듀서가 자체 청크 외부의 다른 상태 비트에 액세스할 수 있도록 썽크에 모든 관련 데이터를 작업에 넣습니다.
• Reducer A의 상태 비트를 잡고 특수한 경우에 Reducer B에 전달하는 다른 최상위 감속기를 추가하시겠습니까?
• 필요한 상태 비트와 함께 Reducer A를 위한 작업을 전달하고 필요한 상태로 Reducer B를 위한 두 번째 작업을 전달합니까?

2) 특정 순서로 발생하는 일련의 단계가 있으며 각 단계에는 일부 상태 업데이트 또는 미들웨어 작업이 필요합니다. 당신은:

• 각 개별 단계를 개별 작업으로 전달하여 진행 상황을 나타내고 개별 감속기가 특정 작업에 응답하도록 하시겠습니까?
• 하나의 큰 이벤트를 전달하고 리듀서가 이를 적절하게 처리한다고 믿습니까?

네, 확실히 겹치는 부분이 있지만 여기서 정신적인 그림의 차이점 중 일부는 다양한 사용 사례라고 생각합니다.

@markerikson 그래서 당신의 조언은 '어떤 상황을 만났느냐에 달려있다'고, 액션이나 리듀서에서 '비즈니스 로직'의 균형을 맞추는 방법은 당신의 고려에 달려 있습니다. 우리도 가능한 한 순수 기능의 이점을 취해야합니까?

응. 감속기는 Redux 요구 사항으로 순수해야 _가지고_ 있습니다(특별한 경우의 0.00001% 제외). 액션 제작자는 절대적으로 _ 하지 않아도 _ 순수해야 하며 실제로 대부분의 "불순물"이 살 곳입니다. 그러나 순수 함수는 순수 함수보다 이해하고 테스트하기가 분명히 더 쉽기 때문에 _if_ 일부 작업 생성 논리를 순수하고 훌륭하게 만들 수 있습니다! 그렇지 않다면 괜찮습니다.

그리고 네, 제 관점에서 볼 때 앱의 논리와 위치에 적절한 균형이 무엇인지 결정하는 것은 개발자의 몫입니다. 액션 생성자/리듀서 분할의 어느 쪽이 유지되어야 하는지에 대한 단일하고 확실한 규칙은 없습니다. (음, 위에서 언급한 "결정론/비결정론"을 제외하고. 이 주석에서 분명히 언급하려고 했던 것입니다. 분명히.)

@cpsubrian

결과로 수행할 작업: 감속기

실제로 이것이 saga가 "이런 일이 발생했다면, 그것도 발생해야 합니다"와 같은 효과를 처리하는 이유입니다.

@markerikson @LumiaSaki

액션 제작자는 절대적으로 순수할 필요가 없으며 실제로 대부분의 "불순물"이 살 곳입니다.

실제로 액션 크리에이터는 불순하거나 존재할 필요조차 없습니다.
http://stackoverflow.com/a/34623840/82609 참조

그리고 네, 제 관점에서 볼 때 앱의 논리와 위치에 적절한 균형이 무엇인지 결정하는 것은 개발자의 몫입니다. 액션 생성자/리듀서 분할의 어느 쪽이 유지되어야 하는지에 대한 단일하고 확실한 규칙은 없습니다.

예, 하지만 경험 없이 각 접근 방식의 단점을 알아차리는 것은 그리 분명하지 않습니다. 여기에서 내 의견도 참조하십시오. https://github.com/reactjs/redux/issues/1171#issuecomment -167585575

엄격한 규칙은 대부분의 간단한 앱에 적합하지 않지만 재사용 가능한 구성 요소를 빌드하려는 경우 이러한 구성 요소는 자체 범위 밖의 것을 인식해서는 안 됩니다.

따라서 전체 앱에 대한 전역 작업 목록을 정의하는 대신 앱을 재사용 가능한 구성 요소로 분할할 수 있으며 각 구성 요소에는 자체 작업 목록이 있으며 이러한 작업만 전달/축소할 수 있습니다. 문제는 "날짜 선택기에서 날짜가 선택되면 해당 할 일 항목에 미리 알림을 저장하고 피드백 알림을 표시한 다음 미리 알림이 있는 할일 목록으로 앱을 탐색해야 합니다"를 어떻게 표현합니까? saga가 실행됩니다: 구성 요소를 오케스트레이션

https://github.com/slorber/scalable-frontend-with-elm-or-redux 도

그리고 네, 제 관점에서 볼 때 앱의 논리와 위치에 적절한 균형이 무엇인지 결정하는 것은 개발자의 몫입니다. 액션 생성자/리듀서 분할의 어느 쪽이 유지되어야 하는지에 대한 단일하고 확실한 규칙은 없습니다.

예, 리듀서에 로직을 넣든 액션 생성자에 로직을 넣든 Redux의 요구 사항은 없습니다. Redux는 어느 쪽이든 중단되지 않습니다. 어떤 식으로든 해야 한다는 엄격하고 빠른 규칙은 없습니다. 그러나 Dan의 권장 사항은 "가능한 한 사용자 상호 작용의 기록에 가까운 작업 로그를 유지"하는 것이었습니다. 사용자 이벤트당 단일 작업을 전달할 필요는 없지만 권장됩니다.

제 경우에는 1개의 작업에 관심이 있는 2개의 감속기가 있습니다. 원시 action.data로는 충분하지 않습니다. 변환된 데이터를 처리해야 합니다. 2개의 감속기에서 변환을 수행하고 싶지 않았습니다. 그래서 썽크로 변환을 수행하는 함수를 옮겼습니다. 이런 식으로 내 리듀서는 사용할 준비가 된 데이터를 받습니다. 이것은 내 짧은 1개월 redux 경험에서 생각할 수 있는 최고입니다.

상점 구조에서 구성 요소/보기를 분리하는 것은 어떻습니까? 내 목표는 저장소 구조의 영향을 받는 모든 것이 리듀서에서 관리되어야 하는 것입니다. 그래서 선택기를 리듀서와 함께 배치하는 것을 좋아하므로 구성 요소가 저장소의 특정 노드를 얻는 방법을 알 필요가 없습니다.

이는 구성 요소에 데이터를 전달하는 데 유용합니다. 구성 요소가 작업을 전달할 때 반대의 경우는 어떻습니까?

예를 들어 Todo 앱에서 Todo 항목의 이름을 업데이트하고 있으므로 업데이트하려는 항목의 일부를 전달하는 작업을 전달한다고 가정해 보겠습니다.

dispatch(updateItem({name: <text variable>}));

, 작업 정의는 다음과 같습니다.

const updateItem = (updatedData) => {type: "UPDATE_ITEM", updatedData}

이것은 간단히 다음을 수행할 수 있는 감속기에 의해 처리됩니다.

Object.assign({}, item, action.updatedData)

항목을 업데이트합니다.

이것은 동일한 작업과 감속기를 재사용하여 Todo 항목의 모든 소품을 업데이트할 수 있으므로 훌륭하게 작동합니다. 예:

updateItem({description: <text variable>})

대신 설명이 변경된 경우.

그러나 여기서 구성 요소는 상점에서 Todo 항목이 어떻게 정의되는지 알아야 하고 해당 정의가 변경되면 그것에 의존하는 모든 구성 요소에서 변경하는 것을 기억해야 합니다. 이는 분명히 나쁜 생각입니다. 이 시나리오에 대한 제안 사항이 있습니까?

@dcoellarb

이런 종류의 상황에서 내 솔루션은 상용구를 생성하기 위해 Javascript의 유연성을 활용하는 것입니다.

그래서 나는 가질 수 있습니다 :

const {reducer, actions, selector} = makeRecord({
    name: TextField,
    description: TextField,
    completed: BooleanField
})

여기서 makeRecord는 내 설명에서 자동으로 감속기, 액션 생성기 및 선택기를 빌드하는 기능입니다. 이렇게 하면 상용구가 제거되지만 나중에 이 깔끔한 패턴에 맞지 않는 작업을 수행해야 하는 경우 makeRecord의 결과에 사용자 지정 감속기/동작/선택기를 추가할 수 있습니다.

tks @winstonewert 나는 상용구를 피하기 위한 접근 방식을 좋아합니다. 많은 모델이 있는 앱에서 많은 시간을 절약할 수 있다는 것을 알 수 있습니다. 그러나 이것이 어떻게 구성 요소를 저장소 구조에서 분리하는지 알 수 없습니다. 즉, 작업이 생성되더라도 구성 요소는 업데이트된 필드를 여전히 전달해야 합니다. 즉, 구성 요소는 여전히 다음 구조를 알아야 합니다. 가게 맞지?

@winstonewert @dcoellarb 제 생각에는 액션 페이로드 구조는 리듀서가 아닌 액션에 속해야 하며 리듀서에서 명시적으로 상태 구조로 변환되어야 합니다. 이러한 구조가 초기 단순성을 위해 서로 미러링된다는 것은 운이 좋은 우연의 일치일 것입니다. 이 두 구조는 동일한 개체가 아니기 때문에 항상 서로를 미러링할 필요가 없습니다.

@sompylasar 맞아요, 그렇게 해요. api/rest 데이터를 내 저장소 구조로 변환하지만 여전히 저장소 구조를 알아야 하는 유일한 것은 감속기와 선택기뿐인가요? 내가 그들을 같은 위치에 배치하는 이유, 내 문제는 구성 요소/보기에 있습니다. 나중에 변경하기로 결정할 경우에 대비하여 상점 구조를 알 필요가 없는 것을 선호하지만 내 예에서 설명했듯이 구조를 알아야 할 수 있습니다. 업데이트할 올바른 데이터를 보내십시오. 더 좋은 방법을 찾지 못했습니다.

@dcoellarb 보기를 특정 유형의 데이터 입력으로 생각할 수 있습니다(문자열 또는 숫자와 같지만 필드가 있는 구조화된 개체). 이 데이터 개체는 반드시 저장소 구조를 미러링하지는 않습니다. 이 데이터 개체를 작업에 넣습니다. 이것은 상점 구조와 결합되지 않습니다. 스토어와 뷰는 모두 액션 페이로드 구조와 결합되어야 합니다.

@sompylasar 는 의미가 있습니다. 시도해 보겠습니다. 감사합니다!!!

redux-saga 를 사용하여 액션을 더 순수하게 만들 수 있다고 덧붙이셔야 합니다. 그러나 redux-saga는 비동기 이벤트를 처리하는 데 어려움을 겪으므로 redux-saga 대신 RxJS(또는 모든 FRP 라이브러리)를 사용하여 이 아이디어를 한 단계 더 발전시킬 수 있습니다. 다음은 KefirJS를 사용한 예입니다. https://github.com/awesome-editor/awesome-editor/blob/saga-demo/src/stores/app/AppSagaHandlers.js

안녕하세요 @frankandrobot 입니다 .

redux-saga는 비동기 이벤트를 처리하기 위해 고군분투합니다.

이게 무슨 말이에요? redux-saga 는 비동기 이벤트와 부작용을 우아한 방식으로 처리하도록 만들어지지 않았습니까? https://github.com/reactjs/redux/issues/1171#issuecomment -167715393을 살펴보세요.

아니 @IceOnFire . 지난번에 redux-saga 문서를 읽었을 때 복잡한 비동기 워크플로를 처리하는 것은 어렵습니다. 예를 들어 참조: http://yelouafi.github.io/redux-saga/docs/advanced/NonBlockingCalls.html
그것은 (여전히 말합니까?) 효과에 대해 무언가를 말했습니다.

복잡해지기 시작하기 때문에 나머지 세부 사항은 독자에게 맡기겠습니다.

FRP 방식과 비교: https://github.com/frankandrobot/rflux/blob/master/doc/06-sideeffects.md#a -more-complex-workflow
전체 워크플로가 완전히 처리됩니다. (몇 줄만 추가하면 됩니다.) 게다가 redux-saga 의 장점도 대부분 얻을 수 있습니다(모든 것이 순수 함수이며 대부분 쉬운 단위 테스트임).

마지막으로 이것에 대해 생각했을 때 문제는 redux-saga가 모든 것을 동기식으로 보이게 한다는 결론에 도달했습니다. 간단한 워크플로에는 훌륭하지만 복잡한 비동기 워크플로의 경우 비동기를 명시적으로 처리하면 더 쉽습니다. 이것이 FRP가 탁월한 것입니다.

안녕하세요 @frankandrobot 입니다 .

설명해주셔서 감사합니다. 나는 당신이 언급한 인용문을 볼 수 없습니다. 아마도 라이브러리가 진화했을 것입니다(예를 들어, 지금은 전에 본 적이 없는 cancel 효과를 봅니다).

두 예제(saga 및 FRP)가 정확히 동일하게 동작하는 경우 큰 차이가 없습니다. 하나는 try/catch 블록 내부의 명령 시퀀스이고 다른 하나는 스트림의 메서드 체인입니다. 스트림에 대한 경험이 부족하기 때문에 yield 하나하나를 하나씩 테스트할 수 있으므로 사가 예제를 더 읽기 쉽고 테스트하기가 더 쉽습니다. 그러나 이것은 기술보다 내 마음가짐 때문이라고 확신합니다.

어쨌든 이에 대한 @yelouafi 의 의견을 알고

@bvaughn 여기에 설명하는 것과 동일한 테스트에서 작업, 감속기, 선택기를 테스트하는 적절한 예를

작업, 감속기 및 선택기를 테스트하는 가장 효율적인 방법은 테스트를 작성할 때 "덕" 접근 방식을 따르는 것입니다. 이것은 각각에 개별적으로 초점을 맞추는 3세트의 테스트가 아니라 주어진 일련의 작업, 감속기 및 선택기를 다루는 하나의 테스트 세트를 작성해야 함을 의미합니다. 이렇게 하면 실제 애플리케이션에서 발생하는 상황을 보다 정확하게 시뮬레이션하고 비용 대비 효과를 극대화할 수 있습니다.

안녕하세요 @morgs32 😄

이 문제는 조금 오래되었고 Redux를 한동안 사용하지 않았습니다. Redux 사이트에 테스트 작성 에 대한 섹션이 있으니 확인해보세요.

기본적으로 저는 액션과 리듀서에 대한 테스트를 따로 작성하는 것보다 다음과 같이 함께 작성하는 것이 더 효율적일 수 있다는 점을 지적했습니다.

import configureMockStore from 'redux-mock-store'
import { actions, selectors, reducer } from 'your-redux-module';

it('should support adding new todo items', () => {
  const mockStore = configureMockStore()
  const store = mockStore({
    todos: []
  })

  // Start with a known state
  expect(selectors.todos(store.getState())).toEqual([])

  // Dispatch an action to modify the state
  store.dispatch(actions.addTodo('foo'))

  // Verify the action & reducer worked successfully using your selector
  // This has the added benefit of testing the selector also
  expect(selectors.todos(store.getState())).toEqual(['foo'])
})

이것은 프로젝트에서 몇 달 동안 Redux를 사용한 후 관찰한 것입니다. 공식적인 권장 사항이 아닙니다. YMMV. 👍

"액션 크리에이터에서 더 많은 일을 하고 리듀서에서 더 적게 수행"

애플리케이션이 서버&클라이언트이고 서버에 비즈니스 로직과 유효성 검사기가 포함되어야 하는 경우에는 어떻게 됩니까?
그래서 나는 액션을 그대로 보내고 대부분의 작업은 서버 측에서 감속기에 의해 수행됩니다 ...

먼저, 내 영어에 대해 죄송합니다. 하지만 저는 약간 다른 의견을 가지고 있습니다.

제 선택은 fat 리듀서, thin 액션 크리에이터입니다.

내 작업 생성자는 일부 __promise 미들웨어__를 기반으로 하는 __dispatch__ 작업(비동기, 동기화, 직렬 비동기, 병렬 비동기, for 루프의 병렬 비동기)입니다.

내 리듀서는 비즈니스 로직을 처리하기 위해 많은 작은 상태 슬라이스로 분할됩니다. combineReduers 하여 결합하십시오. reducer 는 __순수 함수__이므로 재사용하기 쉽습니다. 언젠가 AngularJS를 사용하게 되면 동일한 비즈니스 로직을 위해 내 서비스에서 reducer 를 재사용할 수 있을 것입니다. reducer 에 라인 코드가 많으면 더 작은 리듀서로 분할하거나 일부 기능을 추상화할 수 있습니다.

예, A 가 B, C 에 의존하고 B, C 가 비동기 데이터임을 의미하는 교차 상태 사례가 있습니다. A를 채우거나 초기화하려면 B,C 를 사용해야 합니다. 그래서 crossSliceReducer 합니다.

__액션 크리에이터에서 더 많은 일을 하고 리듀서에서 더 적은 일을 하십시오__.

1. redux-thunk 등을 사용한다면 그렇습니다. getState() 액션 생성자 내에서 전체 상태에 액세스할 수 있습니다. 이것은 선택입니다. 또는 일부 __crossSliceReducer__를 생성하여 전체 상태에도 액세스할 수 있고 일부 상태 슬라이스를 사용하여 다른 상태를 계산할 수 있습니다.

__단위 테스트__ 정보

reducer 는 __순수 함수__입니다. 그래서 테스트하기 쉽습니다. 지금은 다른 부분보다 가장 중요하기 때문에 감속기를 테스트합니다.

action creators 를 테스트하려면? 나는 그들이 "뚱뚱한"것이라면 테스트하기가 쉽지 않을 것이라고 생각합니다. 특히 __async 액션 생성자__.

@mrdulin에 동의합니다. 이제 저도 그렇게 되었습니다.

@mrdulin 네. 미들웨어가 불순한 논리를 배치하기에 적합한 장소인 것 같습니다.
그러나 비즈니스 논리 감속기는 올바른 장소처럼 보이지 않습니다. 사용자가 요청한 것이 아니라 비즈니스 논리에 필요한 것을 나타내는 여러 "종합적인" 작업으로 끝납니다.

훨씬 더 간단한 선택은 미들웨어에서 일부 순수 함수/클래스 메서드를 호출하는 것입니다.

middleware = (...) => {
  // if(action.type == 'HIGH_LEVEL') 
  handlers[action.name]({ dispatch, params: action.payload })
}
const handlers = {
  async highLevelAction({ dispatch, params }) {
    dispatch({ loading: true });
    const data = await api.getData(params.someId);
    const processed = myPureLogic(data);
    dispatch({ loading: false, data: processed });
  }
}

@bvaughn

이렇게 하면 미묘하게 정의되지 않은 값으로 이어지는 잘못된 유형의 변수 가능성이 줄어들고 상점 구조 등의 변경이 간소화됩니다.

메모이제이션이나 어떤 종류의 데이터 변환이 필요하지 않은 사소한 상태의 경우에도 모든 곳에서 선택기를 사용하는 것에 반대하는 제 경우:

• 리듀서에 대한 단위 테스트는 이미 잘못 입력된 상태 속성을 잡아야 하지 않습니까?
• 매장 구조의 변경 은 제 경험상 state.stuff.item1 를 state.stuff.item2 변경하면 코드를 검색하여 모든 곳에서 변경합니다. 마치 다른 이름을 실제로 변경하는 것과 같습니다. 특히 IDE를 사용하는 사람들에게는 일반적인 작업이며 생각할 필요도 없습니다.
• 모든 곳에서 선택기를 사용하는 것은 일종의 공허한 추상화입니다. 간단한 상태 부분에 직접 액세스하는 이 문제를 결코 이해하지 못했습니다. 물론 이 API를 통해 상태에 액세스하면 일관성을 얻을 수 있지만 단순성을 포기합니다.

분명히 선택자는 필요하지만 필수 API로 만들기 위한 몇 가지 다른 주장을 듣고 싶습니다.

실용적인 관점에서 내 경험에 따르면 좋은 이유 중 하나는 reselect 또는 redux-saga와 같은 라이브러리가 선택기를 활용하여 상태 조각에 액세스하기 때문입니다. 이것은 내가 선택기를 사용하기에 충분합니다.

철학적으로 말해서, 나는 항상 선택자를 기능적 세계의 "게터 메소드"로 봅니다. 그리고 내가 Java 객체의 public 속성에 절대 접근하지 않는 것과 같은 이유로 Redux 앱에서 직접 하위 상태에 접근하지도 않을 것입니다.

@IceOnFire 계산이 비싸지 않거나 데이터 변환이 필요하지 않은 경우 활용할 것이 없습니다.

Getter 메서드는 Java에서 일반적인 관행일 수 있지만 JS에서 직접 POJO에 액세스하는 것도 마찬가지입니다.

@timotgl

스토어와 다른 redux 코드 사이에 API가 있는 이유는 무엇인가요?

선택자는 리듀서의 쿼리(읽기) 공개 API이고, 액션은 리듀서의 명령(쓰기) 공개 API입니다. Reducer의 구조는 구현 세부 사항입니다.

선택기와 액션은 리듀서 자체가 아니라 UI 레이어와 사가 레이어(redux-saga를 사용하는 경우)에서 사용됩니다.

@sompylasar 여기에서 귀하의 관점을 따르는지 잘 모르겠습니다. 액션에 대한 대안은 없습니다. redux와 상호 작용하려면 액션을 사용해야 합니다. 나는 그냥으로 설계된이 노출 된 상태에서 직접 무언가를 선택할 수 있습니다, 그러나 선택기를 사용할 필요가 없습니다.

선택기를 감속기의 "읽기" API로 생각하는 방법을 설명하고 있지만 제 질문은 선택기를 처음에 필수 API로 만드는 것을 정당화하는 것이었습니다(라이브러리가 아닌 프로젝트에서 모범 사례로 시행할 때 필수입니다. 설계).

@timotgl 예, 선택자는 필수가 아닙니다. 그러나 앱 코드의 향후 변경 사항에 대비하여 개별적으로 리팩토링할 수 있도록 하는 좋은 방법입니다.

• 특정 상태가 어떻게 구조화되고 작성되는지 (리듀서 문제, 한 곳)
• 해당 상태 부분이 사용되는 방식(UI 및 부작용 문제, 동일한 상태 부분이 쿼리되는 여러 위치)

저장소 구조를 변경하려고 할 때 선택기 없이 영향을 받는 상태 조각에 액세스하는 모든 위치를 찾고 리팩터링해야 하며 이는 잠재적으로 단순한 찾기 및-가 아닌 사소한 작업이 될 수 있습니다. 특히 선택기를 통하지 않고 상점에서 직접 얻은 상태 조각을 전달하는 경우 교체하십시오.

@sompylasar 입력

이것은 잠재적으로 사소한 일이 될 수 있습니다

그것은 타당한 우려입니다. 저에게는 값비싼 절충안처럼 보입니다. 그런 문제를 일으킨 상태 리팩토링을 본 적이 없는 것 같습니다. 그러나 나는 "선택자 스파게티"를 접했는데, 상태의 모든 사소한 하위 부분에 대한 중첩 선택자가 상당한 혼란을 야기했습니다. 이 대책 자체도 결국 유지되어야 합니다. 하지만 지금은 그 이유를 더 잘 이해하고 있습니다.

@timotgl 공개적으로 공유할 수 있는 간단한 예:

export const PROMISE_REDUCER_STATE_IDLE = 'idle';
export const PROMISE_REDUCER_STATE_PENDING = 'pending';
export const PROMISE_REDUCER_STATE_SUCCESS = 'success';
export const PROMISE_REDUCER_STATE_ERROR = 'error';

export const PROMISE_REDUCER_STATES = [
  PROMISE_REDUCER_STATE_IDLE,
  PROMISE_REDUCER_STATE_PENDING,
  PROMISE_REDUCER_STATE_SUCCESS,
  PROMISE_REDUCER_STATE_ERROR,
];

export const PROMISE_REDUCER_ACTION_START = 'start';
export const PROMISE_REDUCER_ACTION_RESOLVE = 'resolve';
export const PROMISE_REDUCER_ACTION_REJECT = 'reject';
export const PROMISE_REDUCER_ACTION_RESET = 'reset';

const promiseInitialState = { state: PROMISE_REDUCER_STATE_IDLE, valueOrError: null };
export function promiseReducer(state = promiseInitialState, actionType, valueOrError) {
  switch (actionType) {
    case PROMISE_REDUCER_ACTION_START:
      return { state: PROMISE_REDUCER_STATE_PENDING, valueOrError: null };
    case PROMISE_REDUCER_ACTION_RESOLVE:
      return { state: PROMISE_REDUCER_STATE_SUCCESS, valueOrError: valueOrError };
    case PROMISE_REDUCER_ACTION_REJECT:
      return { state: PROMISE_REDUCER_STATE_ERROR, valueOrError: valueOrError };
    case PROMISE_REDUCER_ACTION_RESET:
      return { ...promiseInitialState };
    default:
      return state;
  }
}

export function extractPromiseStateEnum(promiseState = promiseInitialState) {
  return promiseState.state;
}
export function extractPromiseStarted(promiseState = promiseInitialState) {
  return (promiseState.state === PROMISE_REDUCER_STATE_PENDING);
}
export function extractPromiseSuccess(promiseState = promiseInitialState) {
  return (promiseState.state === PROMISE_REDUCER_STATE_SUCCESS);
}
export function extractPromiseSuccessValue(promiseState = promiseInitialState) {
  return (promiseState.state === PROMISE_REDUCER_STATE_SUCCESS ? promiseState.valueOrError || null : null);
}
export function extractPromiseError(promiseState = promiseInitialState) {
  return (promiseState.state === PROMISE_REDUCER_STATE_ERROR ? promiseState.valueOrError || true : null);
}

저장되는 것이 state, valueOrError 인지 아니면 다른 것인지는 이 감속기 사용자의 관심사가 아닙니다. 상태 문자열(열거형), 해당 상태에 대해 자주 사용되는 몇 가지 검사, 값 및 오류가 노출됩니다.

그러나 나는 "선택자 스파게티"를 접했는데, 상태의 모든 사소한 하위 부분에 대한 중첩 선택자가 상당한 혼란을 야기했습니다.

이 중첩이 리듀서 중첩(구성)을 미러링하여 발생한 경우 권장하지 않는 것은 해당 감속기의 구현 세부정보입니다. 위의 예를 사용하여 상태의 일부에 대해 promiseReducer를 사용하는 감속기는 이러한 부분에 따라 명명된 자체 선택기를 내보냅니다. 또한 선택기처럼 보이는 모든 기능을 내보내고 감속기 API의 일부가 되어야 하는 것은 아닙니다.

function extractTransactionLogPromiseById(globalState, transactionId) {
  return extractState(globalState).transactionLogPromisesById[transactionId] || undefined;
}

export function extractTransactionLogPromiseStateEnumByTransactionId(globalState, transactionId) {
  return extractPromiseStateEnum(extractTransactionLogPromiseById(globalState, transactionId));
}

export function extractTransactionLogPromiseErrorTransactionId(globalState, transactionId) {
  return extractPromiseError(extractTransactionLogPromiseById(globalState, transactionId));
}

export function extractTransactionLogByTransactionId(globalState, transactionId) {
  return extractPromiseSuccessValue(extractTransactionLogPromiseById(globalState, transactionId));
}

아, 내가 거의 잊어 버린 또 하나. 함수 이름과 내보내기/가져오기는 잘되고 안전하게 축소될 수 있습니다. 중첩된 개체 키 — 그다지 많지는 않지만 코드를 망치지 않으려면 축소기에 적절한 데이터 흐름 추적기가 필요합니다.

@timotgl : Redux에 대해 권장되는 많은 모범 사례는 Redux 관련 논리 및 동작을 캡슐화하려는 시도에 관한 것입니다.

예를 들어 this.props.dispatch({type : "INCREMENT"}) 를 수행하여 연결된 구성 요소에서 직접 작업을 전달할 수 있습니다. 그러나 구성 요소가 Redux와 통신하고 있음을 "알게" 하기 때문에 권장하지 않습니다. 더 React 관용적인 방법은 바인딩된 작업 생성자를 전달하여 구성 요소가 this.props.increment() 호출할 수 있도록 하고 해당 함수가 바인딩된 Redux 작업 생성자인지 여부는 중요하지 않습니다. 콜백 전달 부모에 의해 다운되거나 테스트의 모의 함수.

모든 곳에서 작업 유형을 직접 작성할 수도 있지만 상수 변수를 정의하여 가져오고 추적하고 오타 가능성을 줄일 수 있도록 하는 것이 좋습니다.

마찬가지로 mapState 함수 또는 썽크에서 state.some.deeply.nested.field 에 액세스하는 것을 방해하는 것은 없습니다. 그러나 이 스레드에서 이미 설명했듯이 이는 오타의 가능성을 높이고 특정 상태가 사용되는 위치를 추적하기 어렵게 만들고 리팩토링을 더 어렵게 만들고 값비싼 변환 논리가 - 필요하지 않더라도 매번 실행합니다.

따라서 선택자를 사용할 _가지고 있지_는 않지만 좋은 아키텍처 관행입니다.

내 게시물 Idiomatic Redux: Using Reselect Selectors for Encapsulation and Performance 를 읽고 싶을 수도 있습니다.

@markerikson 나는 일반적으로 선택기나 값비싼 계산을 위한 선택기에 대해 논쟁하지 않습니다. 그리고 나는 디스패치 자체를 구성 요소에 전달할 의도가 없었습니다. :)

내 요점은 내가 이 믿음에 동의하지 않는다는 것입니다.

이상적으로는 감속기 기능과 선택기만 정확한 상태 구조를 알아야 하므로 일부 상태가 있는 위치를 변경하는 경우 이 두 가지 논리만 업데이트하면 됩니다.

state.some.deeply.nested.field 대한 귀하의 예에 대해, 나는 이것을 줄이기 위해 선택기를 갖는 가치를 볼 수 있습니다. selectSomeDeeplyNestedField() 는 하나의 함수 이름과 내가 잘못 생각할 수 있는 5개의 속성입니다.

반면에, 이 가이드라인을 편지에 따른다면 const selectSomeField = state => state.some.field; 또는 const selectSomething = state => state.something; 되며 어느 시점에서 이를 일관되게 수행하는 오버헤드(가져오기, 내보내기, 테스트)를 하게 됩니다. 내 의견으로는 더 이상 (논쟁의 여지가 있는) 안전과 순결을 정당화하지 않습니다. 좋은 취지지만 가이드라인의 독단적인 정신을 떨칠 수 없다. 나는 내 프로젝트의 개발자가 선택기를 현명하게 사용하고 적용할 수 있다고 믿습니다. 왜냐하면 지금까지 내 경험이 그렇게 했기 때문입니다.

특정 조건에서 나는 당신이 왜 안전과 관습의 측면에서 실수를 하고 싶어하는지 알 수 있었습니다. 귀하의 시간과 참여에 감사드립니다. redux가 있어서 전반적으로 매우 기쁩니다.

확신하는. FWIW에는 다른 선택기 라이브러리와 Reselect 주변의 래퍼 도 있습니다. 예를 들어 https://github.com/planttheidea/selectorator를 사용하면 점 표기법 키 경로를 정의할 수 있으며 내부적으로 중간 선택기를 수행합니다.