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