흥미로운 접근! XHR을 실행하는 데 사용되는 방법이나 웹 요청이 애초에 비동기의 소스인 것처럼 비동기의 특성에서 이상적으로 분리되어야 하는 것 같습니다.

나도 redux에서 부작용을 처리하는 대안적인 방법에 대해 많이 생각하고 있으며 현재 접근 방식에서 볼 수 있는 몇 가지 문제와 이것이 왜 그리고 어떻게 생각하는지 브레인 덤프할 때 스레드를 가로채지 않기를 바랍니다. 겉보기에 단순함에도 불구하고 올바른 방향으로 큰 발걸음을 내디뎠습니다.

액션 크리에이터의 부작용 문제

순수 함수형 언어에서 부작용은 항상 응용 프로그램의 가장자리로 들어 올려지고 실행을 위해 런타임으로 반환됩니다. Elm에서 리듀서는 새로운 상태와 실행되어야 하는 효과를 포함하는 튜플을 반환합니다. 그러나 이 서명이 있는 메서드는 아직 다른 redux 리듀서로 구성할 수 없습니다.

redux에서 부작용을 수행할 수 있는 명백한(하지만 가장 좋은 것은 아님) 작업 작성자가 되었으며 이 패턴을 지원하기 위해 여러 다른 미들웨어 옵션이 개발되었습니다. 그러나 현재의 미들웨어 접근 방식은 리듀서의 일급 개념으로 부작용을 반환할 수 없는 해결 방법에 가깝다고 생각합니다.

사람들은 여전히 ​​redux를 사용하여 멋진 것을 만들고 있으며 큰 진전을 이루고 대부분의 대안보다 훨씬 간단하고 실용적이지만, 액션 제작자 내부에서 부작용이 발생하는 데 몇 가지 문제가 있습니다.

• 암시적 상태가 숨겨짐
• 비즈니스 로직의 복제
• 컨텍스트 가정 및/또는 종속성은 재사용성을 감소시킵니다.
• 부작용이 있는 액션 제작자는 테스트하기 어렵습니다.
• 최적화하거나 일괄 처리할 수 없음

암시적 상태가 숨겨짐

카운터 응용 프로그램에서 incrementAsync는 시간 초과를 생성하고 완료 시에만 응용 프로그램 상태가 업데이트됩니다. 예를 들어 증분 작업이 진행 중이라는 시각적 표시기를 표시하려는 경우 보기는 애플리케이션 상태에서 이를 유추할 수 없습니다. 이 상태는 암시적이며 숨겨져 있습니다.

때때로 우아하긴 하지만 암시적 상태가 숨겨져 있고 쉽게 직렬화할 수 없기 때문에 생성기를 작업 생성자의 조정자 로 사용하는

redux-thunk 또는 이와 유사한 것을 사용하면 증가 작업이 시작되고 완료될 때 이를 알리는 여러 메시지를 감속기에 보낼 수 있지만 이는 다른 문제 세트를 생성합니다.

효과가 완료된 후 증가 작업이 진행 중인 것으로 표시되는 지점으로 상태를 되감는 것은 실제로 부작용을 재생성하지 않으므로 무기한 진행 상태로 유지됩니다.

귀하의 제안이 이 문제를 해결하는 것으로 보입니다. 부작용은 상태에서 생성되기 때문에 의도는 어떤 형태로든 결과 상태로 표현되어야 하므로 저장소를 작업이 시작된 이전 상태로 되돌리면 반응은 효과를 다시 시작하는 대신 효과를 다시 시작합니다. 상태를 림보 상태로 두십시오.

비즈니스 로직의 복제

애플리케이션이 특정 상태일 때만 액션이 부작용을 일으키는 것은 당연하다. redux에서 액션 생성자가 상태를 요구한다면 그것은 단순하고 순수한 함수이거나 명시적으로 상태와 함께 제공되어야 합니다.

간단한 예로, 예제 카운터 응용 프로그램으로 시작하여 카운터가 5의 배수일 때마다 카운터를 임의의 글꼴 색상으로 변경하려고 한다고 가정해 보겠습니다.

난수 생성은 순수하지 않으므로 이 동작을 두는 제안된 위치는 작업 생성자입니다. 그러나 카운터, 증분, 감소, incrementAsync, incrementIfOdd(이 경우 수정할 필요가 없음) 값을 변경할 수 있는 몇 가지 다른 작업이 있습니다.

이전에 증가 및 감소는 이전에 감속기에서 처리되었으므로 현재 값에 액세스할 수 있었기 때문에 상태가 필요하지 않았지만 감속기는 부작용(난수 생성)을 가지거나 반환할 수 없기 때문에 이제 이러한 함수는 새로운 임의의 글꼴 색상을 선택해야 하고 이 논리를 모든 대응 조치 작성자에서 복제해야 하는지 여부를 결정하기 위해 현재 카운터 값을 알아야 합니다.

현재 상태를 명시적으로 제공하는 한 가지 가능한 대안은 redux-thunk를 사용하고 현재 상태에 액세스하기 위해 콜백을 반환하는 것입니다. 이렇게 하면 현재 값을 제공하기 위해 생성된 모든 장소 작업을 수정하는 것을 피할 수 있지만 이제 작업 작성자는 전역 응용 프로그램 상태에서 값이 저장된 위치를 알아야 하며 이는 동일한 응용 프로그램 또는 상태가 다르게 구성될 수 있는 다른 응용 프로그램에서.

컨텍스트 가정 및/또는 종속성은 재사용성을 감소시킵니다.

카운터 예제를 다시 방문하면 카운터 인스턴스가 하나만 있음을 알 수 있습니다. 동일한 상태를 보거나 업데이트하는 많은 카운터가 페이지에 있는 것은 쉽지만 각 카운터가 다른 상태를 사용하도록 하려면 카운터를 추가로 수정해야 합니다.

이것은 감속기 및 구성 요소 향상기로 일반 목록을 만드는 방법 이전에 논의되었습니다

카운터가 단순 작업 유형만 사용했다면 느릅나무 아키텍처 를 적용하는 것은 비교적 간단합니다.

이 경우 부모는 단순히 액션 생성자 또는 디스패처를 래핑하여 필요한 컨텍스트로 메시지를 보강한 다음 현지화된 상태로 직접 리듀서를 호출할 수 있습니다.

React Elmish 예제 가 인상적으로

incrementIfOdd는 현재 상태를 결정하기 위해 미들웨어에 의존하므로 애플리케이션 상태 내에서의 위치를 ​​알아야 합니다.

incrementAsync는 결국 부모 구성 요소에 노출되지 않으므로 추가 컨텍스트로 래핑할 수 없는 증분 작업을 직접 전달합니다.

귀하의 제안이 이 문제를 직접 해결하지는 않지만 incrementAsync가 상태를 {counter: 0, incrementAfterDelay: 1000} 로 변경하여 스토어 리스너에서 부작용을 유발하는 간단한 작업으로 구현된 경우 incrementAsync는 간단한 메시지가 됩니다. incrementIfOdd는 순수하므로 감속기에서 구현하거나 명시적으로 상태를 제공할 수 있습니다.... 따라서 원하는 경우 elm 아키텍처를 다시 적용할 수 있습니다.

부작용이 있는 액션 제작자는 테스트하기 어렵습니다.

나는 이것이 부작용을 테스트하기가 더 어려울 것이라는 것이 매우 분명하다고 생각합니다. 일단 부작용이 현재 상태와 비즈니스 논리에 따라 달라지면 테스트가 더 어려울 뿐만 아니라 더 중요해집니다.

귀하의 제안을 통해 상태 전환이 실제로 어떤 반응도 실행하지 않고 원하는 반응을 포함하는 상태를 생성한다는 테스트를 쉽게 작성할 수 있습니다. 반응은 또한 조건부 상태나 비즈니스 로직이 필요하지 않기 때문에 테스트하기 더 쉽습니다.

최적화하거나 일괄 처리할 수 없음

John A De Goes의 최근 블로그 게시물은 효과를 표현하기 위한 IO 또는 태스크와 같은 불투명한 데이터 유형의 문제에 대해 논의했습니다. 불투명한 유형보다 부작용에 대한 선언적 설명을 사용하면 나중에 효과를 최적화하거나 결합할 가능성이 있습니다.

FP를 위한 현대 아키텍처

썽크, 약속 및 생성기는 불투명하므로 일괄 처리 및/또는 중복 API 호출 억제와 같은 최적화는 fetchPostsIfNeeded 와 유사한 함수를 사용하여 명시적으로 처리해야 합니다.

귀하의 제안은 fetchPostsIfNeeded 제거 reactions 기능을 구현하는 것이 완전히 실현 가능한 것 같습니다.

내 구현

나는 최근에 새로운 상태를 반환하는 리듀서를 만들 수 있는 redux 의

기존 리듀서 코드와의 호환성을 유지하기 위해 기존 리듀서에 대한 효과를 높이기 위해 compose 및 CombineReducers를 수정해야 했기 때문에 redux를 분기하지 않고 이 작업을 수행하는 방법을 확신하지 못했습니다.

그러나 귀하의 제안은 redux를 수정할 필요가 없다는 점에서 꽤 좋습니다. 또한 귀하의 솔루션이 암시적 은닉 상태 문제를 해결하는 데 더 나은 작업을 수행하고 결과 반응을 결합하거나 최적화하기가 더 쉬울 것이라고 생각합니다.

요약

React가 "단지 UI"이고 실제로 애플리케이션 상태를 저장하거나 업데이트하는 방법에 대해 그다지 규범적이지 않은 것처럼 Redux는 대부분 "그냥 상점"이며 부작용을 처리하는 방법에 대해 그다지 규범적이지 않습니다.

나는 실용적이고 작업을 완료한 사람을 탓하지 않으며 redux와 미들웨어에 대한 많은 기여자들은 사람들이 이전보다 더 빠르고 더 나은 정말 멋진 것을 만들 수 있게 해주었습니다. 우리가 여기까지 올 수 있었던 것은 그들의 공헌 덕분입니다. 공헌한 모든 분들께 특히 감사드립니다.

Redux는 굉장합니다. 이것들은 Redux 자체의 필수 문제는 아니지만 현재 아키텍처 패턴에 대한 건설적인 비판과 상태 수정 이전이 아닌 이후에 효과를 실행하는 동기 및 잠재적인 이점이 있기를 바랍니다.

이 접근 방식과 redux-saga의 차이점을 이해하려고 합니다. 나는 그것이 암시적으로 생성기의 상태를 숨긴다는 주장에 관심이 있습니다. 처음에는 같은 일을 하는 것처럼 보이기 때문입니다. 그러나 io.take 가 구현되는 방식에 따라 달라질 수 있다고 생각합니다. 사가가 현재 해당 yield 에서 차단된 경우에만 작업을 처리한다면 무슨 말인지 확실히 알겠습니다. 그러나 redux-saga가 io.take 가 과거 작업을 반환하도록 작업을 대기열에 넣으면 동일한 작업을 수행하는 것처럼 보입니다. 어느 쪽이든, 액션 스트림을 수신하여 트리거되는 비동기식으로 dispatch 작업을 수행할 수 있는 몇 가지 논리가 있습니다.

그래도 흥미로운 개념입니다. Redux를 상태 전환 및 효과가 트리거되는 작업 스트림으로 개념화합니다. 그것은 나에게 상태 프로세서만을 고려하는 것보다 대안적인 관점인 것 같습니다.

이벤트 소싱 모델에서 Redux 작업이 "명령"(조치를 취하기 위한 우발적 요청)인지 또는 "이벤트"(평평한 보기에 반영된 상태의 원자적 전환)인지에 따라 요약할 수 있다고 생각합니다. 어느 쪽이든 생각할 수 있을 만큼 충분히 유연한 도구가 있다고 생각합니다.

나 역시 "스마트 액션 제작자"의 현재 상태에 약간 만족하지 않지만 Redux가 더 많은 이벤트 저장소인 다른 방식으로 접근했습니다. 여기서 액션은 가능한 많은 효과 중 하나입니다. 일부 외부 "컨트롤러" 계층에 의해 트리거될 수 있습니다. 이 접근 방식을 따르는 코드를 react-redux-controller 로 인수화했지만, 이를 달성하기 위한 잠재적으로 더 가벼운 방법에 대한 반쯤 구운 아이디어가 있습니다. 그러나 현재 가지고 있지 않은 후크를 가지려면 react-redux가 필요하고 일부 상점에서는 아직 해결하지 못한 hijinks를 포장해야 합니다.

스토어 hijinks 설명 https://github.com/rackt/redux/issues/1200

이 접근 방식과 redux-saga의 차이점을 이해하려고 합니다.

나는 내 접근 방식을 생각해 낸 이후까지 redux-saga를 보지 않았지만 확실히 몇 가지 유사점이 있습니다. 그러나 나는 여전히 몇 가지 차이점이 있습니다.

1. 내 접근 방식은 작업 스트림에 대한 액세스 권한이 없고 상태에만 액세스할 수 있습니다. redux-saga는 단순히 작업이 있었기 때문에 프로세스를 시작할 수 있습니다. 내 접근 방식에서는 리듀서가 동작을 요청하기 위해 반응 기능을 트리거하는 상태를 변경해야 합니다.
2. 내 접근 방식에서는 모든 상태가 redux의 상태에 있어야 합니다. Redux-saga에는 saga 생성기에 있는 추가 상태가 있습니다(어떤 라인에 있는지, 지역 변수 값).
3. 내 접근 방식은 비동기 부분을 분리합니다. 비동기 기능을 다루지 않고도 반응의 실제 논리를 테스트할 수 있습니다. 사가는 이것들을 하나로 묶습니다.
4. 사가는 같은 논리의 서로 다른 조각을 함께 가져옵니다. 내 접근 방식은 사가를 감속기, 반응 및 반응 유형 구현에 속하는 부분으로 분할하도록 강요합니다.

기본적으로 내 접근 방식은 순수 기능을 강조하고 모든 것을 redux 상태로 유지합니다. redux-saga 접근 방식은 표현력을 강조합니다. 장점도 단점도 있지만 저는 제게 더 좋습니다. 하지만 저는 편견이 있습니다.

정말 유망하게 들립니다. 도메인 논리에서 반응 기계를 분리하는 예를 보는 것이 더 설득력이 있을 것이라고 생각합니다.

귀하의 제안은 fetchPostsIfNeeded를 제거했으며 더 많거나 더 적은 데이터가 요청되었을 때 필요에 따라 여러 요청을 최적화하거나 다른 API 세트를 사용할 수 있는 반응 기능을 구현하는 것이 완전히 실현 가능한 것 같습니다.

그대로 반응 기능에서는 실제로 그렇게 할 수 없습니다. 어떤 작업이 이미 시작되었는지 알아야 하는 논리가 있지만(더 이상 작업을 일괄 처리할 수 없음) 반응 기능에는 정보가 없습니다. 반응() 함수를 사용하는 반응 기계는 확실히 그런 일을 할 수 있습니다.

도메인 논리에서 반응 기계를 분리하는 예를 보는 것이 더 설득력이 있을 것이라고 생각합니다.

doReactions() 함수가 XMLHttpRequest의 시작/중지를 처리하는 방식을 의미한다고 가정합니까? 다양한 방법을 모색하고 있습니다. 문제는 두 반응이 실제로 동일한 반응인지 여부를 감지하는 일반적인 방법을 찾기가 어렵다는 것입니다. Lodash의 isEqual은 거의 작동하지만 클로저에는 실패합니다.

doReactions() 함수가 XMLHttpRequest의 시작/중지를 처리하는 방식을 의미한다고 가정합니까?

아니요, 제 말은 귀하의 예에서 반응의 개념을 설정하기 위한 모든 구성이 어떤 데이터를 가져오는지에 대한 도메인 논리와 해당 데이터를 가져오는 방법에 대한 세부 정보가 혼합되어 있다는 의미입니다. 일반적인 측면은 예제와 관련된 세부 사항과 덜 결합된 것으로 간주되어야 한다고 생각합니다.

아니요, 제 말은 귀하의 예에서 반응의 개념을 설정하기 위한 모든 구성이 어떤 데이터를 가져오는지에 대한 도메인 논리와 해당 데이터를 가져오는 방법에 대한 세부 정보가 혼합되어 있다는 의미입니다. 일반적인 측면은 예제와 관련된 세부 사항과 덜 결합된 것으로 간주되어야 한다고 생각합니다.

흠... 도메인 논리로 같은 의미가 아닐 수도 있다고 생각합니다.

내가 볼 때 반응() 함수는 도메인 논리를 캡슐화하고 반응이 적용되는 논리를 처리하는 doReactions() 함수와 별개입니다. 근데 뭔가 다른 뜻이신듯...

그대로 반응 기능에서는 실제로 그렇게 할 수 없습니다. 어떤 작업이 이미 시작되었는지 알아야 하는 논리가 있지만(더 이상 작업을 일괄 처리할 수 없음) 반응 기능에는 정보가 없습니다. 반응() 함수를 사용하는 반응 기계는 확실히 그런 일을 할 수 있습니다.

나는 주로 단일 이벤트가 여러 구성 요소가 동일한 정보를 요청하는 상태 변경을 트리거한 경우 이를 최적화할 수 있음을 의미했습니다. 그러나 이전 상태 변경으로 인한 부작용이 아직 보류 중인지 확인하는 것만으로는 충분하지 않으므로 추가 요청이 필요하지 않다는 것은 맞습니다.

처음에는 앱 상태 내에서 모든 상태를 유지할 수 있다고 생각했지만 최근 스톱워치 문제 에 대해 생각하기 시작했을 때 스톱워치 isOn 가 애플리케이션 상태에 저장되어야 한다는 사실을 깨달았습니다. 실제 interval 이 스톱워치와 연결된 isOn 는 앱 상태여야 하지만 이 경우 단독으로는 충분하지 않습니다.

나는 주로 단일 이벤트가 여러 구성 요소가 동일한 정보를 요청하는 상태 변경을 트리거한 경우 이를 최적화할 수 있음을 의미했습니다. 그러나 이전 상태 변경으로 인한 부작용이 아직 보류 중인지 확인하는 것만으로는 충분하지 않으므로 추가 요청이 필요하지 않다는 것은 맞습니다.

요청을 병합하거나 일괄 처리할 생각이었습니다. 중복 제거는 잘 작동합니다. 실제로 보류 중인 상태 변경의 경우도 잘 처리해야 합니다. 서버 응답이 돌아올 때까지 반응 함수에서 반환되므로 중복이 제거되기 때문입니다.

처음에는 앱 상태 내에서 모든 상태를 유지할 수 있다고 생각했지만 최근 스톱워치 문제에 대해 생각하기 시작했을 때 스톱워치 isOn이 애플리케이션 상태에 저장되어야 한다는 사실을 깨달았습니다. 이 스톱워치와 관련된 실제 간격 개체 다른 곳에 저장해야 합니다. isOn은 앱 상태여야 하지만 이 경우 단독으로는 충분하지 않습니다.

내가 생각하는 방식으로 현재 보류 중인 반응은 반응 구성 요소와 같습니다. 기술적으로 내부 상태가 있지만 현재 상태의 함수로 모델링합니다.

흠... 도메인 논리로 같은 의미가 아닐 수도 있다고 생각합니다.

내가 볼 때 반응() 함수는 도메인 논리를 캡슐화하고 반응이 적용되는 논리를 처리하는 doReactions() 함수와 별개입니다. 근데 뭔가 다른 뜻이신듯...

나는 /reactions/index 모듈 전체를 취했지만, 예, reactions 함수가 순전히 도메인 논리라는 데 동의합니다. 그러나 도메인 특정 모듈에 있는 것이 아니라 doReactions 의 상용구와 함께 래핑됩니다. 방법론을 노크하는 것이 아니라 라이브러리 코드와 앱 코드의 구분을 한 눈에 이해하기 어렵게 만듭니다.

그러면 doReactions 자체가 API에서 데이터를 가져오는 특정 행위의 특정 메서드와 다소 밀접하게 결합된 것 같습니다. 나는 살을 붙인 반응 라이브러리가 다양한 유형의 효과에 대한 처리기를 등록하는 방법일 수 있다고 가정합니다.

그것은 당신의 방법을 노크하는 것이 아닙니다. 저는 이 접근 방식이 정말 매력적이라고 ​​생각합니다.

반응 구성 요소 상태가 대부분의 반응 상태와 좋은 비유인지 잘 모르겠습니다.
앱 상태에 있어야 하지만 분명히 어떤 방식으로든
배치할 수 없는 디스패치 이벤트 사이의 상태를 유지하기 위해
가게.

나는 이런 종류의 상태가 @yelouafi 가 제어 상태
아마도 sagas는 직렬화할 수 없는 상태를 모델링하는 괜찮은 방법일 것입니다.
독립적인 관찰자/행위자로서의 시스템.

사가라면 숨겨진 사가 상태에 대해 덜 걱정할 것 같아요
사용자 대신 애플리케이션 생성 이벤트(반응)에만 응답
앱 리듀서가
현재 상태 및 모든 조건부 비즈니스 로직이
응용 프로그램은 복제 없이 원하는 부작용을 허용해야 합니다.
비즈니스 논리.
2016년 1월 4일 월요일 오후 5:56 Winston Ewert [email protected]
썼다:

나는 주로 단일 이벤트가 상태 변경을 유발하는 경우를 의미했습니다.
여러 구성 요소가 동일한 정보를 요청한 경우
최적화하십시오. 그러나 그것만으로는 충분하지 않다는 것이 옳습니다.
이전 상태 변경의 부작용이 아직 보류 중인지 확인
따라서 추가 요청이 필요하지 않습니다.

요청을 병합하거나 일괄 처리할 생각이었습니다. 중복 제거
잘 작동해야합니다. 실제로는 보류 상태의 경우를 처리해야 합니다.
변경 사항도 괜찮습니다.
서버가 응답할 때까지 반응 기능(따라서 중복 제거)
돌아오다.

처음에는 앱 내에서 모든 상태를 유지할 수 있다고 생각했습니다.
하지만 최근의 스톱워치 문제에 대해 생각하기 시작했을 때
스톱워치가 켜져 있어야한다는 사실을 깨달았습니다.
응용 프로그램은 이것과 관련된 실제 간격 개체를 나타냅니다.
스톱워치는 다른 곳에 저장해야 합니다. isOn은 앱에 있어야 합니다.
state but is is not 혼자는 이 경우에 충분하지 않습니다.

내가 생각하는 방식으로 현재 보류 중인 반응은
반응 성분. 기술적으로 내부 상태가 있지만 우리는
그것들을 현재 상태의 함수로.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/rackt/redux/issues/1182#issuecomment -168858051.

방법론을 노크하는 것이 아니라 라이브러리 코드와 앱 코드의 구분을 한 눈에 이해하기 어렵게 만듭니다.

그것은 완전히 공정합니다.

그런 다음 doReactions 자체는 API에서 데이터를 가져오는 특정 작업의 특정 메서드와 다소 밀접하게 결합된 것 같습니다. 나는 살을 붙인 반응 라이브러리가 다양한 유형의 효과에 대한 처리기를 등록하는 방법일 수 있다고 가정합니다.

예. 나는 여전히 그것을 분할하는 가장 좋은 방법을 알아 내려고 노력하고 있습니다. 평등 검사 문제로 인해 복잡합니다.

반응 구성 요소 상태가 대부분의 반응 상태와 좋은 비유인지 잘 모르겠습니다.
앱 상태에 있어야 하지만 분명히 어떤 방식으로든
배치할 수 없는 디스패치 이벤트 사이의 상태를 유지하기 위해
가게.

미안, 내가 비유를 망친 것 같아. 내 요점은 DOM의 상태만큼 컴포넌트 상태에 반응하기 위해 외부 액션 상태를 비교하는 것이 아니라는 것입니다. 간격 또는 XMLHttpRequest는 생성 및 소멸 반응을 수행하는 DOM 요소와 비슷합니다. 당신은 단순히 현재 DOM이 무엇을 해야 하는지 반응하고 그것이 일어나도록 합니다. 마찬가지로 현재 외부 반응 집합을 반환하기만 하면 프레임워크가 취소하거나 작업을 시작하여 사실로 만듭니다.

나는 그 접근 방식도 매우 흥미롭다고 생각합니다. 다른 상태 매핑을 사용하는 여러 doReactions 사용하는 것을 고려해 보셨습니까? 재사용 가능한 드라이버를 빌드할 수 있는 cyclejs와 비슷할 것이라고 생각합니다.

function main(action$) {
  const state$ = action$.startWith(INITIAL_STATE).scan(reducer);

  return { 
    DOM: state$.map(describeDOM),
    HTTP: state$.map(describeRequests),
    ...
  };
}

한 가지 차이점은 작업 스트림( const someEvent$ = sources.DOM.select('.class').events('click') )을 가져오기 위해 드라이버에 이벤트를 쿼리하지 않고 HTTP 요청에 대해 수행한 것처럼 싱크에서 직접 작업( <button onClick={() => dispatch(action())} /> )을 지정한다는 것입니다. 또한.

나는 React 비유가 꽤 잘 작동한다고 생각합니다. DOM을 내부 상태로 간주하지 않고 API와 함께 작동하는 반면 내부 상태는 구성 요소 인스턴스와 가상 DOM으로 구성됩니다.

다음은 API에 대한 아이디어입니다(React 사용, HTTP도 이와 같이 빌드할 수 있음).

// usage
const describe = (state, dispatch) => <MyComponent state={state} dispatch={dispatch} />;
const driver = createReactDOMDriver({ container } /* opts */);
store.subscribe(() => driver.update(describe(store.getState(), store.dispatch)); 
// (could be simplified further to eg. `store.use(driver, describe)` )

// implementation
const createReactDOMDriver = ({ container }) => {
  return {
    update: (element) => ReactDOM.render(element, container),
    destroy: () => ReactDOM.unmountComponentAtNode(container),
  };
};

describe 가 getState (상태 스냅샷 대신) 및 dispatch 합니다. 그렇게 하면 원하는 만큼 동기화될 수 있습니다.

다른 상태 매핑을 사용하는 여러 doReactions를 사용하는 것을 고려해 보셨습니까?

나는 그것에 대해 간단히 생각했고, 지금은 그것에 대해 약간 앞뒤로 가고 있습니다. DOM을 위한 것, http를 위한 것, 타이머를 위한 것, 웹 오디오를 위한 것 등 다른 일을 하는 다른 반응 라이브러리를 갖는 것이 자연스럽습니다. 각각은 자신의 경우에 적합한 최적화/동작을 수행할 수 있습니다. 그러나 일회성 외부 작업을 많이 수행하는 앱이 있는 경우에는 덜 도움이 되는 것 같습니다.

설명이 getState(상태 스냅샷 대신)를 가져오고 디스패치하도록 합니다. 그렇게 하면 원하는 만큼 동기화될 수 있습니다.

나는하지 않을 것이다. 제 생각에는 가능한 경우 비동기를 제한하고 추가 사용 방법을 제공하지 않으려고 합니다. getState()를 호출하려는 모든 것은 감속기 또는 반응 함수에서 수행해야 합니다. (그러나 그것은 나의 순수한 사고 방식이며, 아마도 그것을 따르지 않는 실용적인 경우가 있습니다.)

공정한 지적입니다. 나는 당신의 아이디어와 @taurose 의 예 사이의 매핑에 대해 충분히 생각하지 않았습니다. 성급하게 describe 가 reactions 함수라고 가정했지만 사실이 아닐 수도 있습니다.

하지만 네, 저는 비동기를 제한하는 것이 이상적이라는 데 동의합니다. 왜냐하면 제가 당신의 아이디어의 취지를 이해한다면, 우리는 연속성이 순수하고 의도를 설명하는 배열 구성원의 존재와 같은 상태의 특정 측면과 1:1 매핑되기를 원하기 때문입니다. 주어진 효과가 진행 중입니다. 그렇게하면 여러 번 실행되는 경우 실제로 중요하지 않으며 다른 프로세스가 암시적으로 의존할 수 있는 흐름 중간 어딘가에서 중단되는 프로세스의 숨겨진 측면이 없습니다.

설명이 getState(상태 스냅샷 대신)를 가져오고 디스패치하도록 합니다. 그렇게 하면 원하는 만큼 동기화될 수 있습니다.

describe 는 상태가 변경될 때마다 호출되므로 필요하지 않습니다. 비동기를 할 수 없다는 의미는 아닙니다. 반응 구성 요소를 고려하십시오. 현재 상태를 가져오기 위해 렌더링 메서드 또는 이벤트 핸들러 내부에서 getState 호출하지 않고 소품에서 읽습니다.

그러나 자체적으로 비동기식으로 아무것도 할 수 없다는 점에서 당신이 옳습니다. 그것을 드라이버에 맡기고 매핑된 상태 및/또는 콜백을 전달해야 합니다.

설명이 반응 함수라고 가정했지만 사실이 아닐 수도 있습니다.

내가 말할 수 있는 한, 그것은 거의 동일합니다. 한 가지 차이점은 reactions 가 dispatch 받지 않는다는 것입니다. 따라서 describe 는 작업을 생성하고 전달하는 콜백을 반환하는 반면 reactions 는 작업 생성자를 반환합니다.

@winstonewert 그것은 긴 스레드이며 지금 당장 읽거나 코드를 확인할 시간이 없지만 @yelouafi 가 답변할 수 있습니다.

redux-saga 프로젝트는 여기 에서 긴 토론 .

나는 또한 프로덕션 앱에서 1년 넘게 saga 개념을 사용하고 있으며 구현은 덜 표현적이지만 제너레이터를 기반으로 하지 않습니다. 다음은 redux에 대한 개념에 대한 몇 가지 유사 예입니다.

• http://stackoverflow.com/a/33829400/82609
• http://stackoverflow.com/a/33501899/82609

여기서 구현은 완벽하지 않지만 아이디어를 제공합니다.

@yelouafi 는 redux 외부에서 상태를 숨기는 생성기 사용에 내재된 문제 와 백엔드에서 무용담을 시작하고 유니버설 앱의 프론트엔드에 숨겨진 상태를 전송하는 것이 복잡하다는 점을 알고 있습니다(정말 필요한 경우?)

redux-saga는 Free가 IO 모나드에 대한 것처럼 redux-thunk에 대한 것입니다. 효과는 선언적이며 지금은 실행되지 않으며 내부 검사가 가능하고 인터프리터에서 실행됩니다(나중에 사용자 정의할 수 있음).

제너레이터 내부의 숨겨진 상태에 대한 귀하의 요점을 이해합니다. 그러나 실제로 Redux 스토어가 Redux 앱의 진정한 소스 입니까? 나는 그렇게 생각하지 않는다. Redux는 작업을 기록하고 재생합니다. 항상 이러한 작업을 재생하여 상점을 다시 만들 수 있습니다. redux 저장소는 이벤트 로그의 CQRS 쿼리 보기와 같습니다. 해당 이벤트 로그의 유일한 투영이어야 함을 의미하지는 않습니다. 다른 쿼리 보기에서 동일한 이벤트 로그를 투영하고 기술에 상관없이 생성기, 전역 변경 가능 개체 또는 감속기로 상태를 관리할 수 있는 무용담에서 이를 수신할 수 있습니다.

리듀서로 사가 컨셉을 만드는 것은 개념적으로 나쁜 생각이 아니며 트레이드 오브 결정이라는 데 동의합니다.
개인적으로 프로덕션에서 1년 이상 saga를 사용한 후에 saga의 상태를 스냅샷하고 나중에 복원할 수 있는 것이 유용했을 사용 사례가 기억나지 않기 때문에 이것을 잃어도 제너레이터의 표현력을 선호합니다. 특징.

내가 말하는 것이 redux-saga에 대한 공격으로 들리지 않기를 바랍니다. 나는 그것이 내가 생각해낸 접근 방식과 어떻게 다른지에 대해 이야기했을 뿐입니다.

제너레이터 내부의 숨겨진 상태에 대한 귀하의 요점을 이해합니다. 그러나 실제로 Redux 스토어가 Redux 앱의 진정한 소스입니까? 나는 그렇게 생각하지 않는다. Redux는 작업을 기록하고 재생합니다. 항상 이러한 작업을 재생하여 상점을 다시 만들 수 있습니다. redux 저장소는 이벤트 로그의 CQRS 쿼리 보기와 같습니다. 해당 이벤트 로그의 유일한 투영이어야 함을 의미하지는 않습니다. 다른 쿼리 보기에서 동일한 이벤트 로그를 투영하고 기술에 상관없이 생성기, 전역 변경 가능 개체 또는 감속기로 상태를 관리할 수 있는 무용담에서 이를 수신할 수 있습니다.

나는 당신의 요점을 여기에서 정말로 이해하지 못합니다. 사가가 이벤트 로그의 투영이라고 주장하는 것 같습니까? 하지만 그렇지 않습니다. 액션을 재생하면 무용담이 비동기식 이벤트에 의존하는 경우 무용담에서 같은 위치에 도달하지 않습니다. sagas가 redux의 상태 저장소나 이벤트 로그의 프로젝션에 없는 상태를 생성하는 것은 피할 수 없는 것 같습니다.

내가 말할 수 있는 한, 그것은 거의 동일합니다. 한 가지 차이점은 반응이 디스패치되지 않는다는 것입니다. 따라서 설명은 작업을 생성하고 전달하는 콜백을 반환하지만 반응은 작업 생성자를 반환합니다.

동의. 원칙적으로 반응은 동일한 인터페이스를 사용할 수 있으며 모든 이벤트 핸들러는 이벤트가 시작될 때 전달되는 작업 생성기를 사용합니다.

생각하면 할수록 이 접근 방식과 무용담 사이에 많은 시너지 효과가 있을 수 있다고 생각합니다. @winstonewert가 설명한 4가지 요점에 전적으로 동의합니다. 반응이 사용자가 시작한 작업을 볼 수 없는 것은 좋은 일이라고 생각합니다. 이렇게 하면 숨겨진 상태가 방지되고 리듀서의 비즈니스 논리가 작업 작성자 또는 사가에서 복제될 필요가 없기 때문입니다. 그러나 부작용이 종종 반응 저장소, 간격, dom 개체, http 요청 등에 저장할 수 없는 직렬화 불가능한 상태를 생성한다는 것을 깨달았습니다. sagas, rxjs, baconjs 등은 이 외부 직렬화 불가능한 제어 상태에 완벽합니다.

doReactions는 사가로 대체될 수 있으며 사가의 이벤트 소스는 액션이 ​​아닌 반응이어야 합니다.

내가 말하는 것이 redux-saga에 대한 공격으로 들리지 않기를 바랍니다.

별말씀을 요. 나는 토론을 따르고 있지만 코드를 더 자세히 살펴보지 않고 댓글을 달고 싶지 않았습니다.

언뜻보기에. 상태 변경에만 반응하는 것 같습니다. 내가 말했듯이 그것은 빠른 모습이었다. 그러나 복잡한 흐름을 구현하는 것이 느릅나무 접근 방식(상태와 작업을 모두 수행하는 경우)보다 훨씬 더 어렵게 만들 것 같습니다. 이는 더 많은 제어 상태를 스토어에 저장해야 함을 의미합니다(앱 상태 변경만으로는 관련 반응을 추론하기에 불충분함).

물론 순수한 기능을 능가하는 것은 없습니다. 리듀서는 상태 전환을 표현하는 데 훌륭하지만 상태 머신으로 전환하면 정말 이상해집니다.

이는 더 많은 제어 상태를 스토어에 저장해야 함을 의미합니다(앱 상태 변경만으로는 관련 반응을 추론하기에 불충분함).

네. 이것이 이 접근 방식의 주요 차별화 측면인 것 같습니다. 그러나 실제로 다른 효과 유형을 다른 "드라이버"로 묶을 수 있다면 이 문제를 투명하게 만들 수 있는지 궁금합니다. 나는 사람들이 원하는 드라이버를 선택하거나 새로운 효과를 위해 직접 작성하는 것이 매우 쉽다고 상상하고 있습니다.

그러나 부작용이 종종 반응 저장소, 간격, dom 개체, http 요청 등에 저장할 수 없는 직렬화 불가능한 상태를 생성한다는 것을 깨달았습니다. sagas, rxjs, baconjs 등은 이 외부 직렬화 불가능한 제어 상태에 완벽합니다.

나는 당신이 아직 무엇인지 볼 수 없습니다.

리듀서는 상태 전환을 표현하는 데 훌륭하지만 상태 머신으로 전환하면 정말 이상해집니다.

나는 동의한다. 복잡한 상태 기계를 손으로 작성하는 경우 문제가 있습니다. (사실 우리가 발전기를 감속기로 바꿀 수 있다면 그것은 깔끔할 것입니다.)

그러나 실제로 다른 효과 유형을 다른 "드라이버"로 묶을 수 있다면 이 문제를 투명하게 만들 수 있는지 궁금합니다. 나는 사람들이 원하는 드라이버를 선택하거나 새로운 효과를 위해 직접 작성하는 것이 매우 쉽다고 상상하고 있습니다.

여기서 무슨 생각을 하고 있는지 잘 모르겠습니다. 다른 드라이버가 다른 유용한 작업을 수행하지만 제어 상태를 제거하는 것을 볼 수 있습니까?

@winstonewert 아니요, 공격으로

나는 당신의 요점을 여기에서 정말로 이해하지 못합니다. 사가가 이벤트 로그의 투영이라고 주장하는 것 같습니까? 하지만 그렇지 않습니다. 액션을 재생하면 무용담이 비동기식 이벤트에 의존하는 경우 무용담에서 같은 위치에 도달하지 않습니다. sagas가 redux의 상태 저장소나 이벤트 로그의 프로젝션에 없는 상태를 생성하는 것은 피할 수 없는 것 같습니다.

아니요. redux 스토어는 프로젝션이지만 saga는 평범하고 오래된 단순한 청취자입니다.

saga(프로세스 관리자라고도 함) 는 새로운 개념이 아니며 CQRS 세계에서 시작되었으며 과거에 백엔드 시스템에서 널리 사용되었습니다.

saga는 이벤트 로그를 데이터 구조에 투영하는 것이 아니라 시스템에서 일어나는 일을 듣고 반응을 생성할 수 있는 오케스트레이션의 일부이며 나머지는 구현 세부 사항입니다. 일반적으로 saga는 이벤트 로그(및 시간과 같은 다른 외부 항목)를 수신하고 새로운 명령/이벤트를 생성할 수 있습니다. 또한 백엔드 시스템에서 이벤트를 재생할 때 일반적으로 sagas에 의해 트리거된 부작용 비활성화를 비활성화합니다.

차이점은 백엔드 시스템에서 saga는 종종 실제로 이벤트 로그의 투영입니다. 상태를 변경하려면 이벤트를 내보내고 자체적으로 수신해야 합니다. 현재 구현되어 있는 redux-saga에서는 saga 상태를 복원하기 위해 이벤트 로그를 재생하는 것이 더 어려울 것입니다.

여기서 무슨 생각을 하고 있는지 잘 모르겠습니다. 다른 드라이버가 다른 유용한 작업을 수행하지만 제어 상태를 제거하는 것을 볼 수 있습니까?

아니, 그것을 제거하는 것이 아니라 대부분의 목적을 위해 내부 구현 문제로 만드는 것입니다.

스토어에 도메인 상태를 저장하는 것이 큰 승리라는 Redux 커뮤니티의 강력한 합의가 있는 것 같습니다(그렇지 않으면 Redux를 사용하는 이유가 무엇입니까?). UI 상태를 구성 요소에 캡슐화하는 것과는 대조적으로 UI 상태를 저장하는 것이 유리하다는 합의는 다소 적습니다. 그런 다음 URL(redux-simple-router) 또는 양식 데이터와 같은 저장소의 브라우저 상태를 동기화하는 아이디어가 있습니다. 하지만 이것은 스토어에 장기 실행 프로세스의 상태/단계를 저장하는 마지막 프론티어인 것 같습니다.

이것이 접선이라면 유감이지만 개발자 사용성이 좋은 매우 일반적인 접근 방식에는 다음 기능이 있어야 한다고 생각합니다.

• 일반 사용자가 상점에서 효과가 표현되는 모양에 대해 신경 쓰지 않아도 되도록 만드십시오. 이러한 세부 정보를 추상화하는 간단한 API와 상호 작용해야 합니다.
• 효과를 쉽게 구성할 수 있도록 합니다. 흐름 제어 및 다른 효과에 따라 달라지는 효과와 같은 작업을 수행하는 것이 자연스럽게 느껴져야 합니다. 물론 이것은 생성기 추상화가 실제로 빛나는 곳입니다. 대부분의 제어 흐름에서 잘 작동하며 클로저는 주목할만한 예외입니다. 그러나 redux-saga 또는 react-redux-controller에서 얼마나 복잡한 비동기 흐름을 표현할 수 있는지 쉽게 알 수 있습니다.
• 원하는 경우 효과 상태가 다른 매장 소비자에게 쉽게 노출될 수 있도록 합니다. 이를 통해 사용자에게 다중 효과 프로세스의 상태를 표시하는 것과 같은 작업을 수행할 수 있습니다.
• 이것은 분명하지만 상태를 캡슐화하는 모든 하위 시스템은 작업을 전달하여 해당 상태를 Redux와 동기화합니다.

그 두 번째 요점에 대해서는 redux-saga와 꽤 유사한 것이 있어야 한다고 생각합니다. call 래퍼로 내가 생각한 것과 거의 비슷할 수 있습니다. 그러나 무용담은 어떤 의미에서 중간 상태로 역직렬화할 수 있도록 "빨리 감기"가 가능해야 합니다.

이것은 모든 종류의 어려운 주문이지만 실제로는 직렬화 가능한 하나의 중앙 작업 레코드를 갖고 전체 앱의 상태를 매우 세부적인 수준에서 추적함으로써 큰 ​​승리를 거둘 수 있다고 생각합니다. 활용하는 방법입니다. 그리고 실제로 큰 승리가 있을 수 있다고 생각합니다. 사용자 및 성능 분석으로 앱을 계측하는 훨씬 간단한 방법을 상상하고 있습니다. 다른 하위 시스템이 상태를 통해서만 결합되는 정말 놀라운 테스트 가능성을 상상하고 있습니다.

지금은 길을 벗어 났을 수 있으므로 그대로 두겠습니다. :)

@acjay 나는 우리가 이러한 점에 대해 당신과 동의한다고 생각합니다. 문제는 이 모든 것을 올바르게 해결하는 이 구현을 찾는 것입니다 :)

하지만 제너레이터가 있는 표현형 API와 시간 여행 및 상태 스냅샷/복원 가능성이 있는 것 모두 어려운 것 같습니다... 제너레이터 상태를 쉽게 복원할 수 있도록 효과의 실행을 메모하는 것이 가능할 수도 있습니다...

확실하지 않지만 이것은 while(true) { ... } 스타일의 무용담을 배제할 수 있습니다. 루프는 상태 진행의 결과일 뿐입니까?

@acjay @slorber

내가 (https://github.com/yelouafi/redux-saga/issues/22#issuecomment-168872101)에서 설명했듯이 sagas에서는 혼자 (즉, 핫 리로드 없이) 시간 여행이 가능합니다. 사가를 특정 지점으로 가져오기 위해 필요한 것은 시작부터 해당 지점까지의 일련의 효과와 결과(해결 또는 거부)뿐입니다. 그런 다음 해당 시퀀스로 발전기를 구동합니다.

실제 마스터 브랜치에서(아직 npm에 출시되지 않음). Sagas는 모니터링을 지원하며 모든 산출 효과와 결과를 상점에 전달합니다. 또한 제어 흐름 그래프를 추적하기 위한 계층 정보를 제공합니다.

그 효과 로그는 주어진 시점까지 Saga를 재생하기 위해 악용될 수 있습니다. 로그에 이미 과거 응답이 포함되어 있으므로 실제 API 호출을 할 필요가 없습니다.

repo 예제 에는 saga 모니터 의 {type: 'LOG_EFFECT'} 을 상점에 전달하여 흐름의 추적을 인쇄할 수 있습니다.

다음은 비동기 예제의 효과 로그 캡처입니다.

편집: 죄송합니다 고정 이미지 링크

흥미롭다! 그리고 그 개발 도구 이미지는 _awesome_입니다.

멋지네요 :)

사실, 그 사가 모니터는 꽤 멋지다.

생각해보면 사가는 두 가지 문제를 해결하고 있는 것 같습니다. 첫째, 비동기 효과를 처리합니다. 둘째, 그렇지 않으면 리듀서에서 손으로 쓴 불쾌한 상태 머신이 필요했을 복잡한 상태 상호 작용을 처리합니다.

내 접근 방식은 첫 번째 문제만 다룹니다. 두 번째 문제에 대한 필요성을 찾지 못했습니다. 아마도 나는 아직 실행하기에 충분한 redux 코드를 작성하지 않았을 것입니다.

예, 하지만 두 가지 아이디어를 융합할 수 있는 방법이 있는지 궁금합니다. redux-saga의 call 래퍼는 효과에 대한 매우 간단한 수준의 간접 참조이지만 다양한 유형의 효과에 대한 드라이버로 미들웨어를 초기화할 수 있다고 가정하면 해당 효과를 함수에서 분리된 JSONable 데이터로 나타낼 수 있습니다. 실제로 호출되는 것입니다. 드라이버는 기본 상태 변경 사항을 저장소로 전달하는 세부 사항을 처리합니다.

실제적인 이점은 거의 없지만 복잡성이 많이 추가될 수 있습니다. 그러나 이 생각의 선을 끝까지 따르려고 합니다.

좋아, 나는 더 많은 라이브러리를 만들고 그것을 사용하기 위해 실제 예제를 이식했다.

첫째, 반응 구현이 있습니다.
https://github.com/winstonewert/redux-reactions/blob/master/src/index.js
인터페이스는 세 가지 기능입니다. startReactions는 저장소, 반응 기능 및 이름에서 드라이버로의 매핑을 취합니다. fromEmitter와 fromPromiseFactory는 모두 드라이버를 생성합니다.

여기에서 예제는 시스템을 활성화하기 위해 startReactions를 호출합니다:
https://github.com/winstonewert/redux-reactions/blob/master/examples/real-world/store/configureStore.dev.js#L28

반응의 기본 구성은 다음과 같습니다.
https://github.com/winstonewert/redux-reactions/blob/master/examples/real-world/reactions/index.js.
반응 함수는 실제로 해당 페이지에 대해 실제로 필요한 반응을 파악하기 위해 반응() 함수가 있는 구성 요소를 찾는 반응 라우터 인스턴스화 구성 요소를 반복합니다.

github api 반응 유형의 구현은 https://github.com/winstonewert/redux-reactions/blob/master/examples/real-world/reactions/api.js입니다. 이것은 대부분 원본 예제에서 사용된 미들웨어에서 복사/붙여넣기입니다. 중요한 점은 https://github.com/winstonewert/redux-reactions/blob/master/examples/real-world/reactions/api.js#L79 입니다 . 여기서 fromPromiseFactory를 사용하여 다음을 수행하는 함수에서 드라이버를 생성합니다. 약속을 반환합니다.

구성 요소별 반응 기능은 https://github.com/winstonewert/redux-reactions/blob/master/examples/real-world/containers/RepoPage.js#L80에서 확인하세요.

반응 생성자와 공통 논리는 https://github.com/winstonewert/redux-reactions/blob/master/examples/real-world/reactions/data.js 에

안녕하세요 여러분! Raise는 Elm 아키텍처와 유사한 효과 시스템도 사용할 수 있는 스토어 인핸서를 출시했습니다! 앞으로 커뮤니티의 모든 요구 사항을 충족하기 위해 이러한 모든 접근 방식을 배우고 개선할 수 있기를 바랍니다.

https://github.com/raisemarketplace/redux-loop

토론에 관심이 있는 사람은 여기에서 내 아이디어에 대한 추가 토론을 볼 수 있습니다. https://github.com/winstonewert/redux-reactions/issues/7

여기에서 내 패턴을 사용하여 더 elmish가 되도록 카운터 앱을 재작업한 분기를 볼 수도 있습니다.
https://github.com/winstonewert/redux-reactions/tree/elmish/examples/counter

나는 또한 여기에서 사용된 접근 방식을 재발명하고 있다는 것을 발견했습니다: https://github.com/ccorcos/elmish

@yelouafi , 사가 모니터 아이디어에 대한 링크를 다시 게시할 수 있습니까? 정말 좋은 물건입니다! 링크가 죽은 것 같습니다(404). 더 보고 싶어요!

https://github.com/yelouafi/redux-saga/blob/master/examples/sagaMonitor/index.js

관련 새로운 토론: https://github.com/reactjs/redux/issues/1528

(관련된 것 같아요. 잘못된 곳이라면 죄송합니다.)

모든 효과를 DOM 렌더링과 동일하게 취급할 수 있습니까?

1. jQuery 는 명령형 인터페이스가 있는 DOM 드라이버입니다. React는 선언적 인터페이스가 있는 DOM 드라이버입니다. 따라서 "그 버튼을 비활성화하십시오"라고 명령하는 대신 "저 버튼을 비활성화해야 합니다"라고 선언하고 드라이버가 수행할 DOM 조작을 결정합니다. " GET \product\123 "를 주문하는 대신 "우리는 해당 데이터가 필요합니다"라고 선언하고 드라이버는 보내거나 취소할 요청을 결정합니다.
2. DOM 드라이버에 대한 API로 React 구성 요소를 사용합니다. 다른 드라이버와도 인터페이스하는 데 사용합시다.
   
   
   
   • <button ...> - "일반" React 구성 요소에서 View 레이어를 빌드합니다.
   
   
   • <Map ...> - "래퍼" 구성 요소를 사용하여 일부 라이브러리의 명령형 인터페이스를 선언적 인터페이스로 전환합니다. "일반" 구성 요소와 동일한 방식으로 사용하지만 내부적으로는 실제로 드라이버입니다.
   
   
   • <Chart ...> - 구현에 따라 위 중 하나일 수 있습니다. 따라서 "일반" 구성 요소와 드라이버 간의 경계는 이미 모호합니다.
   
   
   • <Http url={'/product/'+props.selectedProductId} onSuccess={props.PRODUCT_LOADED} /> (또는 "스마트" <Service...> ) - (UI가 없는) 드라이버 구성 요소에서 서비스 계층을 구축합니다.
   
   

보기 및 서비스 계층은 모두 React 구성 요소를 통해 설명됩니다. 그리고 우리의 최상위(연결된) 구성 요소는 그것들을 서로 붙입니다.
이렇게 하면 리듀서가 순수하게 유지되고 효과를 처리하는 새로운 수단을 도입하지 않습니다.

new Date 또는 Math.random 가 여기에 맞는지 잘 모르겠습니다.

명령형 API를 선언적 API로 변환하는 것이 항상 가능합니까?
이것이 실행 가능한 견해라고 생각하십니까?

감사 해요

비동기 작업을 위한 saga 및 기타 멋진 도구가 있다는 점을 감안할 때 지금 안전하게 종료할 수 있다고 생각합니다. #1528에서 몇 가지 흥미로운 새로운 방향을 확인하세요(비동기 뿐만 아니라).