Redux: 질문 : Redux의 저장소와 React의 상태 중에서 선택하는 방법은 무엇입니까?

전역 적으로 앱에 중요하지 않고 복잡한 방식으로 변경되지 않는 임시 상태에 React를 사용합니다. 예를 들어, 일부 UI 요소의 토글, 양식 입력 상태. 전역 적으로 중요하거나 복잡한 방식으로 변형 된 상태에 Redux를 사용합니다. 예를 들어 캐시 된 사용자 또는 게시물 초안이 있습니다.

때로는 Redux 상태에서 React 상태 (Redux에 무언가를 저장하는 것이 어색 해짐)로 이동하거나 다른 방법 (더 많은 구성 요소가 로컬이었던 상태에 액세스해야하는 경우)을 원할 것입니다.

경험의 법칙은 덜 어색한 일을하는 것입니다.

네트워크 요청을 통해 가져온 데이터의 경우 서버 측 렌더링을 지원하기 위해 항상 저장소를 사용하십시오 (최종 목표라고 생각하는 경우). 그렇지 않으면 재수화할 수 없습니다.

두 개 이상의 컨테이너에서 해당 상태를 수신하려면 매장에도 있어야합니까?

나는 임시와 영구의 구별에 대해 @gaeron 과 동의합니다. 그러나 저는 실제로 이것에 대해 세 가지 범주로 생각합니다. 하나는 그가 이야기하는 UI 상태 이며 저는 또한 일시적이라고 생각합니다. 또 하나는 애플리케이션의 실제 핵심 인 라우팅 상태 입니다. 나는 사람들에게 친숙하기 때문에 "라우팅"이라는 용어를 사용하지만, 데스크탑, 웹 및 모바일에 더 잘 적용되는 것으로 생각하기 때문에 이것을 "보기 선택"상태로 추상화합니다.

이제 이것은 사람들이 보는 것을 결정하기 때문에 UI 상태라고 주장 할 수 있습니다 (예를 들어 탭의 상태와 매우 유사 함). 그러나 나는 두 가지 차이점을 본다. 첫 번째는 상태가 직렬화되어 (즉, URL로) 다른 사람에게 전송된다는 것입니다. 따라서 사람들이 특정 UI 상태에 바로 '딥 링크'할 수 있도록하려면 경로 상태로 이동해야합니다 . 두 번째는 대부분의 경우 초기 경로 상태 또는 경로 변경으로 인해 애플리케이션 상태가 변경됩니다 (예 : 볼 데이터로드). 물론 UI의 작업은 동일한 작업을 수행합니다. 그러나 내가 만드는 차이점은 경로 상태 변경에 대한 "애플리케이션 논리" 를 테스트하기 위해보기 나 렌더링없이 경로 상태를 가질 수 있다는 것입니다. 뷰와 렌더링이 관련 될 필요가 없기 때문에 부분적으로 애플리케이션 상태 인 IMHO가됩니다.

이것이 상태 관리를위한 Redux 대 React의 질문과 어떤 관련이 있습니까? 애플리케이션 상태는 Redux의 도메인이고 UI 상태는 React의 도메인입니다. 그러나 라우팅 상태는 (내 생각에) UI 상태로 볼 수 있지만 Redux에서 관리해야합니다 (내가 생각하는 이유에 대한 자세한 내용은 포함 된 링크 참조).

분명히 말하면 , 움직이는 것에 대한

애플리케이션 상태는 Redux의 도메인이고 UI 상태는 React의 도메인입니다.

나는 이것을 주장하지 않습니다. React에서 일부 앱 상태를 유지하고 Redux에서 일부 UI 상태를 유지하는 것이 좋습니다. 나는 그들이 도메인으로 분리되어야한다고 생각하지 않습니다.

Redux로 앱을 만드는 경우 제가 생각하는 방식은 단일 상태 트리를 수용합니다. 거기에 UI 상태도 넣으십시오. 그러나 지루하고 답답해지면 구성 요소에 상태를 넣는 것을 두려워하지 마십시오. 내 요점은 어색하지 않는 한 단일 상태 트리를 사용하고 복잡하게 만들지 않고 단순화 할 때만 사용한다는 것입니다. 이것이 유일한 지침입니다.

먼저 @gaearon 의 입에 단어를 넣을 생각은 없었습니다. 죄송합니다.

둘째, @gaearon에 전적으로 동의합니다. 저는 또한 단일 상태 트리 접근 방식을 굳게 믿습니다. UI 상태에 대해 이야기 할 때, 응용 프로그램 상태와는 관련이 없을 수있는 사소한 것 (예 : 선택한 현재 탭)이 있었습니다 (정확히

제 입장을 명확히하겠습니다. 나는 경로 상태를 포함하여 거의 모든 것이 Redux에 있어야 한다는 데 동의합니다 (내가 Redux와 TypeScript를 사용하여 TodoMVC 구현 에서했던 것처럼. 나는 구체적으로 경로 상태를 언급했고 그것을 구별했습니다. 구현) 확실히 Redux에 속하고 (그리고 렌더링에 전혀 연결되어서는 안 됨) 확실히 "UI 상태"가 아닙니다.

React 구성 요소의 경우 상태를 거의 사용하지 않습니다. 나는 무엇을 렌더링할지에 대한 정보를 얻고 내 컴포넌트 외부의 변경을 트리거하기 위해 호출 할 수있는 클로저를 얻기 위해 props를 사용하는 것을 선호합니다. 삶을 편하게하기 위해 구성 요소에 상태를 도입하는 경우가 드물지만 피하려고합니다. 나는 그것이 일을 명확히하기를 바랍니다.

저는이 질문이 정말 주관적이고 복잡하다고 생각합니다. 그래서 오늘 저희 팀과 함께 어려운 결정을 내 렸습니다. 신경 쓰지 마세요.

• Redux에 연결되어있는 재사용 불가능한 컨테이너의 경우 모든 것을 Redux 저장소에 넣습니다. 심지어 모달이 열려있는 것과 같은 작은 UI 상태라도 더 이상 this.setState 사용하지 마십시오.
• Redux와 관련이없는 재사용 가능한 컴포넌트의 경우 React state를 사용하십시오.

이제 우리는 작은 UI 상태를 관리하는 일을 덜 지루하게 만들기 위해 몇 가지 도우미를 구현하고 있습니다.

@gaearon @ lionng429 @xogeny 이 접근 방식에 대해 생각할 수있는 단점이 있습니까?

@inetfuture TypeScript를 사용하고 있고 애플리케이션 상태에 대한 유형을 완전히 정의하기 때문에 애플리케이션 (redux) 상태에 대해 약간 비참한 경향이 있습니다. 즉, 렌더링에서 모든 상태 조작을 분리하기 위해 구성 요소 라이브러리를 개발할 때 발생했습니다 (자세한 내용은 이전 주석의 링크 참조). 이것은 사소하지 않은 일반적인 구성 요소에 대해서도 완전히 상태를 외부화한다는 것을 의미합니다. 나는 일반적으로 모든 것을 props (상태 조작을위한 상태와 클로저 모두)를 통해 전달합니다. 이렇게하면 애플리케이션 상태에 쉽게 연결할 수 있습니다. 이것의 일부는 의심 할 여지없이 TypeScript를 사용하는 인공물이며 combineReducers 및 connect 를 사용하여 물건을 연결 (최소한 유형 제약 조건을 유지)하는 데 사용할 수 없습니다. 따라서 이것은 아마도 대표적인 관점이 아닙니다. 그러나 나는 당신이 "모든 것을 Redux 스토어에 넣어 라"라고 말하는 이유를 말할 것입니다. 나는 당신이 상태의 부엌 싱크대가 될 것이라고 걱정할 것입니다. TypeScript를 사용한다는 것은 응용 프로그램 상태를 확장하는 데 약간의 노력이 필요하다는 사실이 "정말이게 필요한가요?"라는 결정을 내 리도록 강요하기 때문에 반드시 나쁜 것은 아닙니다. 물건을 쌓아 두는 대신.

대안으로 로컬 구성 요소 상태는 빠른 업데이트 시간이 필요한 제어 된 입력에 유용 할뿐만 아니라 트리거되는 실제 작업 수를 줄일 수 있습니다. 현재 프로토 타입에서는 현재 편집중인 항목을 소품으로받는 양식 편집 HOC를 구성했습니다. 또한 변경된 필드를 해당 상태로 저장 한 다음 결합 된 로컬 WIP 변경으로 디 바운스 된 "EDIT_ITEM_ATTRIBUTE"작업 생성자를 호출하여 양식 입력 변경 이벤트를 처리합니다. 그 결과 양식 자체 만 다시 렌더링되고 훨씬 적은 수의 작업이 트리거되기 때문에 양식 필드가 즉시 업데이트됩니다 (예 : 'A'를 몇 초 동안 누르고 있으면 'AAAAAAAAAAAA'값만 'A', 'AA'등이 아닌 액션으로 전송됩니다.

누군가 관심이 있다면 https://gist.github.com/markerikson/554cab15d83fd994dfab 에서 요점으로 HOC를 얻었습니다.

어쨌든 요점은 구성 요소 상태와 저장소 상태 모두 용도가 있다는 것입니다. 실제 사용 사례를 고려해야합니다.

재사용 가능한 구성 요소의 경우 충분히 크고 복잡하다면 주로 추적 성 및 테스트 용 재생을 위해 Redux에 상태를 유지하는 것이 미래에 대비할 수 있습니다. 그러나이 코드 재사용이 정확히 어떻게 설계되어야하는지에 대해서는 여전히 약간의 의문이 있습니다 (컴포넌트, 액션, 리듀서).

우리의 응용 프로그램에서 우리는 연결과 같은 스타일로이 문제를 해결했습니다. https://github.com/Babo-Ltd/redux-state

Redux에 상태를 저장하는 것이 어색한 경우는 거의 없었습니다. 나는 그것이 제공하는 힘을 좋아하고, 필요할 때 다른 구성 요소와 상호 작용하도록 만들 수 있습니다.

어색 할 수있는 유일한 생각은 폼 요소의 상태를 처리하는 것입니다. 왜냐하면 그것들이 너무 많을 수 있기 때문입니다. 이 경우 redux-form 과 같은 라이브러리를 사용합니다.

내 요점은 어색하지 않는 한 단일 상태 트리를 사용하고 복잡하게 만들지 않고 단순화 할 때만 사용한다는 것입니다. 그게 유일한 지침입니다

@gaearon 이

@idavollen 몇 가지 줄 수 있습니다.

• 드롭 다운 열기 / 닫기 상태, 그렇지 않으면 상점의 모든 드롭 다운 구성 요소를 추적해야합니다.
• <input> 변경을 디 바운싱 할 때 상태를 사용하여 값을 즉시 업데이트하고 (다른 구성 요소가 불필요하게 다시 렌더링 할 위험이 없음) 디 바운스 된 방식으로 스토어를 업데이트 할 수 있습니다.

기본적으로 다른 구성 요소에 영향을주지 않는 상태에 사용해야합니다.

예를 들어 고려해야 할 세 번째 상황이 있습니다. 예를 들어, 앞에 체크 박스가 있고 제출 버튼이있는 여러 줄로 구성된 양식 (렌더링 메서드에서 비용이 많이 드는 반응 컨테이너 구성 요소)이 있습니다. 제출 버튼을 클릭하면 체크 박스가 체크 된 라인을 폼에 제출해야합니다. 즉, 사용자가 토글 할 때 폼을 제출하기 전 개별 체크 박스의 일시적인 상태는 중요하지 않으며 컴포넌트 상태로 취급해서는 안되며 체크 박스 토글로 인해 발생하지 않아야합니다. render ()를 호출합니다.

당분간은 확인란 상태를 응용 프로그램 상태 원 자나 로컬 구성 요소 상태, 즉 확인란을 토글하는 동안 불필요한 render () 호출을 피하기 위해 폼 반응 구성 요소에 넣지 않았습니다. 인스턴스 변수는 체크 박스를 유지하는 것보다 선호되지만 반응 패턴에 위배됩니다.

이 경우 이러한 확인란 상태를 관리하는 가장 좋은 방법이 무엇인지 궁금합니다.

@idavollen 이 확인란은 제어되지 않습니까? 그렇지 않은 경우 어쨌든 다시 렌더링하므로 구성 요소의 상태에서 선택된 항목을 추적하고이를 사용하여 제출할 데이터 부분을 선택할 수 있습니다.

Redux는 구성 요소의 상태에 비해 얼마나 빠릅니까? 실제 이벤트와 렌더링 프로세스 사이의 타이밍 측면에서 정말 합리적인 UI 소품을 위해 Redux를 사용해야합니까? 구성 요소 상태를 사용하려면 그렇게 간단하지 않은 의사 소통이 많이 필요한 복잡한 상황이 있습니다. 이 문제에 대한 도움을 주시면 감사하겠습니다.

@tiberiumaxim 내 경험상 (저는 스마트 TV와 같은 저전력 장치에서 실행되는 react 및 redux로 앱을 개발합니다). 대부분의 경우 구성 요소 상태를 업데이트하는 것이 더 성능이 좋을 것입니다. 그 이유는 발생해야하는 차이가 더 작은 데이터 세트에 있고 디스패치가 발생하지 않기 때문입니다. 구성 요소 또는 자식 만 해당 상태에 액세스해야하는 경우 로컬 구성 요소 상태를 고수하는 것이 더 좋으며 이는 종종 UI 관련 상태의 경우이지만 특정 지점에서 해당 데이터를 redux 저장소에 유지해야하는 경우- 로컬 (컴포넌트) 상태와 글로벌 (redux) 상태의 조합을 사용해야 할 수 있으며 정확한 시간 (예 : 사용자가 페이지에서 벗어날 때)에 해당 데이터를 redux 저장소에 유지해야합니다. 특정 사건에 대해 좀 더 설명해 주시면 더 자세한 정보를 드릴 수 있습니다

Redux에 들어가는 상태와 구성 요소에 대해 로컬로 유지되는 것은 사용자가 결정합니다. http://redux.js.org/docs/faq/OrganizingState.html#organizing -state-only-redux-state 및 http://redux.js.org/docs/faq/Performance를 통해 읽을 수 html # performance -scaling을 참조하십시오.

@deowk 성능 문제에 대한 지식을 공유해 주셔서 감사합니다. 저도 마찬가지라고 생각했지만 확인이 필요했습니다.
또한 @markerikson 링크에 감사드립니다. 다시 한 번 살펴 보겠습니다.

누군가 명시 적으로 언급했는지 확실하지 않지만 로컬 구성 요소 상태는 Redux에서도 관리 할 수 ​​있습니다. 구성 요소 생성자에서 바로 상점을 만들 수 있습니다. 이 로컬 저장소는이 구성 요소의 상태를 포함하고이 구성 요소와 관련된 작업을 처리합니다 (및이 저장소의 dispatch 함수 또는 해당 dispatch 함수를 호출하는 콜백을 전달하여 해당 하위 항목). .

이 아키텍처는 수동으로 구현하거나 redux-fractal, redux-ui 등과 같은 일부 라이브러리를 사용할 수 있습니다.

또는 Dan이 지적했듯이 구성 요소의 상태를 업데이트하는 감속기 스타일의 접근 방식을 구현할 수도 있습니다! https://twitter.com/dan_abramov/status/736310245945933824 참조

활동 표시기 및 모달 열기 또는 닫기와 같은 UI 상태를 저장할 위치를 알고 싶습니다. setState를 사용하면 반응 구성 요소의 단위 테스트에 문제가 발생합니까?

@ akshay2604 : 다시, 그것은 당신에게 달려 있습니다. 이 스레드의 이전 댓글에 게시 한 링크를 참조하십시오. 특히 구성 요소를 테스트하는 데 도움이되는 Enzyme 라이브러리를 사용하는 경우 구성 요소를 테스트하는 동안 setState 를 확실히 사용할 수 있습니다.

제 생각을 공유하겠습니다.

애플리케이션의 입력 / 출력과 관련되는 방식에 따라 상태를 3 가지 범주로 분류합니다.

• "캐시": 영구 데이터의 미러 상태입니다. 예:

{ "todos": [{ id: 1, title: "title" }, { id: 2, title: "title" }] }

• "변경": 영구 데이터에 대한 보류중인 변경을 설명하는 상태입니다. 예:

{ "changeTodo": { title: "title", action: "add", done: false },
{ id: 1, title: "changed title", action: "modify", done: true }, { id: 2, action: "delete" } }

• "view": 현재 필터링, 정렬 등과 ​​같은보기 옵션을 전달하는 상태입니다. 예 :

{ "displayOptions": { searchTerm: "title", sort: ["title", "desc"], filter: "done=false" } }

cache 과 changes 혼합하지 않고 cache 과 view 혼합하지 않으며 view 과 (와) 혼합하지 않습니다. changes

물론 단일 반응 구성 요소에 표시하려면 어떻게 든 병합해야합니다. 따라서 "병합 된"개체는 다음과 같습니다.

{ "todos": [{id: undefined, title: "title", done: false }, { id: 1, title: "changed title" }] }

그러나 이는 상태가 아니라 애플리케이션 로직 의 결과입니다. 따라서 어디에도 보관해서는 안됩니다.
이 병합 된 상태를 선택기에서 캐시 할 수 있고, 저장소에서 캐시 할 수 있으며, 구성 요소에 캐시 할 수 있지만 "상태"가 아니며 중요하지 않으며 애플리케이션 논리 함수를 3 개의 상태 부분에 모두 쉽게 다시 적용 할 수 있습니다. 병합 된 상태를 다시 얻습니다. 이것이 바로 기능적 접근 방식입니다.

Redux 관리자는 "응용 프로그램 로직을 여러 리듀서와 여러 이벤트로 구현해야합니다. 그러면"병합 된 "객체의 다른 부분을 구성하게됩니다."라고 말합니다.
잘못된 접근이라고 생각합니다. 그것은 당신이 redux에서 벗어날 수 없다는 것을 의미합니다. 상태를 관리하는 도구로 의도 된 것은 본질적으로 응용 프로그램 논리 의 구현이됩니다.

안녕하세요, 저는 며칠 동안 React / Redux를 살펴보고 일부 정보를 구성 요소 로컬 상태에 저장하거나 유지할지 여부를 선택하기로 한 결정을 이해합니다.

하지만 하나의 행동이 동시에 두 가지를 모두 요구한다면 어떻게 될까요? 다음은 매우 일반적인 사용 사례입니다.

1. [컨텍스트] Redux 저장소는 단일 리프 { modelItems: myModelItems } 입니다. 서버 모델을 캐시 (일부 / 투영)합니다.
2. [컨텍스트] 뷰는 저장된 / 캐시 된 항목의 UI 목록을 표시하는 단일 스마트 구성 요소 MyItemsView 로 구성됩니다. 마운트되면 구성 요소가 모델 항목 가져 오기를 트리거합니다. 구성 요소 입력 : myModelItems . 구성 요소 출력 : fetchModelItems 액션 트리거. 구성 요소 내부 : state.busy 및 state.errorId
3. [계획] MyItemsView 가 fetchModelItems MyItemsView 트리거하면 모델을 가져 와서 저장소에 캐시하기 위해 HTTP 요청이 서버로 전송됩니다. 이 비동기 작업에는 다음과 같은 4 단계와 많은 후크가 있습니다. onStarted (HTTP 요청이 시작 되려고하고 구성 요소에서 스피너로드가 시작됨), onEnded (HTTP 응답이 시작됨, 스피너로드가 구성 요소에서 중지됨) , 여전히 응답 상태를 보지 않음), onFailed (구성 요소에 오류 알림이 표시됨) 및 onSucceed (Redux 저장소가 업데이트 된 다음 보유하고있는 모델 캐시가 전달됨) 렌더링을위한 구성 요소)

따라서 fetchModelItems 액션 트리거를 다음과 같이 분할하는 방법 :

• onStarted , onEnded 및 onFailed 는 Redux 스토어에 도달하지 않습니까? 이는 onStarted 및 onEnded 가 모델 캐시와 상호 작용하지 않아야하는 일시적인 UI 상태이기 때문입니다. onFailed 마찬가지입니다 (모델 캐시는 변경되지 않고 UI가 오류 알림을 렌더링합니다). MyItemsView 는 여기에 캐시 된 모델이 아닌 UI 상태를 렌더링합니다.
• onSucceed 이 Redux 스토어를 강타합니까? 이 모델 캐시 복권에 당첨이 있기 때문에, 다음 렌더링, 재수 샤워 것, 진리의 소스에 대한 액세스 권한을 부여 신선한 myModelItems 에서 MyItemsView

내 현재 시도의 구현에 대해 Redux Thunk는 fetchModelItems 작업 트리거를 처리합니다. 나는 그곳에서 Redux 경로를 선택한 것 같고, "비동기 성공을 Redux 스토어에 전달하고 다른 것은 React 컴포넌트 상태에 유지하라"고 더 이상 마음을 바꿀 수 없다고 느낍니다.

이것에 당혹스러워서 저장된 성공을 가져오고 연결된 구성 요소 (예 : Redux 컨테이너)로 전달합니다. 그러나 로딩 스피너와 비참한 콘솔 로그 오류 메시지 atm이 없습니다. store.ui.myItemsView.busy 나 store.ui.myItemsView.errorId 정의하고 싶지는 않지만 구성 요소 상태에서 해당 정보를 가져옵니다.

@pascalav :
이것은 지원 시스템이 아니라 버그 추적기입니다. 사용법에 대한 질문은 더 많은 사람들이 도움을 줄 준비가되어있는 Stack Overflow 또는 Reactiflux를 사용하십시오. 아마도 더 나은 답변을 더 빨리 얻을 수있을 것입니다. 감사!