For those who, on a long weekend, are ready not only to eat kebabs, but also to read all the necessary texts, I collected ten of May links from the Vimbox developer channel in corporate Skyak Slack. Like last time, the compilation is concentrated around the Angular framework and will be interesting for programmers working with it.
An excellent analysis of the upcoming Ivy renderer: it describes in general terms why they are doing it at all, and how it works inside.
“Before we get into the details of the performance, I would like to devote a few paragraphs to answering the question that always arises in my head about any changes. This is the eternal question: why?
Details about the Incremental DOM concept mentioned in the article, implemented in the Ivy renderer, and its differences from the Virtual DOM - in this article .
Well, for those who are completely bored - the official design doc for the Ivy-compiler .
Another Ivy renderer mini-review with change detection / live cycle hooks gifs about work, shown by the structure of internal objects and a demo where you can touch it with your hands.
Fun moment from the article:
A short note about why takeUntil should always be the last.
“ What is the problem?
If the takeUntil operator is located in front of the operator creating a new subscription, then upon receiving a notification of the reply in takeUntil this operator will not unsubscribe and continue to work. "
Making animations with RxJS
“Whenever you encounter a problem in which time and asynchrony play a role, reactive thinking along with reactive libraries like RxJS will lead you to a simpler and more reliable solution. In this world of persistent connections, clouds, non-blocking platforms, and microservices, time and asynchrony will play an increasingly important role. ”
Why you should use only ReactiveForms and forget about all sorts of ngModel. Briefly and in the case.
“Why not use both?
I have four reasons:
1. Difficult mastering.
2. It is necessary to load both, and another, and the bundle will become a bit more.
3. We cannot predict what the developer will choose, so it will be more difficult to handle pull requests.
4. In my opinion, it always makes sense to stick to one paradigm, if there are no serious reasons for not doing this. ”
Enough surface anatomy @angular/router , or what happens during navigation.
“From this article, we learned what the Angular router does when a user navigates from one page to another.
You can use the PRIGRAM mnemonic:
P ass
R edirect
I dentify
G uard
R esolve
A ctivate
M anage
to remember the order of steps taken by the Angular router.
Knowing this process will allow you to better understand what is happening behind the scenes, and will help cure potential problems with routing. ”
The story of how the differents are arranged in Angulyar by the example of writing your own.
“Angular differentials are perhaps the least known APIs; these are highly optimized blocks used by Angular itself inside the framework (ngClass, ngStyle, ngFor, etc.).
You will definitely not use them daily, but they can be very useful under certain conditions. If you have ever said to yourself: “It is not enough for me to know that something has changed, I need to know what has changed,” Angular differentials will give you the answer. ”
A simple example of how to quickly get @angular/elements with a simple webpack-config for assembly.
“Please note that we have done everything manually and from scratch .
In the future, this should be, and will become, easier. It is expected that everything will be configured inside the Angular CLI, and the creation of an assembly of the element will be a matter of one cli command.
But if you heard about Angular Elements and want to try them - this is one of the possible solutions. I am sharing the second in the next article . ”
A useful description of how ChangeDetection.OnPush works, without going to Angulyar’s code. It is very useful for those who do not know / poorly understand how to live with it.
“This technique is called dirty checking. To find out if a template needs to be updated, Angular needs to take a new value, compare it with the old one, and decide on the update based on this.
Imagine a great app with thousands of binders; if we allow Angular to check each of them during the change detection cycle, we will run into performance problems.
What if we help Angular by hinting to him when it is worth checking our components? ”
The fifth version of Nest, the excellent Node.js of an angular-like backend framework on typescript, was released. It was made even more abstract (allowing you to use any http-server, not only express), corrected the syntax so that it coincides more with Angulyar (decorators / modules), combed the microservice module, simplifying the insertion of their adapters and RPC libraries instead of default accessible ones.
Well, the traditional: come to work with us! We always need cool people !