Redux-여러 상점, 왜 그렇지 않습니까?

Redux-여러 상점, 왜 그렇지 않습니까?

---

참고로 : 나는 Redux (Baobab)에 대한 문서를 읽었으며 Googling & testing에 대해 상당한 부분을 공유했습니다.

Redux 앱에 하나의 스토어 만있는 것이 왜 그렇게 강력하게 제안됩니까?

단일 상점 설정과 다중 상점 설정의 장단점을 이해합니다 ( 이 주제에 대해서는 SO에 대한 많은 Q & A가 있습니다 ).

IMO,이 아키텍처 결정은 프로젝트 요구에 따라 앱 개발자에게 속합니다. 그렇다면 왜 의무적으로 들리는 지점까지 Redux에 강력히 제안되어 있습니까 ( 여러 매장을 만드는 데 방해가되지는 않지만 )?

편집 : 단일 저장소로 변환 한 후 피드백

몇 달 동안 많은 사람들이 복잡한 SPA를 고려할 때 redux와 함께 일한 후, 단일 상점 구조는 순수한 기쁨이었습니다.

단일 저장소 대 많은 저장소가 많은 유스 케이스에서 왜 까다로운 질문인지 이해하는 데 도움이되는 몇 가지 사항 :

• 신뢰할 수 있습니다 : 선택기를 사용하여 앱 상태를 파고 컨텍스트 관련 정보를 얻습니다. 필요한 모든 데이터가 단일 저장소에 있다는 것을 알고 있습니다. 그것은 국가 문제가 어디에있을 수 있는지에 대한 모든 의문을 피합니다.
• 빠르다 : 우리 매장에는 현재 100 개에 가까운 감속기가 있습니다. 그 수에 관계없이 주어진 디스패치에서 소수의 감속기 만 데이터를 처리하고 나머지는 이전 상태를 반환합니다. 거대 / 복잡한 저장소 ( nbr of reducers )가 느리다는 주장은 상당히 무례합니다 . 최소한 성능 문제가 발생하지 않았습니다.
• 친숙한 디버깅 : 이것은 redux를 전체적으로 사용하는 가장 설득력있는 주장이지만 단일 저장소 대 다중 저장소에도 사용됩니다. 앱을 빌드 할 때 프로세스에서 상태 오류 ( 프로그래머 실수 )가 발생하는 것은 정상입니다. PITA는 이러한 오류가 디버깅하는 데 몇 시간이 걸리는 경우입니다. 단일 저장소 ( 및 redux-logger ) 덕분에 특정 주 문제에 몇 분 이상을 투자 한 적이 없습니다.

몇 가지 조언

Redux Store를 구축 할 때 실제로 해결해야 할 과제는 구조화 방법을 결정할 때 입니다. 첫째, 도로 구조를 바꾸는 것은 큰 고통이기 때문입니다. 둘째, 사용 방법을 결정하고 모든 프로세스에 대해 앱 데이터를 쿼리하기 때문입니다. 상점을 구성하는 방법에 대한 많은 제안이 있습니다. 우리의 경우 다음이 이상적이라는 것을 알았습니다.

{
  apis: {     // data from various services
    api1: {},
    api2: {},
    ...
  }, 
  components: {} // UI state data for each widget, component, you name it 
  session: {} // session-specific information
}

이 피드백이 다른 사람들에게 도움이 되길 바랍니다.

편집 2-유용한 상점 도구

단일 상점 을 "쉽게"관리하는 방법을 궁금해 한 사람들에게는 복잡해집니다. 상점의 구조적 종속성 / 논리를 분리하는 데 도움이되는 도구가 있습니다.

이 Normalizr 스키마를 기반으로 데이터를 정규화. 그런 다음 데이터와 작업 id하고 사전과 매우 유사한 방식으로 데이터의 다른 부분을 가져올 수있는 인터페이스를 제공합니다 .

당시 Normalizr을 모르면서 같은 줄을 따라 무언가를 만들었습니다. relational-json 은 스키마를 가져 와서 데이터베이스와 비슷한 테이블 기반 인터페이스를 반환합니다 . relational-json의 장점은 데이터 구조가 데이터의 다른 부분을 동적으로 참조한다는 것입니다 ( 기본적으로 일반 JS 객체와 마찬가지로 모든 방향으로 데이터를 탐색 할 수 있음 ). Normalizr만큼 성숙하지는 않지만 현재 몇 달 동안 프로덕션에서 성공적으로 사용하고 있습니다.

---

여러 상점을 사용할 수있는 경우가 있습니다 (예 : 초당 같은 시간에 화면에있는 수천 개의 항목 목록을 업데이트하는 데 성능 문제가있는 경우). 그것은 예외이며 대부분의 앱에서는 단일 저장소 이상을 필요로하지 않습니다.

문서에서 왜 이것을 강조합니까? Flux 백그라운드에서 온 대부분의 사람들은 여러 상점이 업데이트 코드를 모듈화하는 솔루션이라고 가정합니다. 그러나 Redux에는이를위한 다른 솔루션이 있습니다 : 리듀서 구성.

리듀서 트리로 더 분할 된 여러 리듀서를 갖는 것은 Redux에서 모듈 식 업데이트를 유지하는 방법입니다. 이것을 인식하지 못하고 감속기 구성을 완전히 이해하지 않고 여러 상점을 방문한다면 Redux 단일 상점 아키텍처의 많은 이점을 놓치게 될 것입니다.

• 감속기 구성을 사용하면 waitFor추가 정보와 특정 순서로 다른 감속기를 수동으로 호출하는 감속기를 작성하여 Flux에서 "종속 업데이트"를 쉽게 구현할 수 있습니다 .

• 단일 저장소를 사용하면 상태를 유지하고 수화하고 읽는 것이 매우 쉽습니다. 서버 렌더링 및 데이터 프리 페칭은 클라이언트에서 채우고 다시 수화해야하는 데이터 스토리지가 하나뿐이므로 JSON은 상점의 ID 또는 이름에 대한 걱정없이 컨텐츠를 설명 할 수 있기 때문에 간단합니다.

• 단일 저장소는 Redux DevTools 시간 여행 기능을 가능하게합니다. 또한 환원 기 수준에서 작동하기 때문에 redux-undo 또는 redux-optimist와 같은 커뮤니티 확장을 쉽게 만듭니다. 이러한 "감소 기 향상제"는 상점에 쓸 수 없습니다.

• 단일 상점은 디스패치가 처리 된 후에 만 ​​구독이 호출되도록 보장합니다. 즉, 리스너가 알림을받을 때까지 상태가 완전히 업데이트되었습니다. 많은 상점에서 그러한 보장은 없습니다. 이것이 플럭스에 waitFor목발이 필요한 이유 중 하나입니다 . 단일 상점의 경우 처음에는 문제가 아닙니다.

• 무엇보다도 Redux에서는 여러 상점이 불필요합니다 (어쨌든 먼저 프로파일 링해야하는 성능 측면의 경우 제외). 우리는 문서에서 중요한 점을 지적하므로 플럭스처럼 Redux를 사용하지 않고 감속기 구성 및 기타 Redux 패턴을 배우고 그 이점을 잃는 것이 좋습니다.

---

수백 또는 수천 개의 리듀서가있는 대규모 엔터프라이즈 앱에서는 앱의 여러 영역을 완전히 별도의 앱으로 생각하는 것이 종종 유용합니다. 이 경우 (실제로 도메인 이름을 공유하는 여러 앱인 경우) 여러 저장소를 사용합니다.

예를 들어 다음 공통 기능 영역을 별도의 앱으로 취급하는 경향이 있습니다.

• 관리자
• 대시 보드 분석 / 데이터
• 결제 관리 및 구매 흐름
• 엔터프라이즈 계정 팀 / 권한 관리

그 중 하나라도 작 으면 기본 앱의 일부로 유지하십시오. 엔터프라이즈 계정 관리 및 분석 도구와 같이 규모가 매우 커지면이를 분리하십시오.

매우 큰 앱을 관리하는 가장 좋은 방법은 여러 개의 작은 앱 구성으로 취급하는 것입니다.

앱이 ~ 50k LOC 미만인 경우이 조언을 무시하고 대신 Dan의 조언을 따라야합니다.

If your app is more than 1 Million LOC, you should probably be splitting out mini-apps, even if you maintain them in a mono repo.

---

This architectural decision belongs to the app developers based on their projects' needs

You are living in your own world. I am meeting with people that uses redux, because it is popular, everyday. You couldn't even imagine how much projects was started reduxing without any decisioning. I hate redux approaches but had to use it, because other developers knows nothing else. It's just an epic bubble inflated by facebook.

• It's not reliable because parts of store are not isolated.
• It's inefficient because you are cloning and traversing hash trie. When mutations grows arithmetically - complexity grows geometrically. You couldn't fix it by refactoring any reducers, selectors, etc. You have to split your trie.
• When it become slow nobody wants to split it into separate applications with separate stores. Nobody wants to spend money on refactoring. People are usually converting some smart components into dump and that's it. Do you know what future is waiting for redux developers? They will maintain these hells.
• It's not debugging friendly. It's hard to debug connections between virtually isolated parts of store. It is very hard even to analyze the amount of these connections.

Let's imagine that you have several redux stores. You will break unidirectional data flow. You will immediately realize how much connections between stores you have. You can suffer from these connections, fighting with circular deps, etc.

Single immutable store with unidirectional flow is not an elixir for every disease. If you don't want to maintain project architecture you will suffer anyway.

---

Multiple stores can be helpful in the following use cases 1. If you have large components that are independent of each other in terms of data structure, behavior, application context. Isolating these components make it easier to manage your data and application flow. It also helps independent development and maintenance of your components. 2. Performance problems: not a typical use case, but if some of your components are updating very frequently and does not have any impact on other components, probably you can go for different stores.

For all other cases, you may not need to have multiple stores. As Dan says, creating thoughtful reducer compositions can prove to be better solution.

---

why we can't use multiple store using redux????

This is not necessary in Redux because the separation between data domains is already achieved by splitting a single reducer into smaller reducers.

---

Can or should I create multiple stores? Can I import my store directly, and use it in components myself?

The original Flux pattern describes having multiple “stores” in an app, each one holding a different area of domain data. This can introduce issues such as needing to have one store “waitFor” another store to update.

This is not necessary in Redux because the separation between data domains is already achieved by splitting a single reducer into smaller reducers.

As with several other questions, it is possible to create multiple distinct Redux stores in a page, but the intended pattern is to have only a single store. Having a single store enables using the Redux DevTools, makes persisting and rehydrating data simpler, and simplifies the subscription logic.

Some valid reasons for using multiple stores in Redux might include:

Solving a performance issue caused by too frequent updates of some part of the state, when confirmed by profiling the app. Isolating a Redux app as a component in a bigger application, in which case you might want to create a store per root component instance. However, creating new stores shouldn't be your first instinct, especially if you come from a Flux background. Try reducer composition first, and only use multiple stores if it doesn't solve your problem.

Similarly, while you can reference your store instance by importing it directly, this is not a recommended pattern in Redux. If you create a store instance and export it from a module, it will become a singleton. This means it will be harder to isolate a Redux app as a component of a larger app, if this is ever necessary, or to enable server rendering, because on the server you want to create separate store instances for every request.

official doc by redux

---

Having one store in Redux is really what we need in many cases, I both used Redux and Flux and believe Redux does the job better!

Don't forget the store is in a JavaScript Object, so while you have only one store, it can be easily extended and reused, to me, having one store make it much easier to traversing using Redux dev tools and not be mixed up in big applications...

Also the concept of one store is mimicking the database for us, one source of truth which you can change it and you can access it in the browser memory...

If the whole application be well-managed, one store can be enough to manage the whole application status...

참고URL : https://stackoverflow.com/questions/33619775/redux-multiple-stores-why-not