Reaja em ação: arquitetura de aplicativo Redux

Os aplicativos modernos devem fazer mais do que nunca e, correspondentemente, mais complexos - tanto interna quanto externamente. Os desenvolvedores há muito tempo estão cientes do caos causado pelo crescimento de aplicativos complexos que carecem de um design consistente. O código tipo espaguete não só não é divertido, mas também retarda o progresso de desenvolvimento dos desenvolvedores, o que, por sua vez, retarda o progresso das unidades de negócios. Lembra da última vez que você trabalhou em uma grande base de código cheia de soluções descartáveis ​​e plug-ins jQuery? Estima-se que isso não seja interessante. Para combater a confusão, os desenvolvedores desenvolveram um paradigma como o MVC (Model-View-Controller) para organizar as funções do aplicativo e orientar o desenvolvimento. O Flux (e sua extensão Redux) é o mesmo, tudo para ajudar os desenvolvedores a lidar com a complexidade crescente dos aplicativos.

Se você não está particularmente familiarizado com o paradigma MVC, não se preocupe, não vamos gastar muito tempo discutindo isso neste livro. Mas, para fins de comparação, antes de discutir Flux e Redux, vamos discutir brevemente MVC. Aqui estão alguns conhecimentos básicos.

• Dados de aplicativo do modelo (modelo). Normalmente substantivos como usuário, conta ou postagem. O modelo deve ter pelo menos métodos básicos para manipular os dados associados. No sentido mais abstrato, um modelo representa dados ou conhecimento bruto. O modelo é onde os dados interagem com o código do aplicativo. Por exemplo, o banco de dados pode armazenar atributos como accessScope, authenticated, etc. O modelo pode usar esses dados em métodos como isAllowedAccessForResource () nele, e esses métodos irão operar nos dados subjacentes do modelo. O modelo é onde os dados originais e o código do aplicativo convergem.
• Representação de vista do modelo. A visualização geralmente é a própria interface do usuário. Não deve haver nenhuma lógica na visualização que não tenha nada a ver com a representação de dados. Para estruturas de front-end, isso geralmente significa que uma determinada visualização está diretamente associada ao recurso e tem operações CRUD (criar, ler, atualizar, excluir) associadas a ela. Os aplicativos front-end não são mais sempre criados dessa maneira.
• Controlador (controlador) - O controlador é a "cola" que une o modelo e a visualização. Os controladores geralmente devem ser apenas colados e não fazer mais nada (por exemplo, eles não devem conter visualizações complexas ou lógica de banco de dados). De modo geral, a capacidade dos controladores de modificar os dados deve ser muito menor do que os modelos com os quais eles interagem.

Embora o paradigma (Flux e Redux) discutido neste capítulo seja muito diferente desses conceitos, o objetivo é ajudar os desenvolvedores a criar arquiteturas de aplicativos escaláveis, razoáveis ​​e eficazes.

A origem e o design do Redux se devem a um modelo popular chamado Flux dentro do Facebook. Se você está familiarizado com o padrão MVC popular usado por Ruby on Rails e outras estruturas de aplicativos, então o Flux pode ser diferente do padrão com o qual você está acostumado. O Flux não decompõe as várias partes do aplicativo em modelos, visualizações e controladores, mas define várias partes diferentes.

• store-store contém o estado e a lógica do aplicativo. É um pouco parecido com o modelo do MVC tradicional. No entanto, eles gerenciam o estado de muitos objetos em vez de representar um único registro do banco de dados. Ao contrário do modelo, os desenvolvedores podem representar os dados de qualquer maneira razoável, sem serem restritos por recursos.
• Os aplicativos Action-Flux não atualizam diretamente o estado, mas modificam o estado do aplicativo criando ações que modificam o estado.
• interface de visualização do usuário, geralmente React, mas o Flux não precisa do React.
• despachante - um coordenador centralizado para operar e atualizar a loja.

A Figura 10-1 mostra uma visão geral do Flux.

 

Figura 10-1 Uma visão geral simples do Flux

Conforme mostrado na Figura 10-1, no modo Flux, a ação é criada a partir da visualização (talvez o usuário clique em algo) e, em seguida, o despachante processa a ação recebida e, em seguida, envia a ação para o armazenamento apropriado para atualização status. Depois que o estado muda, a visualização da notificação deve usar os novos dados (se aplicável). Observe como isso é diferente de uma estrutura de estilo MVC típica. Em uma estrutura de estilo MVC, tanto a visualização quanto o modelo (como a loja aqui) podem atualizar um ao outro. Este fluxo de dados bidirecional é diferente do fluxo de dados mais unidirecional que é típico na arquitetura Flux. Além disso, observe a falta de middleware aqui: embora o middleware possa ser criado no Flux, ele não é um cidadão de primeira classe como no Redux, então o omitimos aqui.

Se você já desenvolveu um aplicativo estilo MVC antes, parte do conteúdo soa familiar, mas o método de fluxo de dados pode não ser o caso. Conforme mencionado anteriormente, os dados fluem mais em uma direção no paradigma Flux, que é diferente da forma bidirecional que as implementações do tipo MVC tendem a usar. Isso geralmente significa que não há uma fonte única de fluxo de dados no aplicativo; muitas partes diferentes do sistema têm o direito de modificar o estado, e o estado geralmente está espalhado por todo o aplicativo. Esse método funciona bem em muitas situações, mas em aplicativos maiores, a depuração e o uso podem ser confusos.

Imagine como isso seria em um aplicativo de médio a grande porte. Suponha que haja um conjunto de modelos (usuários, contas e autenticação) associados a seus próprios controladores e visualizações. Em qualquer lugar do aplicativo, é difícil determinar a localização exata do estado, porque o estado é distribuído em várias partes do aplicativo (as informações sobre o usuário podem ser encontradas em qualquer um dos 3 modelos mencionados anteriormente).

Para aplicativos menores, isso pode não ser necessariamente um problema e pode até funcionar bem em aplicativos maiores, mas em aplicativos clientes grandes, pode se tornar mais difícil. Por exemplo, o que acontece quando o uso do modelo precisa ser modificado em 50 locais diferentes e há 60 controladores diferentes que precisam estar cientes da mudança de estado? Para tornar as coisas mais complicadas, a visualização às vezes se comporta como um modelo em algumas estruturas de front-end (portanto, o estado é mais disperso). Onde está a verdadeira fonte dos dados? Se ele estiver espalhado por visualizações e muitos modelos diferentes, e todos eles estiverem em um ambiente moderadamente complexo, será difícil manter o controle de tudo em mente. Isso também pode levar a inconsistências no estado do aplicativo, o que irá causar bugs no aplicativo. Portanto, este não é apenas um problema que "apenas os desenvolvedores enfrentam", os usuários finais também serão diretamente afetados.

Parte da razão pela qual isso é difícil é que as pessoas geralmente não são boas em inferir mudanças ao longo do tempo. Para entender verdadeiramente esta questão, imagine um tabuleiro de xadrez em sua mente. Não é difícil manter um instantâneo de um tabuleiro de xadrez ou mesmo alguns em sua cabeça, mas você pode acompanhar cada instantâneo de cada tabuleiro de xadrez por 20 rodadas? Que tal a rodada 30? Que tal todo o jogo? Como é difícil rastrear em nossas mentes as mudanças assíncronas de dados ao longo do tempo, devemos construir sistemas que sejam mais fáceis de pensar e usar. Por exemplo, considere chamar uma API remota e usar seus dados para atualizar o estado do aplicativo. Isso é simples para um pequeno número de casos, mas se você precisar chamar 50 terminais de servidor de API diferentes e rastrear as respostas recebidas, enquanto o usuário ainda está usando o aplicativo e fazendo alterações que podem causar mais interações de API, O que vai acontecer então? É difícil separá-los em sua mente e prever o resultado das mudanças.

Você deve ter notado algumas semelhanças entre React e Flux. Ambos são formas relativamente novas de construir interfaces de usuário e visam aprimorar os modelos mentais usados ​​pelos desenvolvedores. Nessas duas maneiras, as alterações devem ser fáceis de inferir e os desenvolvedores devem ser capazes de construir a IU de uma forma que aprimore em vez de interferir.

Como o Flux se parece no código real? É principalmente um paradigma, portanto, existem muitas bibliotecas que implementam a ideia central do Flux. Essas bibliotecas são ligeiramente diferentes na maneira como implementam o Flux. Redux é o mesmo, embora seu estilo Flux exclusivo tenha ganhado a maioria dos usuários e atenção. Outras bibliotecas Flux incluem Flummox, Fluxxor, Reflux, Fluxible, Lux, McFly e MartyJS (embora na prática essas bibliotecas sejam raramente usadas em comparação com Redux).

10.1.1 Primeiro encontro com Redux: uma variante do Flux

Talvez Redux seja a biblioteca mais amplamente usada e conhecida que implementa as idéias por trás do Flux. A biblioteca Redux implementa a ideia de Flux de uma forma ligeiramente modificada. A documentação do Redux o descreve como um "contêiner de estado previsível para aplicativos JavaScript." Especificamente, isso significa que ele coloca os conceitos e ideias do Flux em prática de sua própria maneira.

Não é importante determinar a definição exata de Fluxo aqui, o importante é que irei apresentar algumas diferenças importantes entre os paradigmas de Fluxo e Redux.

• Redux usa um único armazenamento - os aplicativos Redux não armazenam informações de estado em vários armazenamentos no aplicativo, mas salvam tudo em um só lugar. O fluxo pode ter vários armazenamentos diferentes. Redux quebra essa regra e impõe o uso de um único armazenamento global.
• Redux introduz redutores-redutores fazem mudanças de uma forma mais imutável. No Redux, o estado é alterado de forma determinística e previsível, apenas uma parte do estado é modificada por vez, e isso ocorre apenas em um lugar (no armazenamento global).
• O Redux apresenta o middleware - como as ações e o fluxo de dados são unilaterais, os desenvolvedores podem adicionar middleware aos aplicativos Redux e injetar comportamentos personalizados quando os dados são atualizados.
• As ações do Redux não são acopladas à loja - os criadores da ação não enviarão nada para a loja, em vez disso, eles retornarão o objeto de ação usado pelo planejador central.

Para você, podem ser apenas nuances, não importa - seu objetivo é aprender Redux, não "encontrar a diferença". A Figura 10-2 mostra uma visão geral da arquitetura Redux. Vamos mergulhar em cada uma das diferentes partes, explorar como elas funcionam e desenvolver uma arquitetura Redux para seu aplicativo.

 

Figura 10-2 Visão geral do Redux

Conforme mostrado na Figura 10-2, ação, armazenamento e redutor constituem o corpo principal da arquitetura Redux. Redux usa um objeto de estado centralizado, que é atualizado de forma específica e determinística. Quando o desenvolvedor deseja atualizar o estado (geralmente devido a eventos como cliques), uma ação é criada. As ações têm tipos que um redutor específico tratará. Um redutor que processa um determinado tipo de ação gera uma cópia do estado atual, usa os dados da ação para modificá-lo e, em seguida, retorna ao novo estado. Quando o armazenamento é atualizado, a camada de visualização (aqui, o componente React) pode ouvir a atualização e responder de acordo. Observe também que as visualizações na figura apenas leem as atualizações da loja - elas não se importam com os dados com os quais se comunicam. A biblioteca React-redux passará novos adereços para o componente quando a loja muda, mas a visualização ainda só recebe e exibe dados.

10.1.2 Preparando para Redux

Redux é um paradigma de arquitetura de aplicativo, também é uma biblioteca instalável. Este é um aspecto do Redux sobre a implementação "bruta" do Flux. Existem muitas implementações do paradigma Flux (como Flummox, Fluxxor, Reflux, Fluxible, Lux, McFly e MartyJS), e todos eles têm diferentes níveis de suporte da comunidade e diferentes APIs. Redux tem forte suporte da comunidade, mas a API da biblioteca Redux em si é muito pequena e poderosa, o que a ajuda a se tornar uma das bibliotecas de arquitetura de aplicativo React mais populares e mais confiáveis. Na verdade, o uso de Redux com React é tão comum que as duas equipes principais frequentemente se comunicam para garantir compatibilidade e reconhecimento de recursos. Algumas pessoas estão até em duas equipes ao mesmo tempo, então há boa visibilidade e boa comunicação entre os dois projetos.

Para configurar o Redux para usá-lo, algum trabalho precisa ser feito.

• Certifique-se de executar o npm install com o código-fonte do capítulo atual para que todas as dependências corretas sejam instaladas localmente. Neste capítulo, começaremos a utilizar várias novas bibliotecas, incluindo js-cookie, rudux-mock-store e redux.
• Instale as ferramentas de desenvolvedor Redux. Podemos usá-los para visualizar a loja e ação do Redux no navegador.

Redux foi projetado para ser previsível, o que torna fácil criar incríveis ferramentas de depuração. Dan Abramov e outros engenheiros trabalhando nas bibliotecas Redux e React desenvolveram algumas ferramentas poderosas para lidar com aplicativos Redux. Como o estado no Redux muda de maneira previsível, é possível depurar de novas maneiras: os desenvolvedores podem rastrear mudanças individuais no estado do aplicativo, verificar as diferenças entre as mudanças e até mesmo retroceder e reproduzir o estado do aplicativo conforme ele muda. Mudanças de tempo. A extensão Redux Dev Tools permite que os usuários concluam todas essas tarefas e ainda mais, e é empacotada como uma extensão do navegador para distribuição. A Figura 10-3 fornece uma visão rápida das funções da Redux Dev Tool.

 

Figura 10-3 A extensão Redux Dev Tools empacota a popular biblioteca Redux Dev Tools de Dan Abramov em uma extensão de navegador conveniente. Com ele, você pode retroceder e reproduzir aplicativos Redux, ver as mudanças uma a uma, verificar as diferenças entre as mudanças de estado, verificar o estado de todo o aplicativo em uma área, gerar modelos de teste, etc.

Após instalar a extensão, você deverá ver o ícone da nova ferramenta de desenvolvimento na barra de ferramentas do navegador. No final do período de escrita, só ficará colorido quando uma instância do aplicativo Redux for detectada em modo de desenvolvimento, portanto, se o aplicativo ou site visitado não utilizar Redux, a extensão não funcionará. Porém, uma vez que o aplicativo esteja configurado, você verá que o ícone fica colorido e, clicando nele, a ferramenta será aberta.

Este artigo foi retirado de "React Actual Combat"

Este livro orienta o leitor a pensar sobre interfaces de usuário (IU) como um especialista e ensina o leitor a construí-las com React. Este livro é muito prático, com muitos exemplos práticos, permitindo aos leitores começar rapidamente. O objetivo deste livro é permitir que os leitores dominem os principais conceitos de renderização, métodos de ciclo de vida, JSX, fluxo de dados, formulários, roteamento, integração com bibliotecas e testes de terceiros e ajudar os leitores a usar os conceitos de design de aplicativo introduzidos no livro para promover a popularidade do aplicativo. No processo de aprendizagem da integração do React em um aplicativo full-stack, os leitores também podem explorar o gerenciamento de estado e a renderização do lado do servidor por meio do Redu ** e até mesmo entrar em contato com o React Native para IU móvel. Este livro foi escrito especificamente para desenvolvedores familiarizados com HTML, CSS e JavaScript.

O conteúdo principal deste livro
● Use o React do zero.
● Implementar sistema de roteamento com componentes.
● Renderização do lado do servidor em Node.js.
● Use bibliotecas de terceiros.
● Teste os componentes do React.