Padrões de outras linguagens e estruturas para aprimorar seus projetos de front-end

Eu programo há doze anos e já trabalhei com várias linguagens. Isso inclui C , C++ , Java , Python , C# e, finalmente, JavaScript . Cada linguagem ou estrutura tem suas próprias regras. Por exemplo, Rust usa snake-case para nomes de função.

No entanto, existem certas regras, ferramentas e padrões que aprendi a apreciar. Eu os incorporo em meus aplicativos de front-end. Essas regras apenas ressoam mais comigo e tornam a codificação um processo mais suave. Aqui estão alguns que eu particularmente gosto:

Programação Funcional

Minha primeira dica vem do C, a primeira linguagem que aprendi. Lembra quando costumávamos escrever React com classes ? Só de pensar nisso me dá calafrios. Quando o React mudou para componentes funcionais, tornou o código não apenas mais fácil de ler, mas também mais fácil de testar.

Ele também se alinha melhor com os princípios da Programação Funcional.

Essa abordagem funciona muito bem com estruturas de front-end porque geralmente se concentram na criação de trechos de código reutilizáveis. Usar Programação Funcional no desenvolvimento de front-end sempre foi uma estratégia útil para entender esse conceito e também para criar novos recursos de front-end.

Seguir os princípios da Programação Funcional é um item obrigatório em todos os meus aplicativos de front-end.

Se você não estiver familiarizado com a Programação Funcional, recomendo explorá-la ainda mais . Este ponto não está no início desta lista sem motivo. Os benefícios que isso pode trazer para o seu processo de desenvolvimento são substanciais.

Formatadores de código

Quando comecei a programar, não prestei muita atenção à formatação do código. Acho que tudo começou na universidade, onde eu estava aprendendo C++ no meu legal CodeBlocks IDE com um tema branco.

Olhando para o meu código antigo de 2016 no GitHub , posso ver que usei apenas espaços para formatação. Não usei nenhuma ferramenta para cuidar disso automaticamente.

Agora, percebo que foi um erro. Se você pode automatizar algo em seu projeto, você definitivamente deveria. Agora, eu sempre configuro o Prettier e o ESLint no início de cada projeto. Se você não quer perder muito tempo com isso, pode usar configurações pré-fabricadas como a do Airbnb .

Confie em mim, você não vai se arrepender!

Ah, e não se esqueça de configurar em seu IDE uma ação de autoformatação ao salvar arquivo!

Ações de pré-confirmação

Agora que você tem formatadores incríveis, vamos automatizá-los! Não me lembro bem quando comecei a usar ganchos de pré-confirmação, mas eles têm sido uma grande ajuda em meus projetos. Por que formatar manualmente quando pode ser automatizado antes de cada confirmação? Ferramentas como husky e lint-stage tornam essa automação possível.

Kebab-case para nomes de arquivos

Embora o Angular tenha muitos fãs e críticos, gosto de focar no positivo. Angular costuma ser a primeira escolha para grandes empresas e grandes aplicativos. Acho que muitas das decisões tomadas no Angular foram feitas para manter as coisas fáceis de manter.

É por isso que decidi usar kebab-case para todos os meus projetos de front-end. Ele oferece alguns benefícios, como:

• Simplicidade : não preciso me preocupar se uso pascal-case, camel-case ou snake-case (se preferir). Com kebab-case, há apenas uma opção.

• Consistência : se você estiver trabalhando em equipe, adotar uma única convenção de nomenclatura, como kebab-case, pode ajudar a garantir que todos estejam na mesma página e que o projeto permaneça organizado. Não esqueça que você pode forçar o uso do kebab-case via regra eslint usando o pacote unicorn :

 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ],

• Compatibilidade entre plataformas : diferentes sistemas operacionais lidam com nomes de arquivos de maneira diferente. Por exemplo, o Windows não se importa com letras maiúsculas, mas o Linux sim. Ao usar kebab-case, que usa letras minúsculas e hífens, evito problemas.

• Sem problemas com o git : há um problema ao renomear um arquivo de minúsculas para maiúsculas no git. Usando kebab-case, não preciso me preocupar com isso.

Eu gosto de manter as coisas simples. Se eu puder tornar minha vida mais fácil e obter alguns benefícios com isso, sou totalmente a favor.

Usando tags para tipos de arquivo

Outra coisa que peguei emprestado do Angular é como eles nomeiam os arquivos. Angular recomenda nomear arquivos de uma forma que reflita sua função e tipo. Acho que fica mais fácil para mim navegar e entender a estrutura de um projeto. No Angular, o nome do arquivo geralmente possui três partes: a área do recurso, a função do arquivo e o tipo de arquivo.

Por exemplo, heroes.component.ts mostra que o arquivo é um componente para o recurso heroes e é um arquivo TypeScript. heroes.service.ts é um serviço para heroes .

Não sou um grande fã de services , mas uso uma estrutura semelhante para meus componentes React. Aqui está um exemplo:

 my-component ├── my-component.component.tsx ├── my-component.type.ts ├── my-component.style.css ├── my-component.spec.tsx └── my-component.story.mdx

Eu também uso esse padrão para meus hooks e funções. Esse padrão também me ensina a colocar meus testes próximos aos arquivos relacionados a eles.

Automatizar geração de código

O padrão que mencionei antes é muito útil, mas podemos torná-lo ainda melhor com a automação. Angular CLI permite que os usuários gerem código automaticamente, e eu sempre uso plop para fazer o mesmo. O sistema de modelo do Plop é muito poderoso, mas o mais importante, economiza tempo.

Com a automação, não preciso gastar muito tempo pensando na estrutura básica de um componente. Essa tarefa pode ser automatizada, o que me permite focar no que realmente quero fazer.

Usando um 'Domínio'

Não vou explicar o que é um domain em detalhes aqui. Se quiser saber mais sobre o assunto, recomendo a leitura deste artigo . No momento, estou trabalhando com uma equipe de desenvolvedores full-stack e descobrimos que ter uma camada de domínio em nosso projeto de front-end é realmente útil.

É onde colocamos todos os nossos principais tipos e operações. Ele serve como a 'fonte da verdade' em nosso aplicativo.

Se você quiser ver como eu lido com 'domínios' em meus aplicativos, você pode conferir este artigo . Eu gasto muito tempo descrevendo este tópico.

Testando sua arquitetura

Em nosso trabalho com Kotlin , certa vez encontramos um problema em que a lógica se misturava em várias camadas, como usar um tipo definido no repositório dentro de nosso domínio. Isso é proibido do ponto de vista da Arquitetura Limpa, mas todo mundo comete erros.

Foi quando descobrimos o ArchUnit , uma ferramenta para testar a unidade de nossa arquitetura. Basicamente verifica se estamos aderindo corretamente à nossa arquitetura.

Se você está mantendo uma determinada arquitetura, pode ser útil ter uma ferramenta para verificar se ela não foi quebrada em algum momento. Uma ferramenta como o dependency-cruiser pode ser inestimável a esse respeito.

E isso conclui minha lista essencial de padrões de outras linguagens e estruturas para aprimorar seus projetos de front-end. Espero que você tenha achado esta informação útil e que pelo menos uma dessas estratégias tenha inspirado você a implementá-la em seu próprio trabalho!