Para aqueles que, durante o longo fim de semana, estão prontos não apenas para comer churrasco, mas também para ler todos os tipos de textos necessários, coletei dez links de maio no canal de desenvolvedores do Vimbox no Skyeng Slack corporativo. Como da última vez, a coleção está concentrada em torno da estrutura Angular e será interessante para os programadores que trabalham com ela.
Uma excelente análise do próximo renderizador Ivy: ele descreve em termos gerais por que ele é feito e como funciona por dentro.
“Antes de entrarmos nos detalhes da execução, gostaria de dedicar alguns parágrafos à resposta à pergunta que sempre surge na minha cabeça sobre quaisquer alterações. Esta é a eterna pergunta: por quê?
Detalhes sobre o conceito mencionado no artigo DOM Incremental implementado no renderizador Ivy e suas diferenças em relação ao Virtual DOM - neste artigo .
Bem, para aqueles que estão completamente entediados - o documento oficial de design para o compilador Ivy .
Outra mini-revisão do renderizador Ivy com gifs sobre o trabalho de detecção de alterações / ganchos de ciclo ativo, mostrados pela estrutura de objetos internos e uma demonstração em que você pode senti-lo com as mãos.
Um momento divertido do artigo:
Uma breve observação sobre por que o takeUntil deve sempre ser o último.
Qual é o problema?
Se o operador takeUntil estiver localizado na frente do operador que está criando a nova assinatura, ao receber a notificação de cancelamento de assinatura no takeUntil esse operador não cancelará a assinatura e continuará a trabalhar. ”
Fazendo animações com o RxJS
“Sempre que você encontra um problema no qual o tempo e a assincronia desempenham um papel, o pensamento reativo associado a bibliotecas reativas como o RxJS o levará a uma solução mais simples e confiável. Nesse mundo de conexões constantes, nuvens, plataformas e microsserviços sem bloqueio, tempo e assincronia desempenharão um papel cada vez mais importante. ”
Por que vale a pena usar apenas ReactiveForms e esquecer todos os tipos de ngModel. Brevemente e direto ao ponto.
"Por que não usar os dois?"
Eu tenho quatro razões:
1. Desenvolvimento difícil.
2. Teremos que carregar os dois, e o pacote se tornará um pouco mais.
3. Não podemos prever o que o desenvolvedor escolherá, portanto, será mais difícil processar solicitações pull.
4. Na minha opinião, sempre faz sentido aderir a um paradigma se não houver razões sérias para não fazê-lo. ”
Anatomia da superfície suficiente em @angular/router ou o que acontece ao navegar.
“Neste artigo, aprendemos o que o roteador Angular faz quando um usuário navega de uma página para outra.
Você pode usar os mnemônicos PRIGRAM :
Bunda
R edirect
Eu dentifico
G uard
Esolve
Um ativo
Manage
para lembrar a ordem dos passos dados pelo roteador Angular.
Conhecer esse processo permitirá entender melhor o que está acontecendo nos bastidores e ajudar a curar possíveis problemas com o roteamento. ”
Uma história sobre como as diferenças são organizadas em Angular pelo exemplo de escrever suas próprias.
“Diferenças angulares são talvez as APIs menos conhecidas; estes são blocos altamente otimizados usados pelo próprio Angular dentro da estrutura (ngClass, ngStyle, ngFor, etc.).
Você definitivamente não os usará diariamente, mas eles podem ser muito úteis sob certas condições. Se você alguma vez disse a si mesmo: "Não basta que eu saiba que algo mudou, preciso saber exatamente o que mudou", Diferentes angulares fornecerão uma resposta.
Um exemplo simples de como obter rapidamente @angular/elements com uma configuração simples do webpack para montagem.
“Observe que fizemos tudo manualmente e do zero .
No futuro, deve se tornar, e se tornará, mais fácil. Espera-se que tudo seja configurado dentro da CLI Angular, e criar uma montagem de um elemento será uma questão de um comando cli.
Mas se você ouviu falar sobre os elementos angulares e deseja experimentá-los - esta é uma das soluções possíveis. Vou compartilhar o segundo no próximo artigo . "
Uma descrição útil de como o ChangeDetection.OnPush funciona, sem entrar no código Angular. É muito útil para quem não conhece e mal sabe como viver com ele.
“Essa técnica é chamada verificação suja. Para descobrir se um modelo precisa ser atualizado, o Angular precisa adotar um novo valor, compará-lo com o antigo e, com base nisso, tomar a decisão de atualizar.
Imagine um ótimo aplicativo com milhares de fichários; se deixarmos o Angular testar cada um deles durante o ciclo de detecção de alterações, encontraremos problemas de desempenho.
E se você ajudar a Angular, sugerindo a ele quando verificar nossos componentes? ”
A quinta versão do Nest foi lançada - a excelente estrutura de back-end angular do Node.j no typescript. Eles o tornaram ainda mais abstrato (permitindo que você usasse qualquer servidor http, não apenas o expresso), ajustaram a sintaxe para corresponder ao Angular (decoradores / módulos), vasculharam o módulo de microsserviço, simplificando a serra de seus adaptadores e bibliotecas RPC em vez do padrão.
Bem, tradicional: venha trabalhar conosco! Sempre precisamos de pessoas legais !