1 00:00:03,580 --> 00:00:05,770 Hello, everyone, and welcome back. 2 00:00:05,770 --> 00:00:11,290 In this lesson, we are going to talk about Iraqi oil dependency injection we have been creating here 3 00:00:11,290 --> 00:00:17,590 our Courcy service dependency by declaring here a provider at the level of the application component. 4 00:00:17,620 --> 00:00:23,770 Notice that the same way that we have defined this here, the level of the top level component of our 5 00:00:23,770 --> 00:00:30,520 application, we could also be clear here, another provider at the level of the course care component. 6 00:00:30,610 --> 00:00:36,700 If we try results, everything is still working as expected, but something is different in order to 7 00:00:36,700 --> 00:00:43,060 understand it, let's say over here to our courses service and have here some logging to the constructor. 8 00:00:43,060 --> 00:00:49,900 So we are going to log here to the council, a unique identifier that uniquely identifies a given courses 9 00:00:49,910 --> 00:00:51,310 service instance. 10 00:00:51,310 --> 00:00:53,350 Let's define here a variable. 11 00:00:53,350 --> 00:00:56,790 We are going to call it counter and we're going to initialize it to zero. 12 00:00:56,830 --> 00:01:02,000 Now, each time that the constructor gets called, we're going to go ahead and increment discounted. 13 00:01:02,170 --> 00:01:07,600 Now, here in the console log statement that we are about to write, we are going to write creative 14 00:01:07,600 --> 00:01:12,880 courses, service, and we are going to append here the current value of the counter. 15 00:01:13,090 --> 00:01:18,610 We try out this version of our application, try to guess what we're going to get here in the console 16 00:01:18,610 --> 00:01:19,810 if we expected. 17 00:01:19,810 --> 00:01:20,620 We are going to see that. 18 00:01:20,620 --> 00:01:23,650 We have here a series of logging statements. 19 00:01:23,680 --> 00:01:26,080 We can see that there is a lot of logging going on. 20 00:01:26,200 --> 00:01:28,870 Let's simplify a bit here to the logging. 21 00:01:28,870 --> 00:01:34,780 We are going to remove these logging statement here in our cursor component and leave only the logging 22 00:01:34,780 --> 00:01:36,880 here at the level of the constructor. 23 00:01:36,970 --> 00:01:41,860 So if we try this out, we are going to see that multiple instances, of course, this service were 24 00:01:41,860 --> 00:01:42,490 created. 25 00:01:42,500 --> 00:01:46,530 So a total of 11 instances, as we can see here. 26 00:01:46,630 --> 00:01:49,350 Now, what is exactly going on here? 27 00:01:49,450 --> 00:01:55,440 In order to better understand this, let's give to each coarsest service instance and identify it. 28 00:01:55,450 --> 00:01:58,360 And this is going to be a number to this identifier. 29 00:01:58,360 --> 00:02:03,850 We are going to assign the current value of the counter and we are going to bring this out to the screen 30 00:02:03,850 --> 00:02:06,370 at the level of the cursor components. 31 00:02:06,370 --> 00:02:12,460 So we assign to our ID here the counter value and we're going to remove this logging statement from 32 00:02:12,460 --> 00:02:16,450 the constructor where we switch here to our cost curve component. 33 00:02:16,450 --> 00:02:19,880 And we are going to quickly add back here this logging statement. 34 00:02:19,930 --> 00:02:25,630 So this is the closest service at the level of the course curve and we are going to concatenate these 35 00:02:25,660 --> 00:02:29,140 with the identifier of the courses service. 36 00:02:29,140 --> 00:02:33,370 These will allow us to understand what caused this service instance. 37 00:02:33,370 --> 00:02:35,830 Are we exactly accessing here? 38 00:02:35,890 --> 00:02:41,980 So if we try these out, what do we see here in the log that each instance of the course that we have 39 00:02:41,980 --> 00:02:44,800 here, several cards on the screen, we have Tinkertoys. 40 00:02:44,800 --> 00:02:49,690 Each instance has its own instance of the courses service. 41 00:02:49,690 --> 00:02:55,150 So there is sort of a global instance, of course, this service, which takes the value number one, 42 00:02:55,240 --> 00:03:01,120 and that is the one that is being injected here, the level of the service, the rest of the instances, 43 00:03:01,120 --> 00:03:07,170 two, three, four, etc., all the way until 11 are injected at the level of the cost curve. 44 00:03:07,360 --> 00:03:10,870 Let's further confirm that that is indeed what is going on. 45 00:03:10,880 --> 00:03:17,620 We are going to log here in the constructor of our application component, the course service instance 46 00:03:17,620 --> 00:03:18,910 that we are using here. 47 00:03:18,940 --> 00:03:27,100 So let's have here in our logging that this is the root component and let's append here the course service 48 00:03:27,100 --> 00:03:27,610 idea. 49 00:03:27,640 --> 00:03:32,350 So if we tried this out now, we are going to see that in the in the root component. 50 00:03:32,350 --> 00:03:37,090 We are injecting instance number one of the courses, service class. 51 00:03:37,330 --> 00:03:43,550 And then on each of the cards here in our list, we are injecting a different instance. 52 00:03:43,550 --> 00:03:46,480 So we have a total of ten instances. 53 00:03:46,480 --> 00:03:53,590 Of course, this service when instance is created here at the level of the root component and it's injected 54 00:03:53,590 --> 00:03:56,920 directly here in the constructor that's instanced number one. 55 00:03:56,920 --> 00:04:03,670 And then for each of the cards here in our culture, at least, we are creating an instance here that 56 00:04:03,670 --> 00:04:06,490 is unique to each of the course cards. 57 00:04:06,490 --> 00:04:09,550 And that instance is getting injected here. 58 00:04:09,580 --> 00:04:16,450 So what we have here is yet our technical dependency injection we have here and hierarchy of components 59 00:04:16,450 --> 00:04:22,360 we have here, the application component that is composed here of ten course card components. 60 00:04:22,360 --> 00:04:30,130 Each of these components has a provider's property, so each component has its own list of providers. 61 00:04:30,130 --> 00:04:37,180 Whenever a dependency is needed in a given component, the component is going to go through its providers 62 00:04:37,180 --> 00:04:42,520 and it's going to try to find a provider that provides the corresponding dependency. 63 00:04:42,520 --> 00:04:48,940 If the component has such a provider, then it's going to use it to create the dependency. 64 00:04:49,120 --> 00:04:53,290 So that will happen here at the level of the application root component. 65 00:04:53,300 --> 00:04:55,240 It needs Accorsi service. 66 00:04:55,240 --> 00:04:57,340 So it's going through the list of providers. 67 00:04:57,340 --> 00:05:00,460 It finds the provider for courses, service and then it. 68 00:05:00,530 --> 00:05:06,740 Instantiates the glass and receives it here as a dependency, the exact same thing happens here at the 69 00:05:06,740 --> 00:05:11,150 level of each Coast Guard component in order to create the component we need here. 70 00:05:11,150 --> 00:05:15,860 Accorsi service dependency, the component will go through its list of providers. 71 00:05:15,860 --> 00:05:23,750 It finds here a provider, and it uses it to create its own private instance that is not accessible 72 00:05:23,750 --> 00:05:25,640 anywhere else on this application. 73 00:05:25,790 --> 00:05:31,850 Now, the question is, what would happen if a given component would try to find a provider for a dependency 74 00:05:31,880 --> 00:05:36,920 and it would not find a provider in its own private list of providers? 75 00:05:36,950 --> 00:05:38,180 Let's see what would happen. 76 00:05:38,190 --> 00:05:43,850 So if we were lower the application, we are going to see that indeed this application is still working 77 00:05:43,850 --> 00:05:44,660 as before. 78 00:05:44,750 --> 00:05:50,870 But now if we open here to the console, we are going to see that there is only one instance at the 79 00:05:50,870 --> 00:05:53,480 level of the application, of course, is service. 80 00:05:53,600 --> 00:06:00,710 It's the one created here in route component number one, the same instance with a V number one. 81 00:06:00,710 --> 00:06:07,790 It's also being used in all the course card components we have here, 10 occurrences of the logging 82 00:06:07,790 --> 00:06:11,240 of the course service with idea number one. 83 00:06:11,270 --> 00:06:15,110 So what exactly happened here and how does this work? 84 00:06:15,140 --> 00:06:21,320 Well, what happened is that this component here tried to find a provider for the courses service dependency 85 00:06:21,350 --> 00:06:23,270 in its own list of providers. 86 00:06:23,360 --> 00:06:27,610 It did not find a provider that would satisfy that dependency. 87 00:06:27,770 --> 00:06:33,860 So it moved on to its parent component, in this case, the application component to see if there would 88 00:06:33,860 --> 00:06:37,100 be a provider that will satisfy the dependency. 89 00:06:37,160 --> 00:06:43,370 If that would be the case, then the course card component here, which is a child component of the 90 00:06:43,370 --> 00:06:48,760 application component, would then take its dependency from the parent component. 91 00:06:48,800 --> 00:06:53,270 So that is why this is called ineradicable dependency injection system. 92 00:06:53,270 --> 00:07:00,230 It's because there is an Iraqi of injectors that follows the Iraqi of the components themselves. 93 00:07:00,230 --> 00:07:07,850 So child components like the casket component will ask the parent components for their dependencies 94 00:07:07,850 --> 00:07:12,020 in case the component cannot create the dependency themselves. 95 00:07:12,050 --> 00:07:15,910 That will go all the way down until the root of the application. 96 00:07:16,040 --> 00:07:22,250 So if there are multiple levels of components and the dependencies needed in a deeply nested component, 97 00:07:22,250 --> 00:07:28,340 then that component is going to ask its multiple parent components for the dependency. 98 00:07:28,370 --> 00:07:34,820 And this will go on until the root component of the application and even further down the injection 99 00:07:34,820 --> 00:07:38,600 tree until the very root of the application. 100 00:07:38,750 --> 00:07:45,710 This means that the Iraqi oil dependency injection system allows each component to create its own dependencies 101 00:07:45,710 --> 00:07:46,700 if necessary. 102 00:07:46,880 --> 00:07:53,300 Now, when is this functionality useful in the case of the courses service, the service, other than 103 00:07:53,300 --> 00:07:59,300 the idea that we have created here just for troubleshooting purposes, does not really have any state. 104 00:07:59,540 --> 00:08:04,100 These are stateless functions that call the back end and return the result directly. 105 00:08:04,220 --> 00:08:09,170 There is no data stored here at the level of the courses service in those cases. 106 00:08:09,170 --> 00:08:13,360 These multiple instances, of course, service are interchangeable. 107 00:08:13,370 --> 00:08:17,360 There is no need to create multiple copies of this particular service. 108 00:08:17,490 --> 00:08:22,700 We can all share the same courses service that we can make a global application. 109 00:08:22,700 --> 00:08:29,180 Singleton But if, on the other hand, the service that we are injecting here does have some state that 110 00:08:29,180 --> 00:08:36,440 is private to a given part of the application, then in that case we might want to define here a provider 111 00:08:36,500 --> 00:08:43,130 at the level of a component and have that dependency objective and make sure that that dependency is 112 00:08:43,130 --> 00:08:46,210 not visible anywhere else on the application. 113 00:08:46,340 --> 00:08:53,360 Notice also that if we use a local provider at the level of a component, then the service is created 114 00:08:53,360 --> 00:08:57,400 by those providers are linked to the life cycle of the component. 115 00:08:57,680 --> 00:09:04,220 So when the component gets destroyed, those service instances are also removed from memory. 116 00:09:04,460 --> 00:09:10,430 Now that we know how the dependency injection system works and how can we manually configure here our 117 00:09:10,430 --> 00:09:17,270 providers, let's look at an alternative syntax for configuring our dependency injection system. 118 00:09:17,270 --> 00:09:20,090 We're going to talk about three Shakal providers.