Up next in 10
Fully Zone-Less - High-Performance Angular applications in post IVY by Michael Hladky
Nov 16, 2023
In this session of Angular Virtual Conference Conference by Michael Understand the guts of Angulars change detection and why zone.js is your biggest enemy. Learn the trick on template bindings, component rendering, and where you pay the biggest price.
As the tip of the iceberg, you will learn how to identify and avoid
blocking UIs by analyzing flame charts and leverage task scheduling.
In the end, you will be able to build applications with zone-less
performance even in a zone-full environment. 🤯
C# Corner - Global Community for Software and Data Developers
https://www.c-sharpcorner.com
Conference Website: https://www.2020twenty.net/angular
Show More Show Less View Video Transcript
0:00
so welcome and thanks a lot for the opportunity to talk here the title of my talk is fully
0:12
zoneless high performance rendering in angular applications especially now as the ivm migration
0:20
is done and we have a little bit more opportunities and a cleaner roadmap of what is possible and what
0:29
will be possible in the future and to give you a quick uh sketch of the today's talk and a little
0:37
bit of a background there are already design documents about similar ideas out there since
0:43
years it is just um not often that easy to migrate an already existing framework to a certain state
0:51
where you can say and now i can increment uh implement this feature and so on so the ideas
0:58
basically are quite old rob walmart for example presented one of the features that are included in
1:04
this talk i guess 2016 if i'm not wrong so quite old ideas but now as we moved forward it is a
1:14
little bit easier to implement them in a performance and reliable way this is a background and i want
1:23
to switch to the agenda and show you some chapters that i want to talk about and that i hopefully can
1:30
also demo uh easily um let's see because i did an upgrade just before so it was a little bit risky
1:40
we will see what's the agenda first um of course i'm on on those experimenting experimental topics
1:48
for a long time and most of the time i have long-term goals which need several steps to
1:55
achieve so i first want to give a quick uh information of what foundational things i did
2:02
in 2019 and early 18 and then i will switch to the current work of 2020 until now what we have
2:12
on the agenda are the foundations as i said i will quickly introduce you to rendering like some
2:20
basic knowledge and i want to point out some problems that you can run into while trying to
2:26
gain a little bit more performance in rendering then i will talk about template helpers this is a
2:32
pretty cool feature set because it helps to increase the rendering performance and make as
2:42
little changes as possible in your code i will show you some tricks how you handle zone this is
2:48
like it's really really cool it's just a small demo but it will it will show us what we really
2:53
can gain if we can get rid of zone or just trick zone a little bit and then i will show you uh
3:00
additional features on if we already if we can work with a zone less
3:08
similar environment and what we can what we can add on top so as a foundation to
3:17
all my work uh here uh i did a lot of researches one pretty pretty big uh research paper in 2019
3:26
and another very uh big rfc and a couple of github repositories that pointed out the current
3:34
problems of angular what we should change and what we need to implement and this is like uh
3:42
really necessary to make the next step and introduce rendering in a way that i will present
3:48
it now in 2009 my main topic was reactive component state back then uh pretty interesting
3:55
also other frameworks started at the same time to evaluate new ideas regarding this we had flutter
4:02
which was one of the first new frameworks that had ephemeral state as a built-in framework feature
4:09
which i guess is pretty pretty cool but also i even knew from view for example gave a pretty cool
4:17
talk on component states so 2019 and a little bit before was all about reactive component state
4:24
and back then and also now the library that will uh leverage all those things is called rx angular
4:32
slash state the goal was basically to provide you the reactive glue like the minimal lines of code
4:40
that you need to introduce to your component to have reactive component state management
4:45
no architecture no new patterns just one liners for imperative and reactive things to glue together
4:54
pretty cool you should check it out and here i listed some links that you can look at and maybe
5:02
also you can give it a try the first one is the research it's pretty a big paper on dev2 it is
5:08
a general research on reactive components state in front in component oriented frameworks
5:16
then the library itself and it readme its readme's and one talk of 2019 where i demonstrated the
5:25
implementation of this library and what it leverages and how little amount of code is needed
5:32
to make a fully reactive component this is like the foundation of my work and the second chapter
5:41
here would be rendering in angular and rendering is in angular is all about the template rendering
5:51
right template rendering about the component tree angular is a component oriented framework so it is
5:59
a root component which in turn consists out of its children which in turn consists out of their
6:04
children and angular renders this tree in a certain different of ways that i experimented with
6:13
especially the new options that we have since the iv migration and some ideas like the principle of
6:20
locality so i will give you the fundamental information about rendering now and in the next
6:27
chapters i will introduce local rendering and further topics let's go on with the normal
6:35
rendering information and let's take a look at a quick wireframe at the very top we have the
6:41
application ref the application ref is basically a service that holds a reference to your application
6:48
reference to the root component and it also has several ways how you can render the component tree
6:57
and this method is called application ref tick and at the bottom we have a lot of green boxes and
7:05
those green boxes are all the components in our application we have the app component on the left
7:11
side we have the menu component and a lot of menu items inside also components and on the right side
7:19
we have a list with list items check boxes and so on so this is our rough wireframe of the application that I want to discuss And this is the application If we turn it into a component tree structure and the letters here are just references to add to the app component the menu the list component and at least items and so on
7:47
So if we look at this component tree and we render it
7:52
we need to call application tick and if we call application tick this basically takes a little bit
8:01
because application tick is not synchronous but after all its internals are run angular will
8:07
trigger to render the application and it will start by rendering the application the app
8:14
component then the menu its menu items and then it will go on with the list list items and the
8:20
checkboxes this is how angular would render the full components tree and by default this is what
8:28
happens if you initialize a new project in angular for sure this is not the fastest way
8:35
so you can do always a little bit better one thing that you can do is split the code in
8:42
as meaningful components as possible. So this will package the amount of work
8:49
that you need to do to render a specific piece of your application
8:53
But also you can introduce rendering strategies. And there is the default rendering strategy
9:00
and there is also a second rendering strategy. And this is called the on push
9:05
change detection on push strategy. And this strategy basically compares the previous value and the current value and if there is a change basically a change in the
9:17
instance in the reference of this object so no state mutations but immutable state then it will
9:25
re-render your application and if we take a look at this application here and we trigger the tick
9:32
again we see on the left side one component has a gray triangle and if i start to render we see
9:39
this gray triangle turns black this means change detection on push evaluated this component and
9:48
it turned out that it is not that it didn't changed to the previous value so we don't render this side
9:56
and we go on by only rendering the left the left uh right side of our application and this is
10:02
pretty cool and i would really suggest to use the async pipe and change detection on push
10:09
everywhere in your application this will bring you a lot of performance immutable data structures
10:17
and other cool stuff that will increase the rendering performance of your application a lot
10:25
if we take a look at the real life example if i want to introduce a change to this pink component
10:34
here and i call this change or let's say i introduce the rendering over the async pipe
10:43
for example then it would look like that a lot of components don't have change detection on push
10:49
they will render unnecessary also a lot of other components will get re-rendered because the async
11:00
pipe will go up render the full component tree and then go down and evaluate and re-render the rest
11:09
so this path from the pink box up to the top and down to the pink box again is always re-rendered
11:15
no matter if the parent components are changed or not. As you can see, a lot of stuff is re-rendered unnecessary
11:26
Let me quickly introduce myself and then serve some solutions to these problems
11:31
My name is Michael Ladki. I'm a trainer and lead instructor at Trilon
11:35
And I'm mostly focused on custom-tailored consulting, training, and helping bigger companies to scale
11:45
and what I want to do today is I want to help you to fix rendering performance in your applications
11:54
so if we stick with this example from the pink box I give you some tools to fix those example
12:06
and the current tools are collected under rx angular slash template let me quickly uh turn on
12:16
the noise here this package basically includes a lot of cool tools that help you to fix all
12:23
related problems that i will demonstrate today uh tools included or let's say building blocks
12:31
included in this library are imperative rendering primitives like rendering methods that you can call
12:38
in your component i give you an example detect change for example is a render method even though
12:45
you should not directly use it because it will decrease your performance instead of increasing
12:51
it but i'll come to that later on our created imperative rendering methods don't decrease the
12:57
performance they really increase the performance and they don't only increase it a little bit they
13:02
give you some less performance in some full applications speaking about imperative methods
13:10
i also have the rendering strategies rendering strategies are a reactive way of handling those
13:18
different problems in all the various manners I told you that at the very end I will introduce
13:28
tools to trick zone we can directly look to this middle block here unpatch unpatch is one of the
13:35
helper directives that help you to trick the patching of global apis from zone and you can
13:42
basically use let's say click or any kind of event bindings in your dom without interfering
13:49
with some Js I guess this is really really a cool feature then I will speak about the
13:56
fundamental blocks here the push pipe and the RX led directive both of them I created several
14:03
design documents I implemented a very very basic implementation in ng-rx and this presentation
14:11
here includes the latest version with all the performance features as a last piece i want to
14:17
demonstrate viewport priority and this is basically all about rendering only the stuff that you see
14:24
why should you render stuff that is not visible on your browser's viewport so one of the last
14:30
problems i will demonstrate is the few part priority directive let's start with the push pipe
14:37
and the let's directive the push pipe and the let directive if we look at the template syntax
14:47
first are pretty easy to grasp the upper one is a replacement for the async pipe so push or async should work pretty much the same the difference is that the push pipe will bring so less performance also in your zone full applications so by default the push pipe is
15:07
using change detection detect changes and only renders locally the changes in your component
15:15
and don't go up the full component tree and down the same principle is implemented in the rx let
15:23
directive here you can bind an observable to a specific scope of your template and then you can
15:32
display its values as you would do with with other template direct or structural directives like the
15:39
ng for the ng if and so on so it's demo time and let me first introduce template helpers to you
15:49
and I will switch here to this very example and I will show you the code here let me quickly open up
16:01
the demo it is cool let's sing here okay so here we see that we can
16:27
let me scroll down where are we
16:39
ah this is the wrong one i'm sorry let me switch here i'm really sorry
16:48
yeah so here we go um by default we would use if we want to bind an observable to our templates the push pipe and
17:09
the push pipe is displayed or is used as we can see here instead of writing a swing app we can
17:18
write the word push and as a second thing the push pipe takes some strategies I will come to
17:24
that later to quickly demonstrate the usage of the push pipe let me see if I can click on that
17:34
button here quickly and switch to the memoized view stage so here i demonstrate the push pipe in combination with an ngif and this is a very common problem
17:56
that we face i guess the push pipe is pretty clear but the ngif is a little bit more interesting
18:03
the pushback basically only displays your value at a very single place in your template so if i
18:11
quickly render a value with my public replaced curly braces we could let me remove this see
18:20
true and false values coming up in my screen here i will zoom in so that you can read it a little
18:26
bit better and you can see true and false written here nothing special if we want to bind it to a
18:33
certain container or to a certain piece in our template we normally use this push pipe
18:40
hack to bind it to this ngif directive and if i do this and i switch my bush values back and forth
18:49
we see that only true values are shown the falsy values are not visible and this is a very very
18:57
clumsy way and very tricky we have to introduce several hacks to make it also work for bush values
19:04
and this is the situation where we can leverage the rx let's directive so if i use the rx let's
19:12
directive here it looks pretty much the same the only difference here is that i can also deal with
19:20
bullish values so if i switch back to this page here and i click next we see that also false values
19:30
are displayed this is the first cool trick that we implemented to leverage the power of
19:37
of template helpers reactive template helpers another very cool thing is that we
19:46
with the first step here introduced lazy template why laziness because now as you can see i restarted
19:55
and there is no value visible so think about an http request that you bind into your view
20:03
into your template and then it starts to kick off to the server and while it is on its way we could
20:09
basically not do anything we could provide a loading spinner or something else but we
20:13
don't really need to generate the template uh the embedded view that is displaying the value
20:20
so in this case we see nothing because the value is not here yet it is lazy clicking on the next
20:27
button the template is immediately created and we can see true or false values our template now is
20:37
not only lazy we can also handle the full reactive context what does it mean to handle the full
20:42
reactive context i cannot only have next values i can also see if my screen my stream errors and
20:51
then the error should be displayed down here how can i deal with this in the first place i can add
20:59
another two um variables here that help me to deal with my error and my complete state and i can
21:09
quickly implement those two new lines that you can see how our error and our complete
21:17
our signal can get leveraged in the template let me switch back wait until it is refreshing
21:26
click Next so we see error and complete is false if I click the error the error value turns into
21:33
true I can also reset a whole implementation I can next values and then I can also complete and
21:44
with this we have the way to implement let's say a fallback template for error situations in the
21:50
fallback template if we are done or our stream completes still this would make a lot of uh if
21:59
else fiddly necessary in our template part here so for this we can also set up some different
22:10
templates that we can use as template references like you would do in an ngif directive i created
22:17
one template for the complete state one template for the error state and one template for the suspense
22:24
state of this very stream here if i want to leverage them i can just include them here and place it
22:35
as new settings in my rx let's directive and if i now kick off and refresh this component we
22:45
should see the suspense state displayed in a loading spinner pretty cool here we have this
22:51
ghost elements that are immediately displayed because not yet any values are present this is
22:58
i guess huge this is the first time since we have real lazy templates imagine you want to introduce
23:06
such a behavior with your normal setup well what you could do is you can set a default state at
23:13
the beginning you have an empty array and if the empty array has some items you switch to the real
23:20
screen but this is not the full truth the full truth is as long as you did not receive anything
23:27
it is loading or in a suspense state and this is like a demonstration with a ghost element how the
23:36
suspense state really directly is received from the observable context and not from other tricky
23:41
hacks i can also next the value and then my next value template is rendered but i can also display
23:49
the error template or i could display the complete template as you can see here with this small
23:56
check mark so those are the template helpers that i demonstrate wanted to demonstrate you
24:02
especially these lazy templates another cool thing and another performance game that we did is
24:09
we introduced memorized views what does it mean memorized views i don't have a slide here but
24:16
imagine the embedded view the template references that you create normally if you would use angular
24:22
native structural directives they would get instantiated immediately and when you switch
24:28
a template from a complete to error from next to suspense and so on they would get destroyed
24:34
recreated destroyed recreated and this is a lot of work that you need to do in the background
24:40
especially when you start to make more large-scale template stuff or you nest uh
24:48
ifs in ng force and so on then then this is really costly and here memoized views come into play
24:55
we basically create them once and if we change the view we basically don't destroy them we detach
25:03
them from the rendering cycle and if we need them we reattach them to the dom to leverage their
25:09
template syntax this is a really really huge performance gain and one of the things we did
25:15
in the background for you to give you this huge performance impact enough demos let's go back to
25:23
the slides template helpers are done and I want to jump to two new things that we need to make
25:34
template help us verse II because you of course could implement them and just
25:39
directly use detect change but believe me this will mess up your performance
25:44
and the next chapter is here to not only demonstrate how you can mess up your
25:49
performance but also demonstrate how you can basically get rid of those
25:56
negative performance impacts next so I want to discuss two different rendering strategies in this talk there are way more in the
26:08
pipeline but just to keep the scope a little bit narrow for this talk there are only 45 minutes
26:14
I will talk about global and local rendering and the first question that we could ask is how we can
26:23
use these strategies even if we don't really know what exactly they are doing how can we use them
26:29
and one way how we can use them in the push pipe is to add another parameter to our pipe
26:37
you can see those colon strategy in the upper part of the code examples this is how you would
26:42
leverage the strategy in your push pipe and down at the very bottom you can see how you can
26:50
leverage the strategy in the rx let pipe those are two ways how you can leverage these strategies
27:00
the first strategy is the global strategy the global strategy is possible because of some new
27:08
ivy features one of those new ivy features is called tether mark dirty this is basically the
27:14
internal function that i leverage in the background to gain this new rendering strategy
27:21
and what the global strategy does is pretty much identical to what mark for check would do
27:27
the difference is that it just works also without zone included so mark for check really needs zone
27:36
to be in the package to be running in the background to trigger the application ref tick
27:43
to get re-rendered uh global or mark dirty tether mark dirty to be more specific does not rely on
27:50
zone and this is like the first step into direction of a fully zoneless environment
27:59
and global strategy then goes up the tree marks all the components as dirty and then it re-renders
28:06
it would re-render the very component and its children and also up the tree if we remember
28:16
the thing that I showed you with the purple box even if we don't need zone and even if we would
28:24
have marked everything with change detection on push we would unnecessarily re-render the path
28:31
up to the top and down to our very component and this is stuff that we don't really want to do
28:38
this is stuff that really drains performance imagine somewhere in your parent would be a
28:43
costly component a bigger table or something else you would mess up the whole performance of
28:49
of their full application by just using uh the wrong rendering strategy and i'm pretty sure that
28:56
this is one of the points where a lot of people experience negative performance impacts gained by
29:03
zone or the wrong rendering strategy so let me demonstrate you what this rendering strategy would
29:11
do and i will switch into another example here into coalescing uh and now i want to talk about
29:21
those numbers here that flash so first uh let me set up native rendering this is what angular is
29:29
doing natively i just recreated it for uh to get used as a strategy so that you when you use the
29:36
package you can implement it with the native strategy everything will work as it would do
29:42
before and then you can slowly incrementally move into your real cool performance impacts
29:49
with the new strategies. But let's take a look about native. Native would basically render the very component
29:57
In this case, our component here with one push pipe another push pipe and a let directive and not only this very
30:06
component but also its parent component its parent component and the root component so if i click it
30:13
we see all the numbers are flashing and even if we just want to update this very little thing here
30:20
we re-render the full app tree same all but on with the only difference that this could also work
30:29
without zone is with the global strategy so this is done now with tether mark dirty but as you can
30:35
see we still re-render the full component the full application here and this is not really good
30:42
so this is the big downside that i want to demonstrate that you get when you use normal
30:52
rendering or even mark dirty rendering when including all the parent components
30:59
let's go back and let me introduce a second strategy that will fix our problem the second
31:05
strategy is the local strategy and this strategy builds up on detect changes with a little bit of
31:12
tricks in the background here i leverage ivy's new tether detect changes method in the background
31:21
and this strategy should only really only render the very component where you introduce the change
31:28
and maybe it's children if they also introduce a change through this change
31:33
the downside of detect change directly is that you decrease the performance a lot detect changes is
31:45
synchronous and if you call it multiple times in a row you will render it multiple times and here
31:52
i do a demonstration where i just use two push pipes and one let's directive in a template and
31:58
also some static render functions in the component so this is more or less a real life scenario of a
32:05
mid-size component in terms of what you would implement and what you would need to render
32:13
if i quickly demonstrate you the performance of the local strategy natively like how angular would
32:25
implemented by default and how i implemented in the previous implementation of other
32:32
packages we would have if we click the button 12 renderings for one change so jumping from 4
32:41
to 16 and now we will jump from 16 to 28 we see 12 renderings for a single click
32:49
this is not really nice but the good point is we don't re-render all the other components we just
32:57
have to get rid of those unnecessary 12 12 renderings and how we will get rid of it let me
33:05
quickly demonstrate uh discuss those things in my slides uh i use two principles to get rid of it i
33:11
will use scheduling and coalescing and the first thing that i want to talk about is scheduling
33:16
scheduling basically takes a piece of your code and instead of executing it immediately it moves
33:25
it to a different part of your browser scheduling basically helps us to split the work in different
33:34
sections if we look at a synchronous task and we think about the synchronous task and how we can
33:42
split it we would end up in two pieces the first piece is a trigger that is here to trigger our work
33:51
a button click that is bound to a function and this function kicks off our rendering
33:58
then we have work itself this is maybe the rendering of our component and this is the
34:04
two pieces that we need to understand how we can leverage scheduling so scheduling now could look
34:11
like this i trigger a specific work and i reschedule it in this case with the animation frame
34:20
in the future and place it right before the browser paint event right before the browser
34:26
is ready to paint not previously this is one example of how we could schedule a task
34:33
and this is like the fundamental technique or one of the two fundamental techniques that
34:40
we used in rx angular to leverage those incredible cool performance gains scheduling itself is a
34:49
huge different set of options in this slide I demonstrated in red sync in yellow a micro task in blue an animation frame then the dark blue things are cutting edge things here i worked with post task scheduling which is only present in croconary chrome at the
35:10
moment but still we are working with it and we have pretty cool uh and excitement insights on that
35:17
and also the idle callback in gray here so you have a variety of sets of scheduling options
35:23
where you can choose from and we picked the micro task to implement coalescing so what is coalescing
35:31
coalescing basically is buffering multiple different events together into one single what does it mean well imagine we have this function this work this render call that we want
35:45
to schedule to a different place a micro task here is used to schedule it and a micro task you
35:53
have to know is let's call it special synchronous code it is it is synchronously executed but it
36:02
will get prioritized after your normal code so a promise will immediately fire but only after all
36:10
your real synchronous code is executed which is a very very narrow time window between synchronous
36:17
code and the micro task we leveraged this narrow time window to basically coalesce multiple
36:25
different renderings together into one single one and we did it by passing multiple emissions
36:34
into a function this function basically reschedules all those emissions and as when the micro task
36:41
occurs we only call the rendering one single time this is the really really cool performance cane
36:48
that we implemented and here we can see that if we call it three times synchronously pass it to
36:55
our coalescing function we end up with one single call of this render method right after all
37:04
synchronous code is executed this was the first big step into a way how we could really meaningful
37:11
leverage detect changes let me demonstrate coalescing here um and switch to other strategies
37:21
here let me have a sip of water okay so i already demonstrated you that angular by default re-renders
37:33
12 time and also any other implementation of those ideas that i demonstrate here
37:42
will end up in the same negative performance impact and then if we introduce colesting and
37:49
i will do this now and i click the button again let me quickly refresh switch to coalescing we
37:56
have here four renderings and if i click the button we should end up uh instead of having
38:02
12 re-renderings only four and we see this the number jumped from four to eight from eight to
38:07
12 from 12 to 16. and we can see we already gained uh two quarters more two thirds more performance
38:18
because we are down now to one third from 12 to four but this is not enough and again this is not
38:27
scalable so we had to solve a separate another problem and this was scoping the coalescing not
38:34
only by a specific template directive or a specific function in your component we really
38:41
would have to scope all the coalescing on the template itself so everything that would render
38:47
something in a specific template should coalesce the re-rendering of this specific shared template
38:54
together into one and this is our local strategy and if you look at the number here it is
39:01
53 and if i click now the button it only increments by one so we have 54 55 56 and this is really
39:10
huge and i guess super incredible even if my energy level is today a little bit low
39:17
this is as exciting as it could be it is not re-rendering the full application and also not
39:26
over rendering our very component incredible cool i would say let's switch back and let me show you
39:34
even more cool stuff let's recap that we went down from 12 re-renderings to one single rendering
39:41
and let me introduce you the two changes or the two performance impacts that we introduced the
39:48
first one was instead of going up the component tree and down and re-render everything on this
39:54
pass we only render the very component so we improved the number of rendered components drastically and even better we went down for this very single component
40:08
from 12 renderings by Angular native to four renderings to one single rendering
40:15
And this is like incredibly cool. And this is like the reason why we could work on further
40:21
on future features and implement more cool stuff. but this one was like the most important thing for us to ship so while demonstrating how cool and
40:34
how performant we could decrease the number of renderings and also the way how it is rendered
40:41
let me now give you another cool insight on what you could do and the new insight is few port
40:47
priority i want to show you how you can prioritize rendering based on if this component is visible in
40:56
your viewport or not and i will switch to another demo i go here to viewport priority and i zoom
41:09
out a little bit and i demonstrate you that i have a component here a component that is sometimes
41:15
visible and sometimes not and here i have a button and if i click the button you can see the number
41:24
if i go here the number increases whenever i click the button the value counts up
41:32
so would you like to re-render the component here if it would be outside of the viewport would you
41:39
have any benefit of rendering this component or parts of your application that are not visible
41:45
Basically, I would say no. So we should find a way if I click the button here that it will it would show the value
41:54
And if I move out and I click the button, there should be no change
41:59
And this is possible. As you can see, if I jump to an interval where you have constant changes and I move the component out of the viewport, you see changes or re-renderings stopped
42:13
And if I move it in, we can see that the values are changing again
42:18
So this is one thing, but let me point out a variety of problems or let's say performance improvements that we did on top of it
42:27
Now we have 113 as a number here. If I move out and I click the button two times, it would be 115
42:37
so as it is not re-rendered this component is out of sync now which is pretty bad but if we move in
42:47
we detect that there is a difference and we render the component and now we see the original number
42:54
and our rendering increased by one if we move the component out and in again with no change then the
43:02
very component here is not re-rendered so this is i guess a pretty cool performance optimization
43:12
with stuff that is not visible in your viewport really exciting and also really cool because we are working on a way how you can implement
43:24
it globally at the moment you have to apply a directive on a component that you want to control
43:30
over it in the future it should work naturally by just implementing the rx angular template package
43:38
to get out this really high performance improvement let me switch back to my slideshow and jump to the
43:46
last chapter because time is short uh tricking zone and um to demonstrate you how bad zone is
43:54
and what we did i want to talk about quickly a package that is called unpatch unpatch basically
44:02
unpatches zone patched apis pretty intuitive naming what it does is really good to demonstrate
44:12
if you switch to a button click so this is a flame chart of a hello world example and if i
44:17
would click a button that does nothing this happens in angular natively i would re-render
44:25
everything in my application the very very top component until it to the very button
44:33
a lot of people treat um situations where they want to avoid interference with zone with
44:39
the ng zone service and its method run outside zone and this is done here and even with this
44:49
method we have for sure we have a dramatic decrease of performance but still a lot of
44:58
overhead because all the blue methods here are introduced by zone now let me show you how your application would look like if we would basically use the unpatched directive and then it looks like this
45:15
if you battle test it with just vanilla javascript and nothing else you will realize
45:20
this is the minimal amount of code you can execute and this is the most performant way
45:26
how you can handle zone patched apis or let's say how you can deal with code execution in the most
45:33
performant way this is basically even faster than just disabling zone so this is like really
45:42
completely zone less performance in zoneful applications as this is a lot of theory let me
45:49
demonstrated to you in a real life example here i have a tour of heroes running and this is my
45:56
rendering strategy let me switch to global let me switch sorry to native so this would be what
46:04
angular would do natively we can see all those circles flashing i can also switch to local
46:13
and we see that there are a little less renderings present but still a lot so
46:24
the first improvement let me show you is that if i use local and i would type here
46:32
two times the http request that you see flashing here is only coming back one time which is not the
46:40
case if you do it natively here we will see after i type two times also a second
46:48
also a flash here local will if the http request returns only flash down here but still not really
46:57
good because as you can see whenever i type the full application is rendered and this is because
47:04
zone by default patches or global apis even event bindings add and remove event bindings
47:11
so to fix this i will quickly jump into this application and introduce a directive and this
47:19
is the very last thing that i want to demonstrate here i want to introduce the unpatch uh directive
47:25
or on this input binding and refresh the page and if i know type in this input box nothing is re-rendered
47:36
so even if i type a lot not a single rendering is cost not even if we have the change detection
47:44
strategy native here and if i switch back to local this is the best possible way as we can see
47:52
we type and rendering is only introduced here at this very local place so this is pretty cool um
48:03
and if you question what we need to do now to go fully zoneless well basically nothing the very
48:11
demo here that is working with angular native way of rendering is immediately working as long as you
48:18
switch to the local strategy so having a your application run in soneless is as easy as possible
48:26
with this new package rx angular slash template and rx angular slash state let me ramp up the
48:35
stuff here and let me introduce a couple of people what i want to do is i want to follow principles
48:44
from pretty cool persons out there uh one of those cool persons and idols of myself is richard
48:50
feinman and richard feinman has one uh principle that he follows a lot and this is give credits
48:57
where it's due so i want to use a little bit of your time to give credits to people that helped
49:04
and that were like basically interacting and supporting this whole project the two core
49:10
contributors julian and keryl and a lot of other people that helped and currently work on this
49:17
really really cool package that will bring you incredible zone less performance even in zone full
49:24
environments this is the end of my talk i'm very very happy that i could deliver it that i still
49:32
had enough energy this day and as always if you have any questions feel free to approach me feel
49:40
free to ping me and of course check out the repository on npm or on github the repository
49:47
name is called rx angular for the reactive component states that i developed in 2019
49:54
it is rx angular state and for the pretty new and exciting stuff rx angular template that's it from
50:02
my side
#Programming
#Software
#Computer Science