본문으로 건너뛰기

스토어 설정

비공식 베타 번역

이 페이지는 PageTurner AI로 번역되었습니다(베타). 프로젝트 공식 승인을 받지 않았습니다. 오류를 발견하셨나요? 문제 신고 →

Redux FAQ: 스토어 설정​

여러 개의 스토어를 생성할 수 있나요? 스토어를 직접 임포트해 컴포넌트에서 사용해도 되나요?​

원본 Flux 패턴은 애플리케이션에 여러 "스토어"를 두고 각각 다른 도메인 데이터를 관리하도록 설계됐습니다. 이 방식은 한 스토어가 다른 스토어 업데이트를 waitFor 해야 하는 문제를 유발할 수 있습니다. Redux에서는 단일 리듀서를 작은 리듀서들로 분리함으로써 데이터 도메인 분리가 이미 구현되므로 이 방식이 필요하지 않습니다.

다른 질문들에서와 마찬가지로, 페이지에 여러 개의 독립된 Redux 스토어를 생성하는 것이 기술적으로 가능하지만, 의도된 패턴은 단일 스토어를 사용하는 것입니다. 단일 스토어를 사용하면 Redux DevTools 활용이 가능해지고, 데이터 지속성(persisting) 및 재수화(rehydrating)가 간소화되며, 구독 로직이 단순해집니다.

Redux에서 여러 스토어를 사용해야 하는 타당한 이유는 다음과 같습니다:

  • 앱 프로파일링으로 확인된 특정 상태 부분의 과도한 업데이트로 인한 성능 문제 해결

  • 대규모 애플리케이션 내 컴포넌트로 Redux 앱을 격리할 때 (루트 컴포넌트 인스턴스당 스토어 생성 필요)

그러나 새로운 스토어 생성은 (특히 Flux 배경에서 온 경우) 첫 번째 선택지가 되어서는 안 됩니다. 먼저 리듀서 컴포지션을 시도하고, 문제가 해결되지 않을 때만 다중 스토어를 사용하세요.

마찬가지로, 스토어 인스턴스를 직접 임포트해 참조하는 것이 기술적으로 가능하지만 Redux에서 권장되는 패턴은 아닙니다. 스토어 인스턴스를 생성해 모듈에서 내보내면 싱글톤이 됩니다. 이는 대규모 앱의 컴포넌트로 Redux 앱을 격리해야 하거나 서버 사이드 렌더링을 구현해야 할 때 문제가 됩니다. 서버에서는 요청마다 별도의 스토어 인스턴스를 생성해야 하기 때문입니다.

React Redux의 경우, connect() 함수로 생성된 래퍼 클래스는 실제로 props.store가 존재할 때 이를 찾지만, 최상위 컴포넌트를 <Provider store={store}>로 래핑하고 React Redux가 스토어 전파를 처리하게 하는 것이 가장 좋습니다. 이렇게 하면 컴포넌트가 스토어 모듈을 임포트할 필요가 없어지며, Redux 앱 격리나 서버 렌더링 구현이 훨씬 수월해집니다.

추가 정보​

문서

토론

스토어 인핸서에 여러 미들웨어 체인을 두어도 되나요? 미들웨어 함수에서 next와 dispatch의 차이는 무엇인가요?​

Redux 미들웨어는 연결된 리스트처럼 동작합니다. 각 미들웨어 함수는 다음 미들웨어로 액션을 전달하기 위해 next(action)을 호출하거나, 리스트 시작부터 처리 재개를 위해 dispatch(action)을 호출하거나, 액션 처리 중단을 위해 아무것도 하지 않을 수 있습니다.

이 미들웨어 체인은 스토어 생성 시 사용되는 applyMiddleware 함수에 전달된 인자로 정의됩니다. 여러 체인을 정의하면 제대로 작동하지 않습니다. 각기 다른 dispatch 참조를 가지게 되어 체인들이 효과적으로 분리되기 때문입니다.

추가 정보​

문서

토론

상태 일부만 구독하려면 어떻게 해야 하나요? 구독 시 디스패치된 액션을 얻을 수 있나요?​

Redux는 스토어 업데이트 시 리스너에게 알리는 단일 store.subscribe 메서드를 제공합니다. 리스너 콜백은 현재 상태를 인자로 받지 않으며, 단순히 무언가 변경됐음을 알립니다. 구독 로직은 이후 getState()를 호출해 현재 상태 값을 가져올 수 있습니다.

이 API는 의존성이나 복잡성 없이 저수준 프리미티브로 설계됐으며, 고수준 구독 로직 구축에 사용될 수 있습니다. React Redux 같은 UI 바인딩은 연결된 컴포넌트마다 구독을 생성합니다. 이전 상태와 새 상태를 지능적으로 비교하고 특정 부분이 변경됐을 때 추가 로직을 실행하는 함수 작성도 가능합니다. redux-watch, redux-subscribe, redux-subscriber 등이 구독 지정과 변경 처리에 대한 다양한 접근 방식을 제공합니다.

새 상태가 리스너에게 전달되지 않는 것은 Redux DevTools 같은 스토어 인핸서 구현을 단순화하기 위함입니다. 또한 구독자는 액션이 아닌 상태 값 자체에 반응하도록 의도됐습니다. 액션이 중요하고 특별히 처리해야 한다면 미들웨어를 사용할 수 있습니다.

추가 정보​

문서

토론

라이브러리