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 , , , , e, finalmente, . Cada linguagem ou estrutura tem suas próprias regras. Por exemplo, usa para nomes de função. C C++ Java Python C# JavaScript Rust snake-case 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 ? 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. React com classes 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 . 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. ainda mais 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 com um tema branco. CodeBlocks IDE Olhando para , posso ver que usei apenas espaços para formatação. Não usei nenhuma ferramenta para cuidar disso automaticamente. o meu código antigo de 2016 no GitHub Agora, percebo que foi um erro. Se você pode automatizar algo em seu projeto, você definitivamente deveria. Agora, eu sempre configuro e 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 . o Prettier o ESLint 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 e tornam essa automação possível. husky lint-stage Kebab-case para nomes de arquivos Embora 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. o Angular É por isso que decidi usar kebab-case para todos os meus projetos de front-end. Ele oferece alguns benefícios, como: : não preciso me preocupar se uso pascal-case, camel-case ou snake-case (se preferir). Com kebab-case, há apenas uma opção. Simplicidade : 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 : Consistência unicorn 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ], : 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. Compatibilidade entre plataformas : 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. Sem problemas com o git 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, mostra que o arquivo é um componente para o recurso e é um arquivo TypeScript. é um serviço para . heroes.component.ts heroes heroes.service.ts heroes Não sou um grande fã de , mas uso uma estrutura semelhante para meus componentes React. Aqui está um exemplo: services 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. automaticamente, e eu sempre uso para fazer o mesmo. O sistema de modelo do Plop é muito poderoso, mas o mais importante, economiza tempo. Angular CLI permite que os usuários gerem código plop 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 em detalhes aqui. Se quiser saber mais sobre o assunto, recomendo a leitura . No momento, estou trabalhando com uma equipe de desenvolvedores full-stack e descobrimos que ter uma camada em nosso projeto de front-end é realmente útil. domain deste artigo de domínio É 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 . Eu gasto muito tempo descrevendo este tópico. este artigo Testando sua arquitetura Em nosso trabalho com , 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. Kotlin Foi quando descobrimos , uma ferramenta para testar a unidade de nossa arquitetura. Basicamente verifica se estamos aderindo corretamente à nossa arquitetura. o ArchUnit 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 pode ser inestimável a esse respeito. o dependency-cruiser 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!