WEBVTT 00:03.820 --> 00:06.070 Hello, everyone, and welcome back. 00:06.220 --> 00:11.320 In this lesson, we're going to talk about system change detection, as we have seen before, and Google 00:11.320 --> 00:14.800 provides us with two mechanisms that work out of the box. 00:14.800 --> 00:20.980 We have the default angular change detection mode and we have also on Pushkin's detection that we have 00:20.980 --> 00:22.840 covered in previous lessons. 00:22.840 --> 00:27.150 As we have seen these two modes of change detection work in a very different way. 00:27.190 --> 00:33.130 The default change detection mechanism is going to base itself on the values of the expressions in the 00:33.130 --> 00:33.760 template. 00:33.850 --> 00:38.910 It's going to compare the current value with the previous value to see if a change occurred. 00:38.920 --> 00:42.940 If that's the case, then the component gets marked for rendering. 00:42.940 --> 00:47.650 On the other hand, with on push, we are pushing the data explicitly to the template. 00:47.660 --> 00:53.980 So we are pushing the data either via input properties or via the async pipe into the component. 00:54.070 --> 00:59.980 The component will know then that it needs to shake if some new data is available and decide if the 00:59.980 --> 01:01.390 view should be rendered. 01:01.600 --> 01:07.660 In both cases, if an event occurs because an event can implicitly modify the data in both situations, 01:07.660 --> 01:11.980 we are going to be checking the component to see if it needs to be rendered. 01:12.040 --> 01:16.960 These to change detection models will cover the vast majority of various cases. 01:16.960 --> 01:23.590 But there could be some particular situation where you need to inform Angular manually that change detection 01:23.590 --> 01:26.670 should be executed for a given component that is possible. 01:26.680 --> 01:30.600 Also, let's give here a concrete example where that might come in handy. 01:30.640 --> 01:36.700 Let's switch here to our application component and let's leave it running here using on push change 01:36.700 --> 01:37.300 detection. 01:37.390 --> 01:43.060 Now, what we are going to do is we are going to switch here to our template and we are going to again 01:43.060 --> 01:45.880 remove here the use of the async pipe. 01:45.880 --> 01:51.580 So instead of providing an observable to the template unsubscribing to it using the async pipe, let's 01:51.580 --> 01:52.690 just define here. 01:52.690 --> 01:55.630 A course is synchronous member variable. 01:55.720 --> 01:58.440 So this will be an array of courses. 01:58.540 --> 02:03.850 Now, instead of assigning here to these observable variable, we are going to call the back and we're 02:03.850 --> 02:05.840 going to subscribe to these observable. 02:05.860 --> 02:11.170 We are going to take the courses that we get from the backend and we are going to assign it here to 02:11.170 --> 02:13.360 the courses member variable. 02:13.360 --> 02:18.520 And notice that because we are using here on push change detection, if we try this out, we are going 02:18.520 --> 02:21.100 to see that there is no data on the screen. 02:21.100 --> 02:26.060 And this is because there is no way for this component to know that it needs to be rendered. 02:26.080 --> 02:32.890 We did not pass the data via a pipe to the template and we did not provide the data via a component 02:32.890 --> 02:33.760 input either. 02:33.880 --> 02:38.170 So there is really here no way for this component to know that it needs to be rendered. 02:38.230 --> 02:44.320 However, if we would like to manually inform Angular that whenever some data arrives here from the 02:44.320 --> 02:50.230 backend, that in that case we would like to mark the component for a change detection check, then 02:50.230 --> 02:54.760 in that case we can do so using the component change detector. 02:54.790 --> 03:01.360 So every component in ANGULAR has its own change detector that can be injected using the change the 03:01.840 --> 03:03.980 ref angular injectable. 03:04.000 --> 03:10.720 So this is the change detector of this particular application component and every component has its 03:10.720 --> 03:12.340 own change detector. 03:12.340 --> 03:18.190 So the change detector of our application component is going to be different than the change detector 03:18.190 --> 03:22.260 here that we could inject also in the course Kerith components. 03:22.270 --> 03:28.630 Let's then see how can we use the change detector ref to manually inform Angular that it needs to check 03:28.630 --> 03:29.510 these components. 03:29.510 --> 03:33.330 So we are going to check the API available in our change detector. 03:33.370 --> 03:38.740 We have here several functions and if we scroll down the list, we are going to find this function mark 03:38.740 --> 03:39.790 for shick. 03:39.790 --> 03:45.310 So these will inform Angular that this component should be checked for changes. 03:45.340 --> 03:48.790 Now, if we tried this out, we are going to see that this time around. 03:48.790 --> 03:52.290 Indeed, the data is getting correctly reflected on the screen. 03:52.420 --> 03:57.490 These functionality, the use of change detector Şeref should not be used systematically. 03:57.610 --> 04:03.820 Instead, we should rely on either the default change detection mechanism or on Bush in order to check 04:03.820 --> 04:04.840 our components. 04:04.930 --> 04:07.660 This is just for a very exceptional situations. 04:07.720 --> 04:09.160 Let's give a concrete example. 04:09.160 --> 04:14.650 Let's say that, for example, you are continuously pulling the backend for more data and that you are 04:14.650 --> 04:16.680 receiving data very frequently. 04:16.690 --> 04:20.250 Let's say that you are receiving new data several times a second. 04:20.260 --> 04:26.890 Well, in that case, you might not want to push the data continuously to the user interface because 04:26.890 --> 04:28.900 that could cause performance problems. 04:28.910 --> 04:35.700 Instead, you might want to wait for one second or two before pushing new data into our user interface. 04:35.710 --> 04:38.230 So for that, it would be a matter of calling here. 04:38.230 --> 04:44.560 The change detector mark for check function once per second instead of every time that we receive a 04:44.560 --> 04:46.120 new value from the backend. 04:46.120 --> 04:47.620 That is just one example. 04:47.770 --> 04:51.610 Now, let's see another way of implementing here the same functionality. 04:51.850 --> 04:58.150 Instead of calling here the mark for check function directly in our subscribed call, we can alternatively 04:58.150 --> 05:00.280 implement here another interface. 05:00.280 --> 05:00.400 We. 05:00.480 --> 05:06.270 She's the do check interface, so this is a life-cycle hook and we are going to cover all the life cycle 05:06.270 --> 05:07.920 hooks available in the moment. 05:07.950 --> 05:10.680 Right now we want to implement these methods. 05:10.680 --> 05:11.880 Engie do check. 05:11.880 --> 05:18.550 So this method is going to get called every time that is running change detection in a given component. 05:18.660 --> 05:23.640 So if you want to do custom change detection, this is the right life hook to use. 05:23.640 --> 05:30.550 Let's remove here this call to the change detector and let's move it here inside engy to check. 05:30.570 --> 05:36.090 So if we try these out, we are going to see that every time that we are receiving some new data from 05:36.090 --> 05:41.670 the backend, the data is getting correctly displayed on the screen for comment about this call to Mark 05:41.670 --> 05:47.250 for check, then no data is getting displayed because the component does not know that it needs to be 05:47.250 --> 05:48.050 rendered. 05:48.330 --> 05:54.390 These Metford Engie Do Check is the best place to implement some custom change detection logic. 05:54.420 --> 05:59.640 Let's say that we would like to implement here some very specific change detection logic that would 05:59.730 --> 06:05.210 render the component, but only the first time that some data gets back from the backend. 06:05.220 --> 06:11.730 So if the observable would be mid-year further values, those would not get reflected here on the screen 06:11.790 --> 06:13.830 could implement that in the following way. 06:13.860 --> 06:20.310 We can add here and if close and we can check if the course is variable is defined or not. 06:20.470 --> 06:26.880 Initially this variable is going to be undefined, but if it already has a value, it means that the 06:26.880 --> 06:28.980 value has already arrived from the backend. 06:29.010 --> 06:33.320 So in that case, we are going to call the first time the change detected. 06:33.480 --> 06:37.500 Let's also add here some logging so that we can see what is going on. 06:37.510 --> 06:43.650 We are going to log here to the console, simply the name of the lifecycle hook, these life-cycle hook 06:43.650 --> 06:46.380 and the check is called very often. 06:46.540 --> 06:52.020 So if we now check here in our console, we are going to see that we have here a series of calls to 06:52.020 --> 06:53.700 engy do check. 06:53.820 --> 06:59.970 Now, each time that this method is called, in case the variable is already defined, we are again 06:59.970 --> 07:05.310 marking the component for being checked by the angular change detection mechanism. 07:05.370 --> 07:10.680 If we would like to do this, check only the first time that we get some data from the back and we could, 07:10.680 --> 07:16.770 for example, add here an extra flag so we could define here a loaded boolean flag that we are going 07:16.770 --> 07:18.180 to initialize to false. 07:18.300 --> 07:24.540 We are then going to set this flag here to true whenever we get some data from the back end. 07:24.690 --> 07:30.390 Now we are going to take this flag and we are going to use it here in our custom change detection logic. 07:30.390 --> 07:36.420 So we are only going to mark the component for check if the data is already loaded and this will trigger 07:36.420 --> 07:39.760 here change detection in this component for the first time. 07:39.840 --> 07:46.110 Now, the next few times we would like to avoid calling here, Mark, for check because we are sure 07:46.110 --> 07:49.490 that we will no longer receive here any data from the back end. 07:49.500 --> 07:55.860 So in order to ensure that we are going to set this flag back to undefined, let's add here some extra 07:55.860 --> 07:58.050 logging so that we see what is going on. 07:58.140 --> 08:04.740 Whenever the code reaches this point, we are going to look to the console called KDDI Dot marked for 08:04.740 --> 08:05.160 Shick. 08:05.340 --> 08:06.730 Let's check in the console. 08:06.750 --> 08:08.150 What is the final result? 08:08.160 --> 08:13.320 So first of all, we can see that after reloading the application we have here, the data correctly 08:13.320 --> 08:14.640 displayed on the screen. 08:14.640 --> 08:19.710 And notice here in the console, engie to check is being called a bunch of times. 08:19.710 --> 08:21.720 We have here already free calls. 08:21.720 --> 08:26.190 And if we click here, for example, the edit course button, we have here a fourth call. 08:26.190 --> 08:30.720 So this method is being called many times after each browser event. 08:30.720 --> 08:32.140 This is going to get triggered. 08:32.160 --> 08:38.430 But the cold change detector mark for check function is only being called once. 08:38.460 --> 08:45.090 So as you can see, we can use the API of the change detector ref to implement our own custom change 08:45.090 --> 08:46.130 detection logic. 08:46.170 --> 08:52.590 This should only be used in very special cases where we want to do some type of performance optimization. 08:52.720 --> 08:59.280 Again, in the vast majority of cases, default change detection is going to work great and if we really 08:59.280 --> 09:04.410 need on push, change, detection should solve all the performance problems that we encountered. 09:04.500 --> 09:11.130 If we fall in a very specific case where you need something more than that, then we can always resort 09:11.130 --> 09:13.630 to using the change detector reference. 09:13.770 --> 09:16.080 This should only be used as a last resort. 09:16.290 --> 09:22.530 For example, here in this implementation, it would be much easier to simply use the async pipe here 09:22.530 --> 09:29.010 at the level of the application component and have the on pushing detection mechanism detect the changes 09:29.010 --> 09:30.450 automatically for us. 09:30.660 --> 09:36.350 And we d we have covered the multiple mechanisms that we have available for performing change detection. 09:36.420 --> 09:40.540 Now what we're going to talk about is the angular lifecycle hooks. 09:40.650 --> 09:45.600 Let's talk about in detail about all these lifecycle hooks that we have seen so far, such as energy 09:45.810 --> 09:47.100 need energy to check. 09:47.130 --> 09:52.590 Let's talk about the order point, which they're called and the typical use cases where we will need 09:52.590 --> 09:54.210 them before going any further. 09:54.210 --> 09:55.650 Let's do a bit of cleanup. 09:55.650 --> 09:58.590 Let's remove here to the implementation of the check. 09:58.770 --> 10:00.200 We don't need unperceived. 10:00.290 --> 10:05.840 Detection anymore in our application so we can remove these can also remove here the change detector 10:05.840 --> 10:10.820 reference and let's remove here the implementation of the lower the flag. 10:11.000 --> 10:15.920 And with this small cleanup in place, let's not start a new section of the course. 10:15.920 --> 10:20.900 Let's start our deep dive into the multiple angular lifecycle hooks.