Há mais de 4 anos, me apaixonei pelo
ReactJS e, desde então, desenvolvo todos os aplicativos Front-End com essa ferramenta maravilhosa. Durante esse período, eu e as equipes nas quais tive a sorte de trabalhar cometemos muitos erros, muitos dos quais foram corrigidos com sucesso. Muitas soluções ótimas foram encontradas em experimentos difíceis e caros.
Hoje, quero compartilhar os erros mais críticos e dolorosos que são cometidos com mais frequência do que outros. Antes de escrever este artigo, eu, naturalmente, estudei a Internet em busca de artigos semelhantes, e fiquei surpreso ao descobrir que a maioria deles está desatualizada e fala sobre coisas que são de pouca relevância em 2019. Então, tentei compilar uma lista dos problemas mais urgentes no momento.
1. Componentes com estado (classes) são piores que ganchos
Talvez valha a pena começar com o recurso
ReactJS mais sensacional, que apareceu na versão 16.8+. Ao contrário de algumas crenças, esse recurso foi atormentado por erros das gerações anteriores de desenvolvedores e resolve muitos problemas. Se você ainda estiver usando componentes de classe em vez de ganchos em 2019, estará cometendo um grande erro e simplesmente não entenderá qual é a vantagem deles. Eu não explicarei isso em detalhes neste artigo, fique melhor
neste maravilhoso vídeo de Den Abramov , mas eu simplesmente não poderia iniciar este artigo de outra forma
Obviamente, isso não é um erro em si, mas a abordagem de classes em comparação com ganchos é muito mais suscetível a erros, pois muitos artigos já foram escritos sobre:
- Os erros mais comuns em seu código React que você (possivelmente) comete
- Os 7 erros mais comuns que os desenvolvedores reagem
2. Usando funções anônimas como adereços
Se o primeiro erro ainda pode ser percebido como uma homenagem à moda, saber o segundo, asseguro, o salvará de noites sem dormir e dores de cabeça. Afinal, é ela quem faz o aplicativo funcionar tão inadequadamente que seus usuários podem ficar desapontados para sempre no
ReactJS . Mas queremos que os usuários o amem, assim como você e eu, certo? Para evitar esse erro, você pode usar uma regra muito simples - nunca NUNCA passe uma função anônima para o componente como adereços.
export default function MyOtherComponent() { return ( <MyComponent getValue={i => i.value} /> {/* */} ); }
Uma versão mais sofisticada desse erro pode ser algo assim (não leia se você não estiver familiarizado com o Redux):
import { connect } from 'react-redux'; import { createStructuredSelector } from 'reselect'; import MyComponent from './MyComponent'; import { fetchProjectData, projectId } from "./store/projects" const mapStateToProps = createStructuredSelector({ projectId, }); const mapDispatchToProps = { fetchProjectData, }; const mergeProps = ( { projectId, ...restState }: any, { fetchProjectData, ...restDispatch }: any, { memberId, ...restOwn }: any ) => ({ ...restState, ...restDispatch, ...restOwn, fetchProjectData: () => fetchProjectData(projectId), }); export default connect( mapStateToProps, mapDispatchToProps, mergeProps )(MyComponent);
Nos dois casos, é claro, uma função anônima entra no componente
props . Isso é ruim porque, a cada renderização do elemento pai, essa função se refere a um novo objeto na memória, o que significa que não será igual ao anterior e seu componente será renderizado com êxito desnecessariamente. Isso pode retardar tanto o desempenho do seu aplicativo que você começará a cuspir e ficará desapontado com o
React , mas o ponto principal está em FUNÇÕES ANÔNIMAS nos
acessórios . Apenas nunca faça isso - e seja feliz.
O problema é que, muitas vezes, esse erro não faz nada de errado. O código funciona para si mesmo - isso é tudo. E nada notavelmente ruim acontece. Exatamente até o momento em que você enviar novamente a chamada anônima para receber dados do servidor (segundo exemplo), entenderá a seriedade do problema. O acúmulo desses objetos anônimos, como resultado, diminuirá a sua inscrição para o nível de experiência em 1995, quando tivemos que pedir aos vizinhos que liberassem a linha telefônica para baixar a página.
Apenas algumas palavras, como escrever corretamente. Aqui está como:
const getValue = i => i.value; return default function MyOtherComponent() { return ( <MyComponent getValue={getValue} /> ); }
import { connect } from 'react-redux'; import { createStructuredSelector } from 'reselect'; import MyComponent from './MyComponent'; import { fetchProjectData, projectId } from "./store/projects" const mapStateToProps = createStructuredSelector({ projectId, }); const mapDispatchToProps = { fetchProjectData, }; export default connect( mapStateToProps, mapDispatchToProps )(MyComponent);
3. Várias instâncias de reação no aplicativo
Esse erro provavelmente está relacionado à arquitetura de todo o aplicativo como um todo, e não apenas ao ReactJS em particular. Mas esse problema prático costuma ser muito caro para desenvolvedores e muitas vezes para noites sem dormir.
Por favor, não tente empinar mais de uma instância do aplicativo React em uma página. De fato, na documentação do React não há proibição de tal abordagem, eu até cumpri recomendações para fazer exatamente isso em alguns artigos (e, é claro, eu fiz isso em meus aplicativos), MAS otimização dessa abordagem e coordenação de todas as partes do aplicativo, neste caso começa a ocupar mais da metade de todo o tempo de trabalho. Isso pode ser facilmente evitado: por exemplo, se você precisar responder a alguns eventos no código herdado em seu novo aplicativo
React , poderá usar o modelo de evento. Por exemplo, assim:
import React, { useCallback, useEffect } from 'react'; export default function MyComponent() { const reactHandlerOfLegacyEvent = useCallback((event) => {}, []); useEffect(() => { document.addEventListener("myLegacyEvent", reactHandlerOfLegacyEvent); return () => { document.removeEventListener("myLegacyEvent", reactHandlerOfLegacyEvent); }; }, [reactHandlerOfLegacyEvent]); return ({}); }
4. Escrevendo suas próprias bibliotecas, em vez de código aberto existente
Esse problema não é sobre o
ReactJS , mas sobre todo o desenvolvimento. É claro que, enquanto você está apenas aprendendo, escrever um grande número de suas próprias bibliotecas permitirá que você cresça mais rápido e fique maior, mas se você quer estar na vanguarda da programação, deve pelo menos tentar cada uma das bibliotecas de código aberto que resolvem seus problemas. Basta perguntar aos robôs de pesquisa se existem bibliotecas que resolvam o seu problema - eles podem responder a essas perguntas perfeitamente.
Não vou dar um exemplo de bibliotecas que eu mesmo uso, porque Eu sei que metade deles se tornará obsoleto em alguns meses e outros virão em seu lugar. E, ao que parece, isso contradiz a afirmação original. E realmente, por que usar bibliotecas que se tornam obsoletas em alguns meses? A resposta é muito simples - você pode ver a solução para os problemas que ainda não surgiram antes de você. Você pode melhorar as práticas existentes ou entender como resolver o problema muito melhor com o exemplo de problemas nas bibliotecas existentes. Isso só pode ser feito interagindo com o mundo do desenvolvimento através do uso de bibliotecas de código aberto.
5. Medo de usar o código de outra pessoa
Como o erro anterior, isso não é
exclusivo dos aplicativos
ReactJS , mas é bastante comum neles. Com que frequência vejo como um grande junho corajosamente entra em batalha e reescreve partes do código que funcionam muito bem e que não têm problemas, apenas porque leram sobre um dos quatro erros anteriores. Eu próprio era assim. Mas o que há para trapacear, eu freqüentemente perco tempo agora, simplesmente porque movimento é vida.
Mas também aprendi a entender outros desenvolvedores, seus pensamentos e problemas que eles encontraram. Veja quanto tempo e esforço foram gastos (e não em vão) na solução de problemas. Em 3 casos em 5, quando tento "melhorar" o código de outra pessoa, obtenho quase o mesmo resultado que obtive. Só porque no início de uma tarefa, você geralmente não vê todos os problemas que estão à frente no futuro. Então, agora eu respeito o código de outra pessoa, não importa o quão estranho e "desatualizado" me pareça. O que eu aconselho.
Obrigada
Obrigado por ler este artigo e todos aqueles com quem tenho a sorte de trabalhar juntos. Agradecemos a nós por tornar nosso mundo mais interessante e avançar. Não deixe sempre certo, nem sempre habilmente, mas mova-se.
Escreva sobre os problemas encontrados nos comentários. Talvez você tenha soluções para os problemas descritos neste artigo que eu perdi (tenho certeza que sim). Todo o sucesso e bom humor!