[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.