Como observação: li os documentos do Redux (Baobab também) e fiz uma boa parte do Google e dos testes.
Por que é tão fortemente sugerido que um aplicativo Redux tenha apenas uma loja?
Entendo os prós / contras de uma configuração de loja única versus uma configuração de loja múltipla ( há muitas perguntas e respostas sobre SO neste assunto ).
Na IMO, essa decisão de arquitetura pertence aos desenvolvedores de aplicativos com base nas necessidades de seus projetos. Então, por que isso é tão fortemente sugerido para o Redux, quase a ponto de parecer obrigatório ( embora nada esteja nos impedindo de fazer várias lojas )?
EDIT: feedback após a conversão em loja única
Depois de alguns meses trabalhando com redux no que muitos considerariam um SPA complexo, posso dizer que a estrutura de uma única loja foi uma delícia pura de se trabalhar.
Alguns pontos que podem ajudar outras pessoas a entender por que uma loja única versus muitas lojas são uma questão discutível em muitos casos de uso:
- é confiável : usamos seletores para percorrer o estado do aplicativo e obter informações relevantes ao contexto. Sabemos que todos os dados necessários estão em uma única loja. Evita todos os questionamentos sobre onde poderiam estar as questões estatais.
- é rápido : atualmente, nossa loja possui cerca de 100 redutores, se não mais. Mesmo nessa contagem, apenas um punhado de redutores processa dados em um determinado envio, os outros retornam o estado anterior. O argumento de que uma loja enorme / complexa ( nbr de redutores ) é lenta é bastante discutível. Pelo menos não vimos nenhum problema de desempenho vindo daí.
- amigável para depuração : embora esse seja o argumento mais convincente para usar o redux como um todo, ele também vale para loja única versus loja múltipla. Ao criar um aplicativo, você provavelmente terá erros de estado no processo ( erros do programador ), é normal. A PITA é quando esses erros levam horas para depurar. Graças à loja única ( e redux-logger ), nunca gastamos mais do que alguns minutos em qualquer problema de estado.
algumas dicas
O verdadeiro desafio na construção de sua loja redux é ao decidir como estruturá- la. Em primeiro lugar, porque mudar a estrutura no caminho é apenas uma grande dor. Em segundo lugar, porque determina em grande parte como você usará e consultará os dados do seu aplicativo para qualquer processo. Há muitas sugestões sobre como estruturar uma loja. No nosso caso, achamos o seguinte ideal:
{
apis: { // data from various services
api1: {},
api2: {},
...
},
components: {} // UI state data for each widget, component, you name it
session: {} // session-specific information
}
Espero que esse feedback ajude outras pessoas.
EDIT 2 - ferramentas úteis da loja
Para aqueles que se perguntam como gerenciar "facilmente" uma única loja , que pode se tornar rapidamente complexa. Existem ferramentas que ajudam a isolar as dependências / lógica estrutural da sua loja.
Existe o Normalizr que normaliza seus dados com base em um esquema. Em seguida, fornece uma interface para trabalhar com seus dados e buscar outras partes id
, como um dicionário.
Não conhecendo a Normalizr na época, construí algo na mesma linha. O relational-json pega um esquema e retorna uma interface baseada em tabela ( um pouco como um banco de dados ). A vantagem do relational-json é que sua estrutura de dados faz referência dinâmica a outras partes de seus dados ( essencialmente, você pode atravessá-los em qualquer direção, assim como objetos JS normais ). Não é tão maduro quanto o Normalizr, mas estou usando-o com sucesso na produção há alguns meses.