Isenção de responsabilidade
Caro leitor! Se você não tem idéia do que são React e Redux, ler mais não faz sentido, mais bobagens técnicas. Sério, para que serve esta nota, é necessário trabalhar com essas bibliotecas - apesar de tentar escrever com clareza, este artigo não é de nível básico. E isso é experiência pessoal e opinião com base na prática.
O que há de errado em usar o Redux?
Decidi escrever, mas o que há de errado em usar o redux no meu projeto e em milhares de outros? Escrevo aplicativos de reação / redux desde abril de 2016 (três anos). Já é hora de descobrir algumas coisas interessantes ... E havia palestras e relatórios, especialmente voltados para iniciantes, mas não havia nenhum adulto olhando para trás e nenhuma retrospectiva. Enquanto isso, alguém coloca asteriscos em pacotes que verificam "você não tem 13 horas por hora", quebrarei o muro dos estereótipos predominantes.
Mas redux não é necessário!
Você diz, e de certa forma você estará certo. Ele não pode ser usado desde 2018 - há uma tonelada de artigos sobre esse tópico na Internet, mas até agora com o “não uso” de uma fazenda coletiva é obtida, ficará claro abaixo o porquê. E o número de alternativas está fora de escala e mais ainda.
Usamos o Redux, por ser um padrão aceito (pelo menos para reagir), a previsibilidade e a confiabilidade do Redux são importantes para nós. Mas sentimos muito a falta, na verdade, neste
Reivindicar
Provavelmente, para deixar claro qual é a afirmação sobre os pontos, primeiro você precisa voltar ao passado, às raízes, como quiser, ou seja, abrir a documentação do glorioso redux e ler os postulados. Vou considerar apenas o primeiro deles. Se for interessante para você - compartilhe nos comentários, analisarei muitos outros pontos.
A única fonte da verdade ...
Aqui nós temos uma emboscada. Obviamente, diz que pode haver uma história, o redux declara sua diferença da arquitetura de fluxo dessa maneira. Mas se você olhar mais amplamente: a regra é observada em um projeto real? Você dirá: bastante. Declaro (declaro) 1 lado, transfiro-o para o provedor e depois ...
Tecnicamente, o processo está descrito corretamente. Mas posso dizer que as pessoas estão sujeitas a distorções de percepção, lógica e como os programadores ainda são pessoas ... Bem, você entende o que estou levando (se você não entendeu: os programadores são propensos a distorções de percepção, lógica etc.)
A principal distorção aqui é que eu, como muitos de meus colegas, estamos acostumados ao fato de que, se não usarmos o termo “loja” em relação a algo que não seja redux, não haverá outros.
E aí vem a reação
Um recurso técnico chamado estado interno queria cuspir neste postulado. Ele simplesmente cria um armazenamento do tipo estado interno em qualquer local conveniente. Existe um componente - existe um estado que possui um mecanismo para atualizar e influenciar o componente. A diferença de uso (estado da loja, atualização e alterações de transmissão) é quase invisível. Você pode objetar: não está totalmente claro por que você não gosta do estado do componente. Ele não é como editores, como eles podem ser comparados! É interno, bem, o que sinaliza para armazenar lá.
Entenda que a essência não muda do fato de você renomear o item. Há uma marreta na segunda-feira, isso não acontece no dia da semana. Sim, ambas as segundas-feiras são difíceis, outros dias e marretas são mais fáceis. Mas, pelo nome, a marreta não deixa de ser um instrumento de percussão.
A escala do componente de reação de redux e estado é diferente, mas a essência, quando usada hoje, é uma.
Vou explicar da seguinte maneira: na maioria dos casos, os dados do estado interno do componente vão para a criança por meio de adereços, mas, por mais óbvio que seja, os dados de redux, quando integrados ao react, também entram nos componentes por meio de adereços. Do ponto de vista do componente que aceita adereços, não importa o que está fora. Ou seja, para o usuário final - esse armazenamento redux, esse estado interno - é o mesmo.
Além disso, esse estado interno pode não depender dos props do componente em que é declarado. Em seguida, obtemos um isolamento que torna esse estado interno uma loja ainda maior do que você imagina.
Para que seja verdadeiramente interno, deve afetar apenas o componente onde é declarado, sem causar vazamentos nos componentes filhos. Isso é difícil? Bastante, porque seu significado está quase completamente perdido. Este é outro sinal de que o estado interno é uma loja. Afinal, simplesmente removemos um ponto do objetivo de “armazenar o estado, atualizar e transmitir mudanças” - transmitir as mudanças. Tudo, o estado está perdido.
Ou seja, o principal problema de ter um estado interno é que ele concorre com o redux por dados, perde a longo prazo e porcaria. Temos todo tipo de técnicas, como o estado de elevação (é quando o irmão do elemento host é necessário, portanto a parte do estado e toda a lógica de trabalhar com ele são levadas ao pai, gastando muito tempo reescrevendo e testando a lógica de trabalho) etc. Aparecem erros e despesas gerais em melhorias e muita alegria. Esse é todo o barulho que estraga nosso software na fase de desenvolvimento. Não alcançamos vendas, mas o software já é assim.
Ou seja, para todos os sinais e problemas, temos mais de uma história e muitos problemas associados a isso. A última coisa, provavelmente, será a seguinte:
Eu também amo redux pelo tipo de ferramentas que ele possui. Quando comecei, usamos um logger que simplesmente consolidou todas as ações, sem fornecer, no entanto, uma imagem completa do que estava acontecendo. Agora - este é o assistente principal e amigo. No React, eles também são representados. Em geral, o devtools é a razão pela qual qualquer pubsub está longe do Redux. Como uma formiga a uma baleia azul.
Problemas (não haverá provas de DNA):
- alterar o estado interno por meio de react devtools às vezes não leva a uma atualização ou ao resultado desejado - peço a integração com o redux.
- estado interno quebra horários em redux devtools. O super recurso com viagens no tempo disponível na arquitetura redux não funciona graças à reação da arquitetura interna do estado. O estado interno simplesmente não se importava com uma mudança no redux, ele tem seu próprio estado. Timetravel simplesmente não funciona. Alguns elementos simplesmente não são atualizados, parcialmente atualizados etc. Tudo isso épico com sincronização de código assíncrona no ralo.
Um exemplo, é claro, sugado da prática
Você está trabalhando em um novo projeto para você, ou seu colega escreveu algumas funcionalidades há um ano e agora você precisa expandi-las. Em geral, há a tarefa de finalizar o código de outra pessoa. Você começa a investigar e entende que não há dados nos editores. Não há ações, redutores no código que armazenam os dados necessários. E você começa a jornada através da árvore de componentes em busca dos tesouros e os encontra (!!!) até algumas peças. Você pergunta aos colegas, mas a resposta é padrão: não me lembro de escrever para o estado mais rapidamente, não tínhamos tempo e assim por diante. Você acessa a fonte e entende que seu estado atual não envolve revisão. Você está reescrevendo o código testado e funcionando para fazer alterações e adicionar novas funcionalidades.
A presença de uma alternativa perniciosa na forma de um estado interno faz sua ação suja. Afinal, agora é barato e não importa o que acontece em um ano.Poucas metáforas
Parece comida ruim - parece saborosa e barata, mas depois de um ano ou três - o trato gastrointestinal deixa de obedecer e vive sua própria vida. Você gasta muito tempo e dinheiro em recuperar sua saúde anterior e nem sempre consegue isso.
Redux e React Internal State são concorrentes , como grandes e pequenas empresas em um nicho. O principal produto são dados e influência. O software é o consumidor de seus produtos. Existem muitas analogias, mas a essência permanece a mesma - quando desenvolvemos software - não precisamos de concorrência.
Somos os "ditadores" do código do programa e qualquer concorrência deve ser reprimida, o livre mercado deve ser proibido e a economia planejada e o monopólio estatal devem dominar o consumidor.Ahem, algo me aborreceu. Tudo deve ir conforme o planejado, em geral. Temos sprints, lançamentos e muito mais, e o software tem um custo finito e uma vida útil / entrada no mercado. Isso é muito importante, e não podemos permitir o tumulto no navio, a revolta das bibliotecas.
A conclusão é simples.
Não use outros repositórios com redux. Exceções podem criar apenas casos muito isolados. Por exemplo, componentes que, em princípio, não são controlados pelo redux sem a camada correspondente e não o afetam.
Exemplo
Desenvolvi o módulo independente em uma ramificação e refatorando a loja em outra - em geral, minha abordagem para gerenciar a loja e o estado é um tópico separado para publicação. Comecei a refatorar para o módulo, mas no início e no final da gravação do módulo, a refatoração para o teste e o assistente não desapareceu. A refatoração é grande e requer recursos ponderados que precisam ser planejados - em geral, você não pode apenas tomar e refatorar.
Portanto, sabendo das próximas mudanças na loja, não a usei para desenvolver um novo recurso. Isso aumentaria os custos de atualização de refatoração e testes abandonados às vezes.
O que fiz: me inscrevi para um mínimo de dados. Os dados e sua estrutura não sofreram refatoração, o código que os gerou sofreu, salvou etc. Não escrevi um byte para os editores. Verifico se o usuário está logado e mais alguns campos.
Para minhas necessidades, lavei o PubSub com canais e uma API simples. Sim, sim, pubsab. Falta de dor dolorosa normal. Viagem no tempo - dor. Em geral, pretendo escrever uma extensão para chrome na forma de devtools e é possível publicar a reimplementação como concorrente para reduxar no github. Tenho muitas reclamações sobre redux, que não levantarei neste artigo, mas o PubSub praticamente não as possui. Além do fato de eu me lembrar do redux logger ...
E assim o módulo tem seu próprio armazenamento, sua própria conexão com o servidor.
Ou seja, o redux não afeta o módulo, praticamente não pode afetar esse armazenamento (existem apenas três campos na assinatura), mas o módulo e o PubSub não afetam o redux de forma alguma. Essa separação exclui a concorrência.
A pergunta "onde armazenar os dados?" ao desenvolver o módulo, nunca o encontrei. Mas quando se trata de redux vs estado interno - para muitos, essa pergunta surge quase constantemente. Decidi responder a essa pergunta de uma vez por todas.
Minha opinião arquitetônica é:
Armazene dados apenas no redux (todos, inclusive "internos"), se estiverem conectados ao seu projeto de reação como o repositório principal, não use repositórios que irão competir com ele. Isso aumentará a confiabilidade e o impacto desta biblioteca e de suas ferramentas (o rastreamento de tempo e o rastreamento de todos os dados em etapas agilizam o desenvolvimento e a busca de possíveis problemas - as alterações síncronas são mais íngremes e fáceis de serem assíncronas).
Talvez valha a pena adicionar uma biblioteca que exclua completamente o estado interno do desenvolvimento? Ou substitui o estado interno por uma seleção do redux, por exemplo? Comecei a escrever um ano atrás, terminei 90% e até conduzi 1 relatório. O que você diz Precisa disso?
Espero que tenham gostado desta nota :)