As dificuldades de trabalhar com o Redux e sua solução

Redux entre nós

Este é um dos mais populares gerenciadores de estado .

É fácil de usar, transparente e previsível. Com ele, você pode organizar o armazenamento e a modificação de dados. E se assumirmos que ações `` e redutores ' ' são parte do redux `a, podemos dizer sem exagero que ele é o detentor de toda a lógica da área de assunto (também conhecida como lógica de negócios) de nossos aplicativos.

Tudo é tão róseo?

Por toda a sua simplicidade e transparência, o uso do redux tem várias desvantagens ...

Os dados no estado ` redux` e estão em um objeto javascript simples e podem ser obtidos da maneira usual, basta conhecer o caminho .

Mas como organizamos esses dados? Existem apenas duas opções: uma lista simples e um modelo hierárquico .

Uma lista simples é uma ótima opção para um aplicativo no qual existe apenas, por exemplo, um contador ... Para algo mais sério, precisamos de uma estrutura hierárquica. Além disso, cada nível de dados terá menos conhecimento que o anterior. Tudo é lógico e compreensível, mas o caminho para os dados se torna composto .



A presença de uma estrutura hierárquica de dados e a falta de uma abordagem modular para esses dados levam ao fato de que, em todos os lugares em que esses dados são usados, é necessário conhecer o caminho completo para eles. Em outras palavras, isso cria uma coesão da estrutura de armazenamento de dados e de suas estruturas de exibição e leva a dificuldades com o refator do caminho e / ou reorganização da estrutura de dados.




Outro desafio é testar. Sim, há um artigo separado na documentação para teste de redux , mas agora não se trata de testar artefatos individuais como redutor e criador de ações .

Dados, ações e redutores geralmente são interconectados. E uma árvore de dados logicamente relacionados é geralmente atendida por vários redutores , que você precisa testar incluindo juntos.

Adicione a esta lista os seletores cujos resultados dependem, em especial, do trabalho dos redutores .

Em geral, você pode testar tudo isso, mas precisa lidar com vários artefatos que são interconectados apenas por lógica e convenções.

E se surgíssemos uma estrutura, por exemplo, com dados do usuário, incluindo listas de amigos, músicas favoritas e outras coisas, além da funcionalidade de alterá-las através dos redutores de ação . Talvez até escrevamos vários testes para toda essa funcionalidade. E agora, no próximo projeto, precisamos da mesma coisa ...

Como codificar barato?

Procure uma solução

Para descobrir como preservar os benefícios do redux e se livrar das desvantagens descritas, você precisa entender do que isso depende no ciclo de vida dos dados:

• Eventos de relatório de ação , personalizados e muito mais
• O redutor reage às ações e altera ou não altera o estado dos dados
• A alteração de dados é um evento em si e pode causar a alteração de outros dados.

O controlador nesse caso é uma abstração que processa ações do usuário e alterações de dados na loja . Ele não precisa ser uma classe separada, como regra, ele é espalhado por componentes.

Combine todo o zoológico de redux em uma caixa preta

Mas e se você agrupar ações , redutores e seletores em um módulo e ensiná-lo a não depender de um caminho específico para a localização de seus dados?

E se todas as ações do usuário , por exemplo, forem confirmadas chamando o método da instância: user.addFriend (friendId) ? E os dados são obtidos através do getter: user.getFriendsCount () ?

E se pudermos importar todas as funcionalidades do usuário com uma importação simples?

 const userModule from 'node_modules/user-module'; 

É conveniente? Especialmente considerando que, para isso, você não precisa escrever um monte de código extra:
O pacote npm redux-module-creator fornece todas as funcionalidades para a criação de módulos redux fracamente acoplados, reutilizáveis e testados .

Cada módulo consiste em um controlador , um redutor e uma ação e possui os seguintes recursos:

• integra-se à loja por meio de uma chamada ao método integrador e, para alterar o local da integração, é necessário alterar apenas o local da chamada do integrador e seu parâmetro
  
  
  
• o controlador tem uma conexão com sua parte dos dados na loja , lembrando o caminho que é passado para o integrator () uma vez. Isso elimina a necessidade de conhecê-lo ao usar dados.
  
  
  
• o controlador é o detentor de todos os seletores, adaptadores etc. necessários
• Para rastrear alterações, é possível assinar alterações em seus próprios dados
• o redutor pode usar o contexto de chamada - uma instância do módulo e obter actionType`s pertencentes ao módulo. Isso elimina a necessidade de importar várias ações e reduz a probabilidade de erro.
• As ações obtêm o contexto de uso, porque se tornam parte da instância do módulo: agora não é apenas trainingFinished , mas readingModule.actions.trainingFinished
• agora existem ações no namespace do módulo, o que permite criar eventos com o mesmo nome para diferentes módulos
• cada módulo pode ser instanciado várias vezes e cada instância é integrada em diferentes partes da loja
• ações para diferentes instâncias de módulos têm diferentes actionType - você pode responder a eventos de uma instância específica

Como resultado, obtemos uma caixa preta que pode gerenciar seus dados e possui alças para se comunicar com código externo.

Ao mesmo tempo, é o mesmo redux , com seu fluxo de dados unidirecional, transparência e previsibilidade.

E como esses são todos o mesmo redux e os mesmos redutores , é possível construir qualquer estrutura a partir deles que a lógica do domínio do aplicativo exija.