React: Como escalar uma aplicação - 3 dicas muito importantes

Eu vou te contar quais foram os principais gargalos que encontrei trabalhando com frontend e seu cérebro vai EXPLODIR!
E ainda vou mostrar as técnicas que encontrei para tentar resolver esses gargalos.

Eu separei também uma dica extra no final que é simplesmente FUNDAMENTAL! :)

Eu já tenho as ideias prontas para compartilhar com você, mas vou dividir este texto em três partes para que seja mais fácil de compreender e também de escrever. Vamos tornar tudo mais tranquilo e organizado!
(Ou tentar)

Quando você escreve componentes React para o trabalho, na maioria das vezes está em uma correria. Vamos ser sinceros, hoje em dia, existe uma boa chance de estar trabalhando em um ambiente onde a equipe de produto, ou de forma mais geral, seu líder, não conhece as falhas e dificuldades do sistema, em um nível técnico mesmo.

Então, não é surpresa quando chega aquele card no Jira ou no Trello com uma feature que aparenta simplicidade, mas no final gera muito retrabalho ou é simplesmente inviável no momento.

Esse cenário é frustrante tanto para os desenvolvedores quanto para os outros membros do time, ou para a empresa em geral, e com isso definitivamente não estou trazendo nenhuma novidade.

Além disso, ao lidar com projetos React, existe um grande ponto a ser considerado desde o início ao escolher a tecnologia preferida para escrever um aplicativo. Às vezes, dependendo de onde e como você quer chegar, principalmente se for algo grande e específico, pode valer mais a pena aprender uma nova e eficiente tecnologia do zero e evoluir a partir disso, em vez de tentar aplicar o que você já está acostumado.

O React apresenta um “problema”:
Você pode fazer do seu jeito, de qualquer forma, sem seguir nenhum método, sem consultar referências e, às vezes, até sem documentação. Você precisa apenas confiar no seu instinto e no que ele diz para ser feito, com base nos seus projetos e experiências anteriores.

Claro, isso é muito poderoso se aplicado corretamente, mas traz uma ressalva: o projeto pode se tornar “Amebóide”, que é como chamamos aqui onde eu trabalho.

Com essa liberdade, quero dizer que você pode criar componentes do tamanho e complexidade que desejar, em uma arquitetura de arquivos e pastas definida sem critérios, com falta de tipagem, documentação ou testes, e assim por diante.

É claro que, de modo geral, o desenvolvimento de software pode ser assim, mas especialmente com o React, não estou dizendo coisas genéricas. Quando comparado a outras tecnologias como Angular ou Vue, temos mais definições, mais contratos, mais guias. Afinal, o Angular é mais um Framework, e parte do que significa ser um Framework é ter regras e orientações para produzir resultados esperados com maior facilidade. Além disso, embora o Vue esteja se tornando mais genérico e semelhante ao React em alguns aspectos, ainda precisamos discutir sobre isso quando escolhemos o React para nossos projetos.

Então, chega de enrolação, quais são as dicas?

Primeira dica:

• Precisamos falar sobre densidade.

De todos os problemas, esse é cruel!

Já abriu um projeto e se deparou com arquivos com mais de 500 linhas?
E projetos com arquivos de 100 linhas, mas que fazem de tudo? Como aquele componente de um calendário que implementa arrastar e soltar, esticar, mover, com animações, muitos estados e muitos eventos para controlar, tudo no mesmo componente.
Citei esse exemplo porque, infelizmente, tentei fazer essa proeza e passei um mês inteiro tentando entender um bug.

Como eu disse, eu tentei... Só mesmo... Sem êxito… :(

Mas voltando ao que importa, vamos ser honestos: Menos linhas significam menos tempo gasto tentando entender o que o código faz, ou melhor, como ele faz. Afinal, precisamos entender isso, pois escrevemos esse código há um ano e agora a equipe de produto está solicitando que adicionemos a funcionalidade de arrastar e soltar no dispositivo móvel (algo bastante desafiador em termos de usabilidade), então teremos que fazer modificações.

A densidade não se aplica apenas ao número de linhas, mas principalmente a uma coisa: a quantidade de funcionalidades que estão presentes em um único espaço de arquivo. Precisamos de componentes mais atômicos, mais isolados em termos de regras de negócio.

Tente escrever uma única funcionalidade por componente. Afinal, é para isso que utilizamos a definição de componente!
Aqui está como solucionamos esse problema por aqui:

Com cápsulas! Não, não estou falando de remédios para dor de cabeça, mas sim de encapsulamento.

Os exemplos aqui estão em TypeScript, mas isso também se aplica caso não esteja sendo utilizado.

Adotamos como padrão que um componente seja representado por uma pasta, que contém um arquivo index.ts que exporta o próprio componente como padrão. Caso o componente precise exportar outras coisas, como tipos, constantes ou até mesmo componentes secundários exclusivos desse componente, também exportamos tudo através do index.ts.

Isso encapsula tudo o que esse componente precisa para funcionar corretamente dentro de uma única pasta. Além disso, ao exportar tudo do mesmo arquivo, podemos escolher permitir a importação apenas do que realmente deve ser importado, evitando expor detalhes internos do componente. Isso garante que quem está reutilizando o componente importe apenas o necessário.

Além disso, caso esse componente precise ser dividido em subpartes exclusivas, essas partes podem ser escritas dentro da pasta principal. Como essas partes também são componentes, elas ficam em suas próprias pastas, isoladas na estrutura.

Se houver funcionalidades comuns entre essas partes que possam ser reaproveitadas, elas podem ser escritas em uma pasta dedicada para reutilização dentro desse componente principal.

Vou escolher um dos componentes mais complexos de um dos meus projetos para exemplificar, mas claro, vai ficar mais claro do que esse texto meu aí de cima:

Aqui está o link para o artigo completo no Medium, onde eu continuo com as dicas e ainda anexei imagens para te ajudar com a trefa de entender esse texto :)