리덕스는 왜 단일 스토어를 사용하는가?

TL;DR : 리덕스의 모듈화 단위는 스토어가 아니라 리듀서다

Dan Abramov의 답변 번역입니다 : https://stackoverflow.com/questions/33619775/redux-multiple-stores-why-not

Redux - multiple stores, why not?

여러 스토어를 사용해야 하는 극단적인 경우가 있습니다

예: 화면에 표시되는 수천 개의 항목 목록을 초당 여러 번 업데이트하는 데 성능 문제가 있는 경우).

하지만 이는 예외 케이스이며 대부분의 앱에서는 단일 스토어면 충분합니다.

 

공식 문서에서 이를 강조하는 이유는 무엇일까요?

Flux 배경에서 온 대부분의 사람들은 멀티 스토어가 업데이트 코드를 모듈식으로 만드는 솔루션이라고 가정하기 때문입니다.

 

그러나 Redux는 이에 대한 다른 솔루션을 제공합니다.

 

바로 리듀서 합성입니다.

리듀서 트리로 추가적으로 분할될 수 있는 여러 리듀서를 만드는 것이

Redux에서 업데이트를 모듈식으로 유지하는 방법입니다.

 

이를 먼저 이해하지 못하고 여러 스토어를 사용하고 있다면,

Redux의 단일 스토어 아키텍처의 많은 이점을 놓치고 있는 것입니다.

• 리듀서 합성을 사용하면 추가 정보와 함께 특정 순서로 다른 리듀서를 수동으로 호출하는 리듀서를 작성하여 Flux의 waitFor와 같은 "종속 업데이트"를 쉽게 구현할 수 있습니다.
•  단일 저장소를 사용하면 영속, 수화 및 상태 읽기가 매우 쉽습니다.
  • 서버 렌더링 및 데이터 프리페치는 클라이언트에서 채우고 다시 수화해야 하는 데이터 저장소가 하나뿐입니다.
  • JSON은 스토어의 ID나 이름에 대해 걱정하지 않고 해당 내용을 설명할 수 있기 때문에 좋습니다.
•  단일 스토어는 디스패치가 처리된 후에만 구독 함수가 호출되는 것을 보장합니다.
  • 즉, 리스너가 알림을 받을 때는, 이미 상태가 완전히 업데이트 된 후입니다. 여러 스토어를 사용하면 이를 보장할 방법이 없습니다.
  • 이것이 Flux가 waitFor를 필요로 하는 이유 중 하나입니다. 단일 스토어에서 이는 애초부터 문제가 안됩니다.
•  무엇보다 Redux에서는 여러 스토어가 필요하지 않습니다(성능 이슈에 의한 엣지 케이스 제외: 프로파일링 필요).
  • Flux처럼 Redux를 사용하여 이점을 잃는 대신 리듀서 합성 및 기타 Redux 패턴을 배우세요