Transcript from the "Performance with Change Detection" Lesson
>> Lukas Ruebbelke: So in this module, we're going to continue on this make it everything narrative arc. So we saw how to make it work through unit testing, and how to make it right through static analysis, which I particularly love. Because you can get a lot of insight, with very little effort on our part, which is nice.
[00:00:23] Now we're going to talk about making your application fast. And so, obviously, there's tons of things you can do to accomplish that, but I want to give you two concrete things that you can do, to make your application faster. And so one of these is something that is slightly on the advanced spectrum, but I wanted to service it.
[00:00:49] Because being able to do this first technique is something that you could not do in angular js. And it's pretty crazy, let's talk about change detection. In Angular JS, one of the valid criticisms is that if you did not use,
>> Lukas Ruebbelke: Change detection properly or you didn't understand how the digest cycle was working, it was really easy to get the applications kind of a bad sluggish state.
[00:01:22] So, for instance, I had one of my friends come to me. He owns a company, he's a developer. He said, hey, I need you to look at my Angular application, AngularJS application. I'll pay you, it just crashes, after five minutes, we can't use it anymore. And so I show up, and he's showing me and I'm just like, wait a second.
[00:01:44] You are literally looping over a thousand records, using repeat and putting them on the page.
>> Lukas Ruebbelke: And every one of these records is fairly complex. So now you're binding to a thousand objects, complex objects, on the page so it was basically these car records. And you're wondering why if you are having to go through and compare every one of these, when something changes.
[00:02:09] [INAUDIBLE] it's starting to run slow. I found my experiences that generally when you have a performance problem, more than likely, you have a UX problem. That is actually the performance problem is a trailing indicator that your experience is not optimal. So one of the first things that I would to a situation like that is, yes, putting a thousand records on the page and binding to them, that's going to cause some problems.
[00:02:42] More importantly, I don't know anybody who could possibly process all 1000 of those records. How many of them could you even see at a single time, maybe 20? There's a reason why I would wager if we did a Google search, they could give us hundreds of thousands of records.
[00:03:00] But they gave us 20 at a time, because that is a level in which we can process. So to say, first of all, with performance, this is kind of a freebie, but I run into it a lot, is if you run into a performance problem, first stop and look at the user experience.
[00:03:21] For instance, you may not need a thousand records on the page, or there may be a way to simplify the experience. The one, improve your performance but also improve it for the user. So with that said, in Angular two or above you had the ability, well, first and foremost, that they redid change detection from the beginning.
[00:03:44] So it's much more performant. But they also gave us the ability to control where and when it happens. And so they introduced this thing called zone.js. And it's pretty ridiculous. And so Brian Ford, who used to be on the Angular team, I remember one night we were in San Francisco and he's telling me, I had this crazy idea and I think probably like had or whatever is like this crazy idea of like what if you monkey patched everything on the DOM,
>> Lukas Ruebbelke: And you could listen for it. So change notation on the entire thing. Not just angular but everything. And you could do it in an efficient way, how cool would that be? I'm thinking that sounds crazy. Well, anyways, what ended up being really cool and what ended it up being was JS.
[00:04:35] And this is why I kinda had this monkey, because it's monkey patching the entire DOM that your app lives in. More importantly, is it's creating these very efficient change detection classes under the hood, so it's this optimized thing that has a current state and a previous state. And then when something changes, instead of looping over the component.
[00:04:59] It loops over the change detection class it says, has it change or not? Do I need to update it or perform some action. And as a result change detection just right at the box, three to ten times faster. Amazing, so we're already getting this huge performance boost right at under the gates.
[00:05:21] But it's even faster than change detection not needing it at all. And this is, I think, really interesting, and do you know what? We have to start over, you forgot to unfreeze me. Well, you know what? You guys get to hear this material all over again. Live stream people, love you.
[00:05:51] We didn't catch any of the slide. Now I'll just get excited about being excited, again. Now I've got to think of new jokes. So anything I said that was funny in the last three minutes, I've got to think of something else that is funny. So bear with me, this will take sixty seconds.
[00:06:13] So in this module, we're going to talk making our application fast. We saw how to make it, right, or make it work, rather, through testing. And how to make it bright through static analysis. In this module, we're going to talk about how to make it fast. And we're going to show two very concrete things that you can start to do within your application to enable that.
[00:06:38] The first one is change detection. And so change detection in AngularJS 1.x was understandably, you can't get it into a bad state. If you do not know what you're doing and you were not cognizant of the digest cycle, certain things would happen that would create a bad user experience or poor user experience such as binding to A thousand records on the page, not good.
[00:07:07] And all of a sudden will start to creep and crawl and break down. In Angular 2 and above, they introduced an entirely new change detection by virtue of Zone.js. And how this works is, instead of looking at the the Angular application, they are essentially monkey patching the entire dom structure in the application.
[00:07:32] So they are watching every single dom element, and monkey patching it with these change detection classes. And so it is going through, analyzing the application. And it's creating essentially this optimize class, with a current and previous state. And so if something changes, it just compares the current state to the previous state.
[00:07:53] And if they're different, then it knows it needs to do something about it. And so this change or changing how we do change detection, resulted in a 3 to 10x improvement. So already just imagine that your app is now three to ten times faster, huge win right out of the gate.
[00:08:17] More importantly, faster than that, is if you simply did not have to do change detection at all. So, in Angular, we can control how an angular, let's say like a node, in the node tree, how it responds to change detection. In fact, by default, it's just how it's going to respond to every change.
[00:08:41] It's going to be much faster, but it's still going to respond to every single change. But we can set change detection to onPush, and what that means is it will only check for changes once, and then it's done. Any changes that happens, is going to be pushed down the node, and Angular is not going to worry about it.
[00:09:06] And so essentially, we're turning off components detection for a component branch. Now, I see kind of some looks here, like what. So let's see how this works, this is a component tree and this is default change detection. Something happens, everything lights up and checks. Now, with OnPush change detection, what we can do with this node right here, we can say we're turning this off.
[00:09:45] And we're going to set it to OnPush, so it's going to evaluate one time, and then it's done. No more Change Detection, for this node and its children.
>> Lukas Ruebbelke: So now when something happens down here
>> Lukas Ruebbelke: So let's say we got this thing coming down here, and we'll talk about this thing, what that might be.
>> Lukas Ruebbelke: That essentially,
>> Lukas Ruebbelke: Well, let me back this up, so something could have happened on here, and it may not light up. So it may not need to detect it, or if you need to force it, then you could simply at the child branch. Then you could force it to run change detection here.
[00:10:34] And it goes up through the parent. But the main thing that generally will happen, in most cases is this. Something will happen, and it'll fly completely under the change detection radar.
>> Lukas Ruebbelke: So let's think of a mechanism,
>> Lukas Ruebbelke: That we used to communicate changes across our application, a few modules back.
>> Lukas Ruebbelke: It does it very, very well.
>> Lukas Ruebbelke: Completely encapsulated.
>> Lukas Ruebbelke: Observables, observables are totally capable of handling their own change detection. That's what that next tic is for, something happened. We're gonna take it and we're gonna run with it ourselves. So you can have, you say everything that is coming to this thing, into this particular node branch is an observable.
[00:11:31] Therefore, we do not need Angular change detection, because it's in the context of the observable. So again, if you remember way back to day one, I said that Angular is simply letting other technology, other standard based technologies to do the work. And they're leveraging it so that you get twice the framework, with half a foot print.
[00:11:59] And so in our component, we simply say ChangeDetection and we turn it to ChangeDetectionStrategy OnPush, that's it. Now, one caveat to this is that if you have, for instance, an observable string and you set it to something. This will not update your template, why not? Well, we turned off change detection.
[00:12:32] So what you need to do is this
>> Lukas Ruebbelke: this.cd so this is changeDectectorRef.detectChanges. So I guarantee, this is a lot easier to do this on a very specific basis, on a specific tic, than having it run all the time. So to me this is a no brainer in terms of tradeoff.
>> Lukas Ruebbelke: So, in a nutshell, we have the ability to turn off change detection at a component level, if it's appropriate. And allow the observables to handle, the essentially eventing within this. Remember, Code volume, control flow, state management. Well, they're doing all of these within the observable string. It's very common to see an observable string that is doing all of that or addressing all of that very elegant precise and concise matter.
>> Lukas Ruebbelke: And then if we actually do need to update a template or whatever, we just call the typed changes and we just force that on a protect basis. But we are controlling it, so very much like detect changes in our testing. We're doing just the same thing here, we have the ability to do that.
[00:14:05] Any questions about that? It makes sense, you just turn it off, Observables are doing it for us. And if we need to update it, we can just force that change to happen. Use different, I think that with his first app, and somebody did a game and optimized it.
[00:14:23] It just went through the roof, in terms of actually speed and responsiveness, because we're just turning it off entirely.