플럭스 스토어 또는 액션(또는 둘 다)이 외부 서비스에 접촉해야 합니까?
스토어가 자체 상태를 유지하고 네트워크 및 데이터 스토리지 서비스를 호출할 수 있는 기능이 있는 경우... 이 경우 작업은 단순한 메시지 전달자에 불과합니다.
-아니면...
...스토어는 액션의 불변 데이터의 바보 같은 수신자여야 합니다(액션은 외부 소스 간에 데이터를 가져오거나 전송하는 것이어야 합니다).이 인스턴스의 스토어는 뷰 모델 역할을 하며 액션에 의해 공급된 불변 데이터에 대해 자체 상태 기반을 설정하기 전에 데이터를 집약/필터링할 수 있습니다.
내가 보기엔 둘 중 하나여야 할 것 같다.그렇다면 왜 한쪽이 다른 쪽보다 선호/권장되는가?
플럭스 패턴은 양쪽 모두 구현되어 있는 것을 보았습니다만, (처음에는 전자의 어프로치를 채용하고 있는) 스토어는 액션의 데이터를 바보 같은 수신자가 되어, 기입의 비동기 처리는 액션 크리에이터에 존재해야 한다고 생각합니다.(비동기 읽기는 다른 방법으로 처리할 수 있습니다.)제 경험상, 이것은 중요한 순서대로 몇 가지 이점이 있습니다.
스토어가 완전히 동기화됩니다.이렇게 하면 스토어 로직을 훨씬 쉽게 따르고 테스트할 수 있습니다. 지정된 상태의 스토어를 인스턴스화하고 액션을 전송하여 상태가 예상대로 변경되었는지 확인합니다.또한 플럭스의 핵심 개념 중 하나는 캐스케이드 디스패치를 방지하고 동시에 여러 디스패치를 방지하는 것입니다.매장이 비동기 처리를 할 경우 이는 매우 어렵습니다.
모든 액션 디스패치는 액션 크리에이터에서 이루어집니다.스토어에서 비동기 작업을 처리하고 스토어의 액션 핸들러를 동기 상태로 유지하려면(또한 플럭스 싱글 디스패치 보증을 받기 위해서는), 스토어는 비동기 처리에 대응하여 추가 SUCCESS 액션과 FAIL 액션을 실행해야 합니다.이러한 디스패치를 Action Creators에 넣으면 Action Creators와 Store의 업무를 분리할 수 있습니다.게다가, 어디에서 액션이 디스패치 되고 있는지를 알기 위해서, 스토어의 로직을 조사할 필요는 없습니다.이 경우 일반적인 비동기 액션은 다음과 같습니다(의 구문 변경).
dispatch「 」 、 「 」 、 「 」:someActionCreator: function(userId) { // Dispatch an action now so that stores that want // to optimistically update their state can do so. dispatch("SOME_ACTION", {userId: userId}); // This example uses promises, but you can use Node-style // callbacks or whatever you want for error handling. SomeDataAccessLayer.doSomething(userId) .then(function(newData) { // Stores that optimistically updated may not do anything // with a "SUCCESS" action, but you might e.g. stop showing // a loading indicator, etc. dispatch("SOME_ACTION_SUCCESS", {userId: userId, newData: newData}); }, function(error) { // Stores can roll back by watching for the error case. dispatch("SOME_ACTION_FAIL", {userId: userId, error: error}); }); }여러 될 수 있는 예에서는 이은 " " " "가 됩니다.이 예에서는 이 모듈은
SomeDataAccessLayer아약스액션 크리에이터가 적습니다.이건 별것 아니지만, 가져도 좋아요.#2에서 설명한 바와 같이 스토어에 동기 액션 디스패치 처리가 있는 경우(또한 동기 액션 디스패치 처리가 필요한 경우) 비동기 조작의 결과를 처리하기 위해 추가 액션을 실행해야 합니다.Action Creator에서 디스패치를 실행한다는 것은 하나의 Action Creator가 비동기 데이터 액세스 자체의 결과를 처리함으로써 세 가지 액션 유형을 모두 디스패치할 수 있다는 것을 의미합니다.
Facebook의 개발자에게 이 질문을 트윗했는데, Bill Fisher로부터 들은 대답은 다음과 같다.
사용자의 UI와의 상호작용에 응답할 때 액션 크리에이터 메서드로 비동기 호출을 합니다.
하지만 티커나 다른 비인간적인 운전자를 가지고 있을 때는 가게에서 걸려오는 전화가 더 잘 통합니다.
중요한 것은 오류/성공 콜백에서 액션을 생성하여 데이터가 항상 액션과 함께 발생하도록 하는 것입니다.
저장소는 데이터를 가져오고 구성 요소에 저장소의 데이터가 업데이트되었음을 알리는 등 모든 작업을 수행해야 합니다. 왜일까요?중요한 동작에 영향을 주지 않고 가볍고, 일회용이며, 교환이 가능하기 때문입니다.모든 중요한 동작과 기능은 매장에서 이루어집니다.또한 매우 유사하지만 서로 다른 두 가지 액션으로 복사되는 동작의 중복을 방지합니다.상점은 진실의 유일한 원천이다.
지금까지 본 모든 플럭스 구현에서 액션은 기본적으로 오브젝트로 변환되는 이벤트 문자열입니다.기존에는 "anchor:clicked"라는 이름의 이벤트가 있었지만 플럭스에서는 AnchorActions로 정의됩니다.클릭.게다가 대부분의 실장에서는 이벤트를 수신하고 있는 스토어에 실제로 디스패치하기 위한 개별 디스패처 오브젝트가 있습니다.
개인적으로 저는 개별 디스패처 오브젝트가 없고 Action 오브젝트가 디스패치를 직접 하는 Reflux의 플럭스 구현을 좋아합니다.
편집: Facebook의 Flux는 실제로 "액션 크리에이터"를 불러오기 때문에 스마트 액션을 사용합니다.또한 다음 스토어를 사용하여 payload를 준비합니다.
https://github.com/facebook/flux/blob/19a24975462234ddc583ad740354e115c20b881d/examples/flux-chat/js/actions/ChatMessageActionCreators.js#L27 (27 및 28행)
완료 시 콜백은 취득된 데이터를 payload로 하여 새로운 액션을 트리거합니다.
그래서 그게 더 나은 해결책인 것 같아요.
'멍청한' 행동에 찬성하는 논거를 제시하겠습니다.
수행에 보기 데이터 수집 책임을 부여하면 수행과 보기의 데이터 요구 사항을 결합할 수 있습니다.
반면 사용자의 의도 또는 응용 프로그램의 일부 상태 천이를 선언적으로 설명하는 일반 액션에서는 해당 액션에 응답하는 모든 스토어가 의도를 구독된 보기에 맞게 맞춤화된 상태로 변환할 수 있습니다.
이것은 더 많은 수의, 그러나 더 작고 전문화된 상점들에 적합하다.내가 이 스타일을 주장하는 이유는
- 이를 통해 보기가 데이터를 소비하는 방법에 대한 유연성을 높일 수 있습니다.
- 소비하는 뷰에 특화된 "스마트" 스토어는 많은 뷰가 잠재적으로 의존하는 "스마트" 액션보다 더 작고 복잡한 앱에 대한 결합이 적을 것입니다.
스토어의 목적은 뷰에 데이터를 제공하는 것입니다."Action"이라는 이름은 응용 프로그램의 변경 사항을 설명하는 데 목적이 있음을 시사합니다.
기존 대시보드 보기에 위젯을 추가해야 한다고 가정합니다. 이 보기에는 방금 백엔드 팀이 롤아웃한 몇 가지 새로운 집약 데이터가 표시됩니다.
"smart" Actions를 사용하면 새 API를 사용하기 위해 "새로 고침" 작업을 변경해야 할 수 있습니다.그러나 추상적인 의미에서 "대시보드 새로 고침"은 변경되지 않았습니다.뷰의 데이터 요구 사항은 변경된 사항입니다.
"덤" 작업을 사용하면 새 위젯이 사용할 새 저장소를 추가하고 "새로 고침" 작업 유형을 수신하면 새 데이터에 대한 요청을 보내고 준비가 되면 새 위젯에 표시하도록 설정할 수 있습니다.뷰 레이어에 더 많은 데이터 또는 다른 데이터가 필요할 때 변경하는 것은 해당 데이터의 소스(스토어)입니다.
개론의 플럭스-크롬-크롬-크롬-크롬-크롬-크롬-크롬은 '올바른' 접근법의 훌륭한 효용 변형을 가지고 있다.
Action Creator는 외부 API 서비스에서 약속을 생성하고 약속과 3개의 액션 상수를 다음 주소로 전달합니다.dispatchAsync프록시/확장 디스패처로 기능합니다. dispatchAsync는 항상 첫 번째 액션을 디스패치합니다(예: 'GET_EXTERNAL_DA').TA'와 약속이 반환되면 'GET_EXTERNAL_DA' 중 하나를 디스패치합니다.TA_SUCCESS' 또는 'GET_EXTERNAL_DATA_ERROR'입니다.
Bret Victor의 유명한 '원칙에 관한 발명' 비디오와 같은 개발 환경을 만들고 싶다면, 차라리 데이터 구조 내의 행동/이벤트의 투영에 불과한 바보 같은 스토어를 부작용 없이 사용해야 합니다.또, Redux와 같이, 실제로 글로벌 불변의 데이터 구조의 멤버인 경우에도 도움이 됩니다.
자세한 내용은 이쪽:https://stackoverflow.com/a/31388262/82609
언급URL : https://stackoverflow.com/questions/25630611/should-flux-stores-or-actions-or-both-touch-external-services
'programing' 카테고리의 다른 글
| 확인 이메일에 고객 이름 가져오기 (0) | 2023.03.13 |
|---|---|
| eslint를 typescript와 함께 사용 - 모듈 경로를 확인할 수 없습니다. (0) | 2023.03.13 |
| 표준 웹 기술로 앵귤러 대체 (0) | 2023.03.13 |
| React-router TypeError: _this.props.이력이 정의되지 않았습니다. (0) | 2023.03.13 |
| Node.js 코드에서 MongoDB 연결을 닫지 않는 것이 권장되는 이유는 무엇입니까? (0) | 2023.03.13 |