[MUSIC] Okay, so we're continuing in our code editor and I'm in Lecture53 folder which is located in fullstack-course5/examples folder. In the previous lecture, we coded up our loading.component.js to turn on when somebody throws a spinnerActivate event with the data on equals true. And that's going to show us a little spinning icon fixed in the middle of the screen. Now the question is, who is going to throw this spinner:activate event? We could try to throw the spinner:activate event everywhere in our system whenever we see that something Is asynchronous is about to happen. For example, when we try to pull data from the restaurant server, right before we do that we could throw the spinner event with the on equals true, and then after it returns in handling our response, or our promise, we could throw another event with the spinner activate with the on property equals false. And I think that'd probably be okay, however, we have a couple of issues with that. Number one is, is that we would actually have to remember to sprinkle it all over our code whenever we are trying to use the $HTP service. Number two is, there are times when we use the http service without even knowing ourselves about it. For example, if we go to the public module and look at our routes, you'll see that for example when we go to this State public and especially public.home it will pull in this home.html will actually first pull in public html and then will pull in home.html. The requests for these snippets of html are are actually asynchronous calls that are made by angular using the $http service. So we don't one have in this case kind of a normal ability to tell it go ahead and turn on the spinner and turn off the spinner. Well it happens to be that the $HTTP service provides an ability for us to configure it to actually plug in to the entire lifecycle of sending the request and receiving the request such that we can kind of catch the request as it goes out and catch the response as it goes back in. And those are called interceptors, and this is what we’re going to have now. And inside of our common loading folder here, we’re going to create this file called, loading.interceptor.js. And basically this is our interceptor, so let’s go, over what this does. An interceptor is a factory, meaning it's going to create this function for us and wait for the return value from this function. And in this function, you can see has a return value, and that's in itself an object. So if we place a cursor here, you could see that this whole thing is just one object literal right here, and this object literal has three properties. It has the request property, it has the response property and it has the response error property. So let's let's go over as to how we're going to code this up. The request property is expected to be a function that takes in a config object, and a config object in here on the request is basically everything that's going to be needed for the dollar sign HTTP service to make the request, meaning the URL the request headers, whatever else is needed to making that request. So when an HTTP service makes a request, it's going to first go to this function right here before actually going out and making a request. This gives us an ability to hook into the whole process and actually broadcast, make the rootScope broadcast our loading event which is this right here, spinner:activate, with the value on being true. That when the response comes back, we can again broadcast using the root scope, again, with that same loading event. But in this case, the on property is going to be false, so we could turn it off. And finally, if there's a response error, and the response error gets called when a previous interceptor either threw an error, because you can have more than one interceptor attached to the HTTP service, or it resolved the rejection. So something went wrong in the previous interceptor and it basically is receiving back an error. So we can heal that error by first of all, since we're, when we made the request it turned it on through the event where the on equals true. Now that we got an error we know we can turn off the loading indicator so we can again, broadcast that loading event named with the on property equals false. And the last thing we need to do inside the response error function is that we need to reject the promise. All of this is being done with promises and if we don't reject this response, this call will still return to the caller but it will look like our promised result successfully which is not the case. The caller will then erroneously assume that the data being returned is the data it's looking for instead of the error. That will obviously cause all kind of issues, so that's why we need to explicitly reject the response here. Now one last thing that you'll notice that may look a little confusing is this loading count. And you could see that we're actually adding to the loading count and figuring out whether or not it's one. And in the response we're subtracting from the loading count and then seeing if it's 0 and the same thing in the responser, we're first subtracting from it and seeing if it's 0. Why are we doing that? Well, the reason we're doing it is because since these request are asynchronous it is totally possible and in fact happens all the time when a few requests happened at the same time. So for example, the HTTP service can be loading a few templates at the same time and making a few requests at the same time. We wouldn't want to turn it off completely when the first request came back while the second request is still pending. Which means we need a counter, an increment counter every time there's a new request and a decrement counter every time one of the requests comes back. So, as long as we still have pending requests, this loading indicator will still keep going and we will not throw another event with the on property equals false. We we will wait until we decrement the counter to the point where there is nothing loading at all, so it's a 0. And then, we'll broadcast that you can go ahead and turn off. So that's our interceptor, just for fun here, I actually put in a logging statement, so we could see what it inside of config after we hook it up. So we could save that now and at this point, all we have is a factory. We just create a factory on the common module. We really haven't done anything at all to the $HTP service. Let's go to the module, to the common.module.js, and go ahead and configure the HTP service provider. The way we do that as you remember, we just say config. And we call, let's call it a config function. And now we need to define this config function, config.$inject, and what we need to inject is a HTTP provider, $httpProvider, because we need to configure that provider. So we'll say function config, Http provider. And now we need to add to the http provider's interceptors array. The http provider service has a special property called interceptors that holds an array of all these interceptors that when the http service goes out to do its job it first checks that array to see if it needs to have one of the interceptors work its magic on one of the requests or the responses before it actually goes through with the request. So let's go ahead and configure httpprovider.interceptors, plural. And that's an array, so we'll push, and what we'll push is the name of our interceptor. And that is LoadingHttpInterceptor. So, that's the name that we need to push on here. So, now our http provider is going to have an interceptor, loading http interceptor as part of its request and response system. So, let's save that, let's go to index html to make sure I actually included at the very bottom, the loadinginterceptor.js. And let's save that now, and remember the interceptor had this inside the request property or function that is the request property. Where this console log and we're basically outputting this config object that the interceptor is being called with. So let's go back to our browser. I already started browser sync inside the lecture 53 folder and, so here we are on our browser. So if we reload right now, we should, at least momentarily, see the spinning icon here. Let's do Ctrl+R or Cmd+R on Mac. Yes, and I don't know if you caught that, but we saw the little loader, they're in the middle. Now let's go ahead and open the console. And let's go ahead and do another reload, so we could just see that. And you can see inside the interceptor config, and there's two of them and let's take a look at it. Let's open that object, that config object. And you can see there's headers, we can see a bunch of headers here inthis case it's just accept HTML. Text/html and you could see that it's showing us the URL property on that config object and the URL is src/public/public.html. Well guess what? That's from the template URL inside the public routes.js. And the second object here, let's open it up, sure enough it's going to be src/public/home.html. We go back to our public.routes.js, you'll see that these are the two template URLS, template URL properties that are in there. So you can see that as the http service is going out to pool or to request this html snippet files from the server, it's making a http request and our interceptor intercepts thata and is able to throw an event, a loading event, and then when that request resolves and comes back, it's able to throw another event with the on property equals false. So for now I'm going to go ahead and just comment it out, and leave it for you so you can uncomment it later and mess with it. But we don't need this constantly going out to our console, so we'll leave it off. Okay, so now we have an interceptor. An interceptor intercepts our requests and responses. It is able to throw these events that turn on and off our loading indicator that is happily sitting inside of our index.html. And the loading indicator is a component we previously coded That is listening for these events that we're throwing and turning itself on and on, or turning on the image tag, on and off, inside of our page.
