🛬 🤽🏿 👨🏽‍⚕️ 6 conceitos que um arquiteto de aplicativo Angular precisa dominar ✋🏿 👨🏾‍🤝‍👨🏽 📓

Angular é um dos maiores frameworks web existentes. Inclui muitos recursos internos. E isso significa que, para o desenvolvimento completo do Angular, você precisa lidar com uma quantidade razoável de conceitos. O autor do material, cuja tradução publicamos hoje, acredita que existem seis conceitos que os desenvolvedores Angular precisam ter conhecimento profundo para criar aplicativos bem projetados. No entanto, ele não está falando sobre o estudo do código fonte para a implementação desses conceitos, embora ele próprio às vezes precise pesquisar o código. Trata-se de entender os mecanismos relevantes e a capacidade de colocá-los em prática.

1. Arquitetura, módulos e bibliotecas

No mundo do desenvolvimento web, a arquitetura modular da Angular é algo especial. Provavelmente, essa é uma daquelas idéias piores que outras adotadas pelos iniciantes.

A parte mais difícil aqui é que o desenvolvimento web já usa uma arquitetura modular. Claro, estou falando de importações do ES6.

Como os módulos angulares adicionam um nível adicional de agrupamento lógico ao sistema, é importante que sua estrutura, tanto quanto possível, corresponda às tarefas resolvidas com sua ajuda.

Saber separar e combinar a funcionalidade do aplicativo usando módulos bem projetados é uma parte fundamental da criação de uma arquitetura de aplicativo Angular.

TypesVários tipos de módulos angulares

Existem vários tipos de módulos angulares para conhecer:

Módulo Declarações / Widget. Módulos com declarações de várias entidades. Um exemplo desses módulos é o conjunto de componentes da interface do usuário, diretivas e tubulações.
Módulo de Serviços. Módulos de Serviço Por exemplo - HttpClientModule.
Módulo de roteamento. Módulos de roteamento
Módulo de Recurso de Domínio. Módulos que implementam as principais tarefas do aplicativo.
Módulo principal / compartilhado. Um módulo principal é um módulo para declarar serviços globais. Um módulo compartilhado é um módulo no qual os componentes são declarados para compartilhamento.

Aqui está o material onde você pode encontrar detalhes sobre os módulos angulares.

▍ Biblioteca ou módulo?

Eu diria que a distinção acima entre módulos pode ser estendida às bibliotecas. Com essa abordagem, verifica-se que pode haver uma biblioteca contendo apenas serviços, uma biblioteca que representa a rota e assim por diante.

Mas se um módulo ou biblioteca é criado depende do tipo de projeto e se o projeto é representado por um repositório mono ou vários repositórios.

▍ Perguntas a serem feitas antes de criar um módulo

Aqui estão algumas perguntas a serem feitas antes de escrever um módulo:

? — , . , . , .
, ? . , , . , , .

2. ,

Compartilhar responsabilidades é, em teoria, simples. Mas na prática já é mais difícil. Os desenvolvedores, desde a época do Angular.js, sabiam que os componentes deveriam ser feitos o mais compactos possível e os serviços, maiores. Nas novas versões do Angular, essas idéias não mudaram muito.

Atualmente, é importante ter uma idéia do que exatamente deve fazer parte dos componentes, do que faz parte dos serviços e também levar em conta o fato de que as diretivas são provavelmente um recurso muito subestimado do Angular.

▍Condição

A resposta para a pergunta exata de onde armazenar o estado do componente depende de onde os dados correspondentes são necessários. Ou seja, eles podem ser necessários apenas no componente, sendo local e encapsulado, ou podem ser necessários fora do componente.

Se os componentes compartilharem o estado ou o estado precisar ser acessado pelos serviços, o estado deverá ser armazenado no serviço. Além disso, se o estado estiver armazenado no serviço, quais ferramentas específicas de gerenciamento de estado são usadas não desempenham um papel especial.
Se o estado for local (por exemplo, estamos falando sobre o formulário) e for usado apenas dentro do componente, o estado deverá ser simplesmente salvo no componente.

OrkTrabalhando com o DOM

Provavelmente, a maioria das manipulações de DOM deve ser feita em diretivas. Imagine que um dos componentes esteja equipado com a funcionalidade Arrastar e Soltar.

Estou certo de que, nessa situação, você pode criar um componente e vincular os eventos correspondentes a partir dele, mas, se fizer isso, dois fenômenos serão misturados:

Descrição da aparência do componente.
Determinação do comportamento do componente.

As diretivas são um recurso angular que permite descrever mecanismos reutilizáveis. Em quase todos os projetos em que trabalhei, notei o uso insuficiente de diretivas. As diretivas podem ter uma parcela considerável da responsabilidade dos componentes.

Aqui está um exercício para você: encontre o maior componente em seu projeto atual pelo número de linhas de código. É usado nele Rendererou ElementRef? A lógica correspondente, provavelmente, pode ser transferida para a diretiva.

3. Detecção e renderização de alterações

Quando se trata de renderizar novamente a interface do usuário, em Angular, tudo é feito como que por mágica, usando os mecanismos internos da estrutura.

Porém, se você precisar otimizar o aplicativo para que a interface seja renderizada novamente novamente apenas quando necessário, você deverá lidar com essa “mágica”. E, melhorando a renderização, você precisa confiar não apenas no conhecimento, mas também na intuição.

Um arquiteto de aplicativo Angular provavelmente deve estar ciente de que uma estratégia de detecção de alterações é usada para otimizar o desempenho da renderização onPush. Mas, no decorrer do trabalho, nem sempre tudo corre como o esperado. Especialmente quando os modelos não usam objetos observáveis e tubos assíncronos.

▍ Melhorando a detecção de alterações

Para melhorar o processo de detecção de alterações usado no projeto, faz sentido começar com as seguintes idéias:

É necessário considerar todos os dados como imutáveis. As bibliotecas de gerenciamento de estado baseadas em Rx podem ser muito úteis aqui.
Para gerar dados em modelos, vale a pena usar apenas (ou principalmente) objetos observáveis. Ao usar um estado local, vale a pena aplicar BehaviorSubject.

Se você deseja desenvolver aplicativos Angular de alto desempenho, basta lidar muito bem com problemas de detecção de alterações. O fato é que o alto desempenho nem sequer está “atualizando a interface quando necessário”. Isso é "atualizar a interface apenas quando necessário".

▍ Superando limitações de desempenho angular

Reduzir o número de re-renderizações da interface do aplicativo é um dos segredos que permite criar aplicativos rápidos e eficientes. Mas, às vezes, o desempenho do aplicativo deve ir além dos limites definidos pelo próprio dispositivo Angular. Entre esses aplicativos, destacam-se jogos, projetos cujos dados são atualizados com frequência, páginas que exibem listas grandes e complexas e assim por diante.

Se você realmente precisa extrair o máximo do desempenho Angular, isso significa que você deve recorrer a uma técnica que envolve a eliminação do Zone.js e a atualização precisa da interface, usando os recursos mais recentes do Ivy. Aqui está o material sobre isso.

4. Roteamento

O roteamento não é apenas uma representação do SPA na forma de muitas páginas virtuais. Também está carregando pacotes de aplicativos sob demanda usando os recursos de carregamento lento dos materiais do subsistema de roteamento angular.

Se você estiver trabalhando em um aplicativo grande e o tamanho do pacote configurável exceder 1 MB, provavelmente já deve saber por que isso é importante. De fato, ninguém encontrará a perspectiva de baixar grandes quantidades de dados para trabalhar com um determinado aplicativo.

O roteamento deve ser usado não apenas para separar as rotas de nível superior, mas também para organizar o trabalho com as partes mais rasas e profundas da interface.

Isso permite que você divida o conteúdo dos pacotes configuráveis pelas rotas principais e ajuda a dividir os aplicativos em pequenas partes que não precisam ser transferidas para os usuários até que uma solicitação explícita seja feita para fazer o download deles.

▍ Exemplo: componente com guias

Suponha que estamos desenvolvendo uma interface de usuário que use guias. Além disso, cada guia é independente das outras. Essa é uma situação ideal em que cada guia pode ser atribuída à sua própria rota e organizar o carregamento lento de dados, durante o qual apenas os dados da guia selecionada são transmitidos ao cliente.

Quer outro exemplo? E quanto a pop-ups e janelas modais? Seu código absolutamente não precisa ser incluído nos materiais incluídos no pacote original do projeto. O código dessas janelas faz sentido carregar somente quando elas são necessárias, mas não antes.

Se você deseja algo inspirado antes de aplicar essas idéias, sugiro dar uma olhada na documentação do componente @ angular / material / tabs , que implementa o padrão acima.

5. Formulários

A maioria dos aplicativos CRUD é composta essencialmente de várias formas. É muito provável que você gaste muito tempo criando formulários. Portanto, é importante que alguém que queira ser um arquiteto Angular domine o trabalho com formulários corretamente.

É provável que a maioria dos seus formulários use um módulo ReactiveFormsModule. E se eles não consistirem em um único controle, então, usando-os, ngModela ligação de dados bidirecional será implementada.

A API Angular para trabalhar com formulários é muito fácil de aprender. Para alcançar a excelência no uso dessa API, em geral, basta estudar adequadamente a documentação e saber quais problemas podem surgir ao trabalhar com formulários.

O principal problema que vale a pena conhecer é que os formulários em Angular não estão vinculados aos tipos de dados subjacentes a eles. Essa é provavelmente a coisa mais desagradável de se trabalhar com mecanismos que, de outra forma, são muito bem feitos. Como resultado, verifica-se que o desenvolvedor precisa monitorar cuidadosamente se os formulários correspondem às estruturas de dados usadas ao trabalhar com eles.

6. RxJS

E o último da nossa lista, embora não menos importante, é a tecnologia RxJS.

Estou convencido de que um dos recursos mais poderosos do Angular é a profunda integração dessa estrutura com o Rx e a programação reativa funcional.

Para dominar verdadeiramente o Angular, abrindo caminho para o design de aplicativos de alta qualidade, você primeiro precisa estudar o Rx, ou pelo menos os operadores mais importantes. É difícil ser um desenvolvedor Angular verdadeiramente avançado sem gastar muitas horas entendendo o Rx.

Há duas razões para aprender o Rx para ajudá-lo a desenvolver aplicativos Angular: desempenho e processamento de dados assíncrono.

O processamento de dados assíncrono é uma tarefa particularmente difícil em aplicativos modernos e altamente interativos. Portanto, você deve esquecer as promessas, oh setTimeoute oh setInterval, e começar a trabalhar no estilo Rx.

Outro motivo sério para aprender Rx é otimizar o desempenho do aplicativo. Obviamente, para começar, basta usar tubos assíncronos, mas às vezes isso não é suficiente. Por exemplo, você pode controlar a nova renderização de componentes passando apenas esses eventos pelo canal, cuja ocorrência implica a necessidade de nova renderização.

O Rx fornece ao desenvolvedor muitos operadores que podem ajudá-lo a armazenar em cache algo ou criar algo em pacotes. E isso, como resultado, leva ao desempenho otimizado do aplicativo. Aqui material sobre os padrões RxJS.

Sumário

Forneci aqui uma pequena lista de tópicos que vale a pena explorar para alguém que deseja se tornar um desenvolvedor Angular de alto desempenho ou alguém que deseja ser um arquiteto de aplicativos Angular.

Você pode adicionar muito mais a esta lista. Mas, entre outras coisas, proponho não esquecer que, para realmente aprender algo sobre o mundo do desenvolvimento web, você precisa começar com o básico. Estes são JavaScript, CSS, padrões de design, técnicas de escrita de código limpo, ferramentas e muito mais.

E o que você recomendaria estudar para quem deseja aprender como projetar aplicativos Angular de alta qualidade?

6 conceitos que um arquiteto de aplicativo Angular precisa dominar