Explore
For Enterprise
Join for Free
Log In

Artes e Humanas
Negócios
Ciência da Computação
Ciência de Dados
Tecnologia da informação
da saúdesaúde
Matemática e Lógica
Desenvolvimento Pessoal
Ciência e Engenharia Física
Ciências Sociais
Línguas
Notas
Certificados

Explore todo o Coursera

Navegar
Pesquisar
For Enterprise
Entrar
Inscreva-se gratuitamente

Lecture 34, Part 2: AngularJS Event System

Loading...

Aplicativos web de página única com AngularJS

Universidade Johns Hopkins

4.9 (1,478 classificações) | 60K alunos inscritos

Curso 5 de 6 no Desenvolvimento Web com Ruby on RailsDesenvolvimento Web com Ruby on Rails Programa de cursos integrados

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.

Visualizar o programa do curso

Habilidades que você aprenderá

Unit Testing, JavaScript, Angularjs, Web Development

Avaliações

4.9 (1,478 classificações)

5 stars
1,357 ratings
4 stars
100 ratings
3 stars
13 ratings
2 stars
4 ratings
1 star
4 ratings

NO

Sep 18, 2016

My special "thank you" for going deep inside the subject with your "how?" and "why?", instead of just instructing us "do this and that". It's a real pleasure to participate in your class, thank you!

DR

Sep 18, 2016

This is an excellent course. The lectures are clear and very well-prepared. The course material is excellent and Yaakov is an excellent presenter: very informative and engaging. Highly recommended.

Na lição

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.

Lecture 34, Part 1: AngularJS Event System8:56

Lecture 34, Part 2: AngularJS Event System14:53

Lecture 35, Part 1: Modules7:21

Lecture 35, Part 2: Modules10:41

Ministrado por

Yaakov Chaikin
Adjunct Professor, Graduate Computer Science

Transcrição

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

Explore nosso catálogo

Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.

O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.

© 2019 Coursera Inc. Todos os direitos reservados.

Baixar na App Store

Baixar no Google Play

Coursera
Sobre
Liderança
Carreiras
Lista de cursos
Certificados
Certificados MasterTrack™
Notas
For Enterprise
For Government

Comunidade
Learners
Partners
Developers
Beta Testers
Translators

Conectar
Blog
Facebook
LinkedIn
Twitter
Instagram
YouTube
Tech Blog

Mais
Termos
Privacidade
Ajuda
Acessibilidade
Imprensa
Contato
Diretório
Afiliados