그래서 클라이언트 전체에 수분을 공급하기 전에 전체 번역 객체를 redux 저장소에 두는 것이 좋습니다. 이 번역 객체는 약 50kb의 gzip이며, 115kb의 압축되지 않은 객체입니다.redux 상점의 크기가 너무 큽니까?
전체 사이트가 번역되므로이 번역 개체는 기본적으로 웹 사이트의 모든 비 동적 사본을 나타냅니다. 초기 HTTP 요청에서 클라이언트에 수분이 공급되면 최소한 사내 복사를 위해 즉석 브라우징 환경을 제공해야합니다.
그러나이 방법, redux 저장소가 너무 길면 궁금합니다.
번역을 별도로로드해야합니다. Webpack은 도움이되는 코드 분할을 허용합니다. 또는 스크립트 태그를 사용할 수도 있습니다.
별도로로드하는 이유는 브라우저에서 캐시 할 수 있기 때문입니다. 이렇게하면 사용자 당 한 번만로드 할 수 있습니다. React에 의해 생성 된 HTML 페이지가 동적이고 전달한 저장소가 동적이기 때문에 캐싱 할 수 없습니다.
데이터가 너무 크기 때문에 각 페이지로드시로드하는 것은 좋지 않습니다.
또한 매장은 주 전용입니다. 변화하는 것을 처리하는 것입니다. 정적 데이터를 거기에 넣는 것은 그것이 처리하려고하는 것이 아닙니다. 이것은 완료 할 수 없다는 것을 의미하지는 않지만 좋은 일치는 아닙니다.
Redux 저장소에 '너무 큰'크기가 있다고 생각하지 않습니다. 그러나 응용 프로그램 상태 만 포함해야합니다. 번역 오브젝트는 코드에 있어야하며 i18n 라이브러리를 통해 액세스해야합니다. 상태에는 사용자에게 표시해야하는 언어가 나와 있어야합니다.
모호하고 주관적인 ... 상점 내부 _is_ "코드". 또한 번역 데이터를 직접 상점에 통합하는 [여러 솔루션] (https://github.com/zoover/react-redux-i18n)이있는 것 같습니다. 좀 더 구체적인 것이 있습니까, 아니면 당신의 의견입니까? 분명히 말하자면, 나는 주 내부의 키에 직접 액세스하지 않고 단지 거기에 로딩하고 거기에 i18n을 지정하는 것입니다. –
@JohnDoe 당연히 제 생각에 저장소에 원하는 것을 저장할 수 있지만 Redux 설명서의 첫 번째 줄에 "상태 컨테이너"라고 나와 있습니다. 응용 프로그램의 전역 상태를 나타내지 않는 모든 정적 데이터를 저장하는 이유는 무엇입니까? –
사용자가 자유롭게 UI 언어를 변경할 수 있다는 의미에서 "상태"입니다. 지역화 된 컨텐츠는 실제로 애플리케이션의 "상태"입니다. –