Get best of the week

Redux Toolkit não é mais necessário?

O problema da enorme quantidade de código padrão ao usar o Redux é conhecido por todos, todos resolvem da melhor maneira possível. E usamos muletas e bicicletas diferentes em projetos diferentes, sem perder a esperança de encontrar algo padronizado e conveniente. Há pouco mais de um ano, desesperávamos nossa pesquisa e levamos a sério a solução para o problema. O que veio disso é descrito abaixo.

História de aparência


Nossa empresa está desenvolvendo projetos para startups em todo o mundo. E para esses caras loucos de inspiração, o mais importante (ou um deles) é o tempo. Anteriormente entrou no mercado - maiores chances de sobrevivência. Portanto, sempre tentamos reduzir o tempo de desenvolvimento sem sacrificar a qualidade e reduzir o número de erros causados ​​pelo fator humano. Na maioria das vezes, escolhemos algo padrão e mais ou menos estável. Nesse caso, não foi possível encontrar nada pronto, então eles arregaçaram as mangas e começaram a ver o que poderia ser pedalado aqui.



Como sempre, começamos com uma descrição do problema e obtivemos o seguinte:

  • Cada desenvolvedor tem seu próprio sotaque sutil ao escrever código, é difícil conseguir a implementação do conceito de "código despersonalizado";
  • Muito código (clichê, copiar e colar e todos os problemas resultantes), mais de 100 linhas em CRUD;
  • É gasto muito tempo escrevendo coisas básicas. Você vai esquecer uma coisa, a outra: definir carregamento, lidar com erros, etc;
  • A estrutura da loja difere de projeto para projeto e, às vezes, entre diferentes partes do projeto.

Uma pergunta feita corretamente ou um problema formulado é metade da solução. Após um pouco de reflexão, introduzimos as regras para a formação da loja, descrevemos sua estrutura e decidimos refatorar e pentear o código. Apesar do fato de nossa base de códigos não ser incrivelmente grande, imediatamente tropeçamos na quantidade de código que precisa ser alterada.

Enquanto os PMs pensavam sobre onde conseguir mais algumas horas do dia, houve alguns entusiastas que geraram e implementaram uma idéia simples a ponto de banalizar. Sim, idéias engenhosas, depois que surgem, sempre parecem simples. E a idéia era a seguinte: basta gerar trechos de código separados em vez de reescrevê-lo manualmente. Eu não queria usar trechos e obter folhas na saída, porque quaisquer mudanças levaram ao desastre e à refatoração repetida, rapidamente cortaram uma função que tomou alguns parâmetros como entrada e construiu redutor, ação e saga. Assim nasceu a primeira versão das comunicações ( @ axmit / redux-Communications) O nome "comunicação" nasceu de alguma forma por si só, porque essa biblioteca une as sagas e os componentes. E assim foi ...

Imediatamente depois disso, a felicidade veio. Bem, ou quase imediatamente. O tempo de desenvolvimento diminuiu cerca de 20% (conforme calculado - o tópico de um artigo separado). Primeiro de tudo, devido a uma redução significativa no número de bugs de rastreamento. E isso sem mencionar o fato de que os desenvolvedores têm muito menos probabilidade de cometer erros estúpidos por desatenção.



Linus Torvalds disse uma vez: “A conversa não vale nada. Mostre-me o código. ”E eu concordo completamente com ele. Não vou citar ou reescrever a estação ou fornecer as folhas de código aqui.Vou dar apenas um pequeno exemplo. Links para uma descrição completa da biblioteca e uma caixa de areia com exemplos também podem ser encontrados no final do artigo.

Considere uma tarefa típica - precisamos criar CRUD para alguma entidade. Tome por exemplo a tarefa. Considero inútil descrever a versão padrão, como isso ocupará muito espaço, e todo mundo que se deparou com o editor provavelmente imagina como ficará. E para obter comunicação, você precisa fazer o seguinte:

1. Descreva o transporte, sem ele em qualquer lugar

const basePath = `/api/task`;

const taskTransport = {
   add: task => axios.post(`basePath`, task).then(r => r.data),
   get: id => axios.get(`${basePath}/${id}`).then(r => r.data),
   update: task => axios.put(`${basePath}/${task.id}`, task).then(r => r.data),
   delete: id => axios.delete(`${basePath}/${id}`, task),
   getCollection: () => axios.get(basePath).then(r => r.data)
};

2. Descreva o espaço para nome do nome
const namespace = 'task';

3. Crie uma estratégia para criar comunicação
const strategy = new CRUDStrategy({
   namespace,
   transport: taskTransport
});

4. Crie comunicação
const taskCommunication = buildCommunication(strategy);

5. Conecte redutores e sagas da comunicação, como de costume
taskCommunication.reducers
taskCommunication.sagas

6. Depois disso, resta conectar o lado ao componente
taskCommunication.injector(MyComponent)

7. E comece a usar
componentDidMount() {
   const { getTaskCollection } = this.props;
   getTaskCollection();
}

render() {
   const { taskCollection } = this.props;
   return  taskCollection.data.map(item => <span>{item.title}</span>)
}

De fato, o transporte e o componente precisarão ser criados em qualquer caso, e o código de comunicação completo é o seguinte:

import { taskTransport } from './task.transport';
import { CRUDStrategy, buildCommunication, StoreBranch } from '@axmit/redux-communications';
 
const namespace = 'task';
 
const strategy = new CRUDStrategy({
   namespace,
   transport: taskTransport
});
 
export const taskCommunication = buildCommunication(strategy);


Isso é tudo o que você precisa fazer para ter um CRUD totalmente funcional. Se você precisar fazer algo mais complicado, poderá expandir a comunicação CRUD ou usar a BaseCommunication. Em um caso extremo, sob os bastidores ainda são os mesmos bons editores à moda antiga com todos os seus recursos. A flexibilidade não foi afetada. O transporte é colocado em uma camada separada e sua implementação pode ser qualquer coisa. Temos o graphQL em nossos projetos e consultas simples usando axios, e não tivemos nenhuma dificuldade nesse sentido. Um leitor atento pode ter notado que a biblioteca exporta sagas, e essa é uma de suas limitações mais significativas. Se, por algum motivo, você não puder usar sagas, esta biblioteca, infelizmente, não é adequada para você.

Porque agora?


A decisão de escrever um artigo ocorreu após a leitura deste artigo . Ao cutucar esta ferramenta, fiquei surpreso ao descobrir que as comunicações são muito mais simples, mais concisas, fornecem uma estrutura mais clara da loja e, ao mesmo tempo, não têm flexibilidade inferior. Depois de sentar e classificar uma hora com as fontes do exemplo ao redux-toolkit, eu a reescrevi para comunicação. Tentei fazer um mínimo de alterações para facilitar o rastreamento da diferença, embora, na minha opinião, a estrutura do exemplo esteja muito confusa. Deixei especificamente comentários sobre o código para facilitar a comparação de como era e como se tornou. Preste atenção nos arquivos e fatias * .communication.ts que eles substituem.



O fato de o número de linhas ser muito menor e o próprio código parecer muito mais agradável (subjetivo) não é tão importante, porque em prod temos comunicações bastante pesadas. Há mais uma diferença importante. O código é declarativo. Simplesmente determinamos o que e onde queremos obter e o que fazer com os dados e como fazê-lo - não nos importamos.
Conclusão - o redux-toolkit deve ser usado para personalização, para todo o resto existe o MasterCa ... @ axmit / redux-communication .

Resumir


  • O código se tornou consistente em todos os projetos e com todos os desenvolvedores. Problemas semelhantes são resolvidos de maneira uniforme e as soluções geralmente são entregues em pacotes separados e reutilizadas no futuro. Ao mesmo tempo, a quantidade de código diminuiu significativamente.
  • O mês de junho recebeu um fluxo claro e compreensível.
  • Os idosos se alegram por não precisarem escrever toneladas de código padronizado e estão pensando em outras formas de melhorar as comunicações.
  • A depuração foi simplificada e a estrutura da loja tornou-se simples e compreensível para todos os desenvolvedores da empresa.
  • A transição entre projetos ou diferentes partes do sistema não causa dor de cabeça.
  • Os PMs também estão felizes. O número de bugs diminuiu - os clientes estão satisfeitos. Escrever ficou mais fácil - os desenvolvedores estão felizes. O que mais o PM precisa para ser feliz?
  • Você pode passar para as comunicações gradualmente ou até usar uma abordagem híbrida (comunicações + fatias).

Obviamente, a biblioteca também tem desvantagens.

  • Sem código e documentação de amostra, é muito difícil entender isso.
  • Alterar a estrutura da loja por um arbitrário não funcionará, porque É na estrutura da loja que toda a automação se baseia. Mas vale a pena notar que em nosso trabalho nunca tivemos dificuldades com isso.
  • Você só pode trabalhar com sagas. Thunk não nos convinha, e sempre usamos sagas, então isso não é um problema para nós. Mas se, por algum motivo, as sagas não combinarem com você, você não poderá usar a biblioteca.

Espero que, apesar das deficiências existentes, nossa biblioteca seja útil para alguém. Se você tiver alguma sugestão para melhorar ou tiver dúvidas sobre o uso deles, escreva, terei prazer em discutir.
Se houver algum análogo mais legal que não possamos encontrar - me avise, nós definitivamente o estudaremos!

Uma descrição completa da biblioteca pode ser encontrada aqui e clique aqui online .

O código completo do exemplo reescrito para comunicação nas docas do ReduxToolkit está aqui , mas você pode digitar aqui .

More articles:


All Articles