Lecture 53: Coding Up $http Interceptor

Loading...

Del curso dictado por Johns Hopkins University

Single Page Web Applications with AngularJS

1469 calificaciones

Johns Hopkins University

Single Page Web Applications with AngularJS

1469 calificaciones

Curso 5 de 6 en SpecializationRuby on Rails Web Development

Do you want to write powerful, maintainable, and testable front end applications faster and with less code? Then consider joining this course to gain skills in one of the most popular Single Page Application (SPA) frameworks today, AngularJS. Developed and backed by Google, AngularJS is a very marketable skill to acquire. In this course, we will explore the core design of AngularJS 1.x (latest version of AngularJS 1), its components and code organization techniques. We will enhance the functionality of our web app by utilizing dependency injection to reuse existing services as well as write our own. We will create reusable HTML components that take advantage of AngularJS data binding as well as extend HTML syntax with a very powerful feature of AngularJS called directives. We’ll set up routing so our SPA can have multiple views. We will also learn how to unit test our functionality. At the end of this course, you will build a fully functional, well organized and tested web application using AngularJS and deploy it to the cloud.

De la lección

Module 5 - Form Validation, Testing, and Restaurant Site Development

Welcome to module 5! This is the last module in the course. We'll start this module by learning just how easy it is to validate forms with Angular. We will then delve into unit testing our AngularJS code. We will go over how to set up tests for every type of major Angular artifact: controller, service, directive, and component, as well as how to test services that access the network through the HTTP service. However, the last part of the module is the most fun. We will take the site that was developed for our real client in my previous course and re-write the entire thing using AngularJS. However, the coding fun doesn't have to stop there. After you finish the required part of the course, you can move on to the optional bonus part where we take our newly developed AngularJS application and enhance with it even more features that will allow the restaurant owners to administer their own data. We'll go over setting up authentication, editing restaurant menu items, uploading menu item pictures and so on.

Lecture 51, Part 1: Basic Structure of the Restaurant App3:30

Lecture 51, Part 2: Basic Structure of the Restaurant App14:21

Lecture 52: Coding Up a Loader/Spinner6:54

Lecture 53: Coding Up $http Interceptor11:04

Lecture 54: Coding Up Menu Categories View - Part 19:34

Lecture 55: Coding Up Menu Categories View - Part 213:12

Lecture 56: Coding Up Menu Categories View - Part 310:48

Lecture 57: Single Category View - Part 14:42

Lecture 58: Single Category View - Part 211:05

Lecture 59: Single Category View - Part 313:23

Course Wrap-Up1:54

Conoce a los instructores

Yaakov Chaikin
Adjunct Professor, Graduate Computer Science
Whiting School of Engineering

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

Explora nuestro catálogo

Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.

Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.

© 2019 Coursera Inc. Todos los derechos reservados.

Descargar en la App Store

Consíguelo en Google Play