Como Estruturar o seu Front-End com Angular
Estruturar o workspace é uma das partes mais complicadas quando iniciamos um projeto. Eis aqui um guia pra te ajudar nessa tarefa.
Enquanto alguns o chamam de Framework, o Angular pode ser considerado uma grande plataforma, que te fornece todas as ferramentas necessárias para o desenvolvimento de aplicações Front-End. Além disso, tem um CLI super poderoso em que podemos adicionar infinitas funcionalidades via Schematics.
O Angular já possui um Style Guide com padrões bem definidos. Porém, ainda há bastante coisa pra acrescentar, e é dessas coisas que vamos falar aqui:
Nx = ❤
Eu falo bastante do Nx porque ele reduz e muito o tempo que você demora estruturando o projeto do zero. Ele foi criado por dois caras que eram da Google (Victor Savkin e Jeff Cross) e trabalham ativamente no projeto do Angular. Desde então eles prestam consultoria ensinando metodologias de desenvolvimento para aplicações de grande porte. Resumindo: Eles sacam muito de Angular.
Monorepo
Utilizar um único repositório tem tantas vantagens que cabe num segundo artigo. Aqui eu vou destacar a integração instantânea entre diferentes aplicações e a facilidade de geração de releases.
O Angular já vem com um monorepo padrão, mas ele é um tanto limitado e acaba misturando bibliotecas com aplicações. O Nx resolve isso dividindo o workspace em 3 áreas: apps ou aplicações, libs ou bibliotecas e tools que são ferramentas para facilitar o fluxo de desenvolvimento.
Programação reativa
O Angular usa RxJS para implementar o padrão Observer. Nele, temos um stream de vários eventos que podem ser manipulados como se estivéssemos manipulando um array.
Se você usa Promises, como basicamente tudo no Angular usa RxJS, a recomendação é que você o aprenda e utilize ao invés de usar .toPromise() na sua aplicação inteira. Ele é bem mais poderoso e tem inúmeros operadores, então vale muito a pena investir.
Por onde começar:
- RxJS: Programação reativa em JavaScript
- Por que programação reativa?
- Learn RxJS
- RxJS Marbles: Interactive diagrams of Rx Observables
Faça micro frontends
Divida a sua aplicação em micro aplicações, para que você possa evoluí-las sem que uma interfira na outra, e distribuí-las sem precisar fazer o deploy de todo o seu front-end caso você altere apenas uma pequena parte da sua aplicação. Tente identificar as diferentes aplicações que você irá desenvolver e as divida no Workspace.
Crie bibliotecas
Identifique aquilo que é compartilhado entre aplicações e organize em bibliotecas. No meu time de produto da TOTVS, nosso Workspace tem uma biblioteca de componentes de UI, uma biblioteca que contém tudo o que é comum para todas as aplicações (internacionalização, autenticação e uma série de interceptors), uma biblioteca pra cada micro serviço contendo os models e os services com as requisições REST, entre outras.
Quando criamos uma biblioteca com o Nx, ele faz as configurações de TypeScript necessárias para que ela esteja disponível para todo o workspace.
Use gerenciamento de estado
Fazer a comunicação entre diferentes componentes nem sempre é uma tarefa fácil, e você vai acabar se perdendo entre vários services e @Inputs/@Outputs quando precisar atualizar o estado da sua aplicação. A galera do React fez isso muito bem com o Redux, e o NgRx trouxe esse conceito pro Angular com o nosso amado RxJS.
Segue alguns links que podem te ajudar nessa jornada:
- Máquinas de estado, quando usar e para que?
- Construindo aplicações front-end reativas com NgRx
- Gerenciamento de estado no Angular com NgRx e programação reativa
- State Management With NgRx
Schematics
Muitas das coisas que fazemos são repetitivas e podem ser automatizadas. Por meio do Schematics, conseguimos estender o CLI do Angular com comandos personalizados que gerem ou alterem código de acordo com nossos padrões internos. Você pode aprender mais sobre eles nesse artigo.
Builds com Affected
Uma das ferramentas que eu mais gosto no Nx é o affected, que consegue mapear quais aplicações ou bibliotecas foram afetadas pelas alterações comparando a sua branch com a master (ou dev), ou dois commits diferentes (como a HEAD vs o commit anterior). Com ele, podemos gerar builds mais rápidos e precisos recompilando somente o que precisa ser recompilado. O affected também pode ser usado em testes, lints, etc.
Conclusão
Usar o Nx para estruturar uma aplicação pode te poupar bastante dor de cabeça e trabalho configurando o Workspace. Separar suas aplicações em pedaços menores vai te ajudar lá na frente quando você precisar dividir a manutenção delas. Gerenciar o estado e usar programação reativa são duas coisas que ajudam bastante a reduzir a complexidade dos componentes e o Schematics é uma ferramenta super flexível pra ajudar o seu time a escrever menos código repetitivo. O affected fala por si só.
Se houver qualquer coisa que eu possa fazer pra tornar esse artigo melhor, comente ou envie uma mensagem privada. Feedbacks são sempre super bem vindos.
