0:00
[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.
5:04
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.
6:58
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.
8:05
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.
9:06
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.
Yaakov ChaikinAdjunct Professor, Graduate Computer Science
