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.
Lecture 34, Part 2: AngularJS Event System
Loading...
Del curso dictado por Johns Hopkins University
Single Page Web Applications with AngularJS
1429 calificaciones
Explore Related Videos
At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you
Johns Hopkins University
1429 calificaciones
Curso 5 de 6 en SpecializationRuby on Rails Web Development
De la lección
Module 4 - Components, Events, Modules, and Routing
In this module, we start by introducing the idea of Component-based architecture. We will then delve into the AngularJS component API. The component API is something that was just recently added into Angular 1 and it's not only supposed to improve your application through the use of Component-based architecture, but also prepare you for an upgrade to Angular version 2, which uses components almost exclusively. We will then learn about the AngularJS event system and how to split up our application into smaller modules that can then be glued together to produce our final application. We'll finish off the module by diving fairly deep into Routing between views in your application and, specifically, into the use of the ui-router module, which is one of the most popular open source routing solutions within the AngularJS ecosystem. In fact, it's so popular that even the main Google documentation for routing in Angular links to ui-router. Routing is a very important topic. Without it, your Single Page Application is stuck displaying just 1 view, without an elegant way to display other views.
Conoce a los instructores
Yaakov ChaikinAdjunct Professor, Graduate Computer Science
Whiting School of Engineering
[SOUND] Okay, we're back to our co-editor and
I'm located in lecture 34 which is located in
full stack dash course five examples folder.
And this is once again our shopping list application which is
now called shopping list events app.
There are many times in applications When there's some asynchronous communication
going on.
And while that's taking place, because usually that takes a little bit,
you need some sort of spinner or
some sort of graphic to tell the user that something is going on and he should wait.
So what we're going to do is, when a shopping list item is added to
the shopping list we're going to kick off a whole bunch of asynchronous actions.
Each of which will check whether or
not a particular item in the list A list contains the word cookie or not.
Now, since there could be more than one item in that list,
we can have more than one asynchronous action being fired.
However, while those asynchronous actions are being resolved, we would like to show
some sort of indication to the user that something is going on.
So we're going to display a loading spinner that is actually going to be our
flicker button and
if you've heard our flicker.com this is what their loading icon is like.
And since we didn't really know where this particular behavior is going to reside
We're going to place our loading spinner component.
Yet another component, we're going to have an application,
we're going to place it outside of our controller.
So, it's not even inside of our shopping list controller, as you could see the div
ends right here, it's actually sitting completely outside of it.
But it is still sitting inside of the ng-app directive,
which means it's inside of our Angular application.
So let's go to our app.js and take a look at the code.
Let's actually minimize the file browser so be a more room here.
So as you could see we have one more component called loadngSpinner and
all the component has a spinner.html template url and a SpinnerController.
Well, the template URL for it's spinner.html Is very simple.
Is just an img tag and it has as ng-if in it meaning it will get
shown this img will be part of the dam if this $ctrl.showSpinner is true.
Otherwise it will say false and the entire img tag will be pulled out
from the dam rendering going back to our you see we have a starter here.
We started our SpinnerController and we injected the rootScope and
you will see why in a minute and this is just a starter one.
Let's take a look at A very important part of the code
which is inside this ShoppingListComponentController.
That's the thing that displays the shopping list and
we injected a couple of things here.
We injected our q service, if you remember from when we spoke about promises and
we also injected this weight loss filter service.
That's an asynchronous service that checks for
names of the shopping list to check to make sure there are no cookies in it.
And we're going to invoke that service inside the $doCheck again,
$doCheck get involved every time through the digest loop.
And therefore, we could check whether or
not our number of items in our item changed.
And if it did, it means it is time for us to check whether or
not there are cookies inside of our shopping list.
Before however when we make that Asyncernous call to our
loss filter service, we're going to broadcast an event.
And notice that we're broadcasting an event using the root scope.
And the reason that is, is because the component that needs to catch that,
is a loading spinner, and it's completely not in our path of optiscope chain.
So therefore, we go back to the We using a root scope so we're starting from ng app
starting from the very top component and we're broadcasting that event down.
And the event is called shopping list call on processing and
the only data we're passing really we're mostly for
show here is on the property on in the object and its value is true.
So what this event should trigger somewhere, somewhere in application,
we don't know where, and we don't care.
Is it should show some sort of a spinner to the user saying hey,
we're processing or maybe do some other things as well.
But in our, for our purposes, all we needed to do is actually show the spinner,
so the user knows something is going on.
Then, we're going to use our $q.all and the way we're going to do that is,
we're going to loop over every item inside of our items array.
And for every item, we're going to call this WeightLoss Filter service and
call its, method called check name which returns a promise.
And will going to push every single promise into this promises ray.
As you can remember the queue service dollar sign queue service.
All takes an array of promises and then it can deal with them all at once and
that's actually what we want.
We want them to be asynchronous and all of them to be parallel at the same time.
And the reason we want that is because even if one fails which means if even if
one fails it means that we detected a cookie in there.
And we're going to go to this catch block the rest of the promises will get
cancelled automatically right there on the spot.
So the first time it detects a cookie, the rest of them will get cancelled.
And what's going to happen is it's going to do this jQuery stuff we've seen before
where it's going to find the element with that error message and go ahead and
slide it down.
And if all of them come back with a positive result, which means none of
the items in the shopping list actually contain the word cookie.
Then we're simply going to remove the error message if it's in there.
In either case however, whether it's good or not we have a finally block that will
broadcast yet another message using the dollar sign root scope service.
And will broadcast shopping list processing and
on with the value of force which means we've done.
We have completed all of our asynchronous communication.
Nothing else is being process, so therefore,
go ahead and turn off that spinner.
Okay, so we've set up broadcasting the on event when the spinner should turn on.
And we've set up the broadcasting of the event
that the spinner should turn off at the end of all this asynchronous processing.
Let's go to our actual spinner controller and
implement the event listener to catch those events.
So the first thing we're going to do is we're going to go ahead and
use our $rootScope that we injected right here into our controller.
We're going to call this $on method and the $on method is going to look for
shoppinglist all lowercase processing.
That's the name of our event and we need the handler function.
But I need the name and it's going to pass us event and data.
Okay, we'll put a semicolon here and now we could actually log what the event is.
So event and we'll log what that is and we'll also log what the data is.
Okay, now let's go to our browser and browser sync is already started,
it's going to open up our console.
And let's go it and add something like chips two bags of chips and
we'll click add.
When we do that, you can see a couple of things happen.
Number one is the first event gets fired and
that event is an object.You can see it has a name.
The name of the event is shopping list processing and
you can see the data as well that was broadcast to the entire tree,
really, which is this object with the property on.
And a value of true but you could see that there is yet
another event that got broadcast.
And another Event that got broadcast was, again, shoppinglist:processing,
except with the object that it broadcasted was on false.
So the first time when we started processing was this event.
When the processing was over, this event was broadcast.
Both of these events however were caught inside
of our SpinnerController right here.
That's where we printed that out, the next step is fairly simple,
we just have to check if data.on because that's our on property.
If it's true that means we want to turn on the spinner and that's easy.,
It's just ctrl.showSpinner = true.
And otherwise else Our Sctrl.showSpinner = false; Let's go ahead and save that.
Let's go back to our browser and let's go ahead and try it.
Let's say chips, 3 bags of chips, we'll click Add.
And we can see right there it's processing, so it's showing us.
And once the second event comes in that icon disappears and
if we say, let's move this down a little bit.
And if we say cookies, the dreaded cookies,
3 bags of the cookies and we click Add, yet again it's processing.
Now it's processing two events or two items in the shopping list and
it comes back with cookies detected.
So if we remove that again once I remove it,
it has to once again trigger the whole broadcasting which is what it does.
And again, it's checking to see that there's no cookies in here and
once it comes back it turns off our animating icon,
there's actually one more thing to do.
If you take a closer look, this spinner controller and this spinner component all
together, this loading spinner component, will work very well in this view.
But what happens if I switch views And comeback to it and
then switch and comeback to it.
Every time it may comeback to it, we're going to have $rootScope.$on, so
which means every time we will register this event listener and
there is really no code to go ahead and destroy this.
This will be different if I just said just set something like this scope, why?
Well because every time that this view gets destroyed
this scope gets destroyed with it and anything that's attached to it.
However, root scope is never destroyed until the entire application is destroyed
and here we have potential for a really nice memory leak.
Because every time we come here this on is going to get executed but
nothing actually de-registers it.
Well, we'll learn of this handy method in the controller nowadays and
the components called controller.$onDestroy.
So when this is going to get destroyed,
when the scope of this control against destroyed.
We want to trigger the destruction of this listener as well and
the way we could do that is to say this is a function.
But I need the name of it and what we need is we need to some how get ahold
of the function that registered this entire listener and
the way we could do it is fairly simple.
The $on function actually returns a deregistration function.
So all we have to do is say var cancel
Listener and we'll make that equal to that.
And in here, since it's a local variable that we can access, we'll copy that.
We'll just say cancelListener, and now that we know that it's a function,
what we need to do is put parentheses behind it put a semicolon and save that.
And now, every time this view gets destroyed, and the scope, the dollar sign
scope that belongs to this controller and belongs to this component gets destroyed.
Will also at the same time de-register our rootScope.$on,
so it will not hang around even though we're no longer using the scope.
Let's go ahead and check out to make sure things are working.
Let's put chips, chips, four bags of chips, and add that.
That seems to be working, it should turn off in a second.
Yes, it did and now we're going to put cookies,
let's make it five bags of cookies, we deserve it and there you go.
That's spinning and at the same time at the end, bam, it says cookies.
If you remove it,
it will once again start spinning to check the items on the shopping list.
We will see that the cookies are not there anymore, the spinner will stop and
the warning will go away as well.
Let's summarize.
In Angular, the publish-subscribe design pattern
is implemented using the Angular Events system.
You can publish events from anywhere in the system and likewise you could
listen for those events, and catch them, anywhere in the system as well.
There's a couple of ways of publishing events.
One way is to use the $scope.$emit that method sends the event up the scope chain.
The other way is called $scope.$broadcast and
that method sends the event down the scope chain.
Obviously, your message or event reachability of a particular node will
depend on where it is located in the scope chain structure.
Whether or not it's in the path of the $broadcast or $emit methods.
So if it's not in the path, or to really reach all nodes,
you use the $rootScope.$broadcast.
What that does is broadcast a message from the very top, where you declare ng-app,
which is really the root controller of our entire application.
And therefore everything an application inherits from it's scope and
therefore everything is in it's scope chain path.
To listen for an event, you either use the $scope.$on or
@rootScope.$on.
In either case,
what you pass into those methods is the name of the event you're listening for,
and you register a function that should be executed when that event gets triggered.
While if you're listening for an event using the $scope.$on,
there's really nothing left to do because when you destroy the particular view,
the $scope will get destroyed with it.
That is not the case with the $rootScope because that always lives
throughout your application.
So you must deregister the listener when using the $scope.$on.
The way you deregister the listener is simply capture the return value
of the dollar sign on method, which happens to be the deregistration function.
And then you hook that into the destroy method of your component, and
then calling that deregistration function inside of that.
If you were to skip doing that, you would leave the listener function registered in
memory Basically, for the rest of their life of this application.
And what's worse, as you keep coming back to this view,
new listener functions would be registered.
And more and
more of them would keep sitting in memory without anyway to reach them and
unload them from memory by deregistering their listening to the event.
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.
