Explore
For Enterprise
Join for Free
Log In

artes y humanidades
Negocios
Ciencias de la Computación
Ciencia de Datos
Tecnología de información
salud
Matemáticas y Lógica
Desarrollo Personal
Ciencias Físicas e Ingeniería
Ciencias sociales
Aprendizaje de un idioma
Grados
Certificados

Explorar todo lo que Coursera tiene para ofrecer

Explorar
Buscar
For Enterprise
Inicia Sesión
Únete de forma gratuita

Lecture 36, Part 1: Routing

Loading...

Single Page Web Applications with AngularJS

Universidad Johns Hopkins

4.9 (1,480 calificaciones) | 60K estudiantes inscritos

Curso 5 de 6 en Ruby on Rails Web Development Programa Especializado

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.

Destrezas que aprenderás

Unit Testing, JavaScript, Angularjs, Web Development

Revisiones

4.9 (1,480 calificaciones)

5 stars
1,358 ratings
4 stars
101 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.

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.

Lecture 36, Part 1: Routing12:03

Lecture 36, Part 2: Routing15:54

Lecture 37, Part 1: Routing State with Controller2:00

Lecture 37, Part 2: Routing State with Controller7:38

Impartido por:

Yaakov Chaikin
Adjunct Professor, Graduate Computer Science

Transcripción

[SOUND] In this video,

we're finally going to address a topic that takes up the majority of the title of

this course, single-page applications.

Even in a simple app,

you'll probably have at least a couple of different views, where the majority of

the content on the page will have to be replaced with some other content.

One way or another,

users need to be able to get from one view in your application to another view.

Let's first take a look at some diagrams of traditional approaches to this feature

and then talk about the single-page application approach.

In the Traditional Client-Server Communication, as they started calling it

Web 1.0, any update whatsoever that the browser needed was handled by the server.

For example,

the browser would start out by requesting a resource at the URL /page1.html.

The server would evaluate the request, find the resource at that URL, and

then respond with the contents of some file, probably named page1.html.

If the user clicked on some button that required some minor update to the page,

even as little as updating someone's name and

some greeting, the browser would make another request to the server.

This time attaching some data or

request parameters to the end of the original URL, in this case id=3.

The server would process the request and

then send the entire page 1.html content all over again, but

with an updated name probably corresponding to the ID with a value 3.

Such updates are called coarse-grained updates because of the large chunk of

data that had to travel through the network for even the smallest updates.

As you can imagine, this was a slow experience for

the user and also clogged up the network quite a bit, passing around,

essentially the same content, over and over.

If the user clicked on a link pointing to /page2.html,

the browser made another request to the server.

The server would process the request and

then return the contents pointed to by the URL as page2.html.

You can see that, in this model,

the routing from field to another was clearly a server side responsibility.

With the introduction of AJAX, this picture improves quite a bit.

Now, when the browser needed a small update to the content,

it already downloaded from the server previously.

It used AJAX to make a background request to the server,

which only returned the needed data.

This obviously improved user experience quite a bit.

Updates felt faster, and the server was considerably less taxed,

no longer trying to serve thousands of users by reserving the same content to

the same user over and over.

It was now the browsers job through JavaScript to take the data in this fine

grained upgrade and

dynamically insert it into the page that was already on the user screen.

However, there was a disadvantage with this approach.

First, if the user wanted to go to the previous state of the view,

before they clicked on something, that made a role to remind UI update.

The good old back button on the browser would not work.

In fact, if there was something in their page browsing history already, they would

simply leave this page altogether and move to the previous page they were on.

I don't want to harp on this too much,

since this is not a user experience class, but this is a big deal.

It's a big deal because it breaks the way pretty much

any user expects to interact with your web application.

The reason this was happening was because it was still the server, not the browser,

that was responsible for the routing from view to view in the web application.

It was still the case that,

if the user clicked on a link that requested /page2.html,

the server had to find that route and return the content pointed to by that URL.

In the single-page application, or

SPA model, the beginning of the client's server interaction is the same.

The browser requests some index.html,

and the server responds with the content which comes along with CSS and JavaScript.

When the user clicks on the URL that's supposed to take them to a new view,

the URL is constructed with the same index that HTML is before, but

it gets followed by a pound sign.

That does not cause the browser to request anything from the server, but

can be detected by JavaScript in that process.

Part of that processing might be making an AJAX call to the server to retrieve

the relevant template for the view, but it doesn't have to be.

Same goes for

another click, which can encode some data like ID equals 3 under the URL.

The JavaScript in the browser is what processes the URL change.

Using the pound sign or the hashtag works for

a browser-only routing because the hashtag on the URL does not

cause the browser to re-request the resource from the server.

Traditionally, the hashtag was used to cause the browser to

automatically scroll to a section of the page where the element with the ID or

the anchor tag Was marked with the name of the hashtag.

We discussed this topic in my other course Called HTML CSS and JAVA Script for

Web Developers.

So look there if you're interested in learning more on this topic.

Note that the hashtag, Hashtag also changes the URL and

the browser's address bar thus aiding another entry into the browser's history.

This is why the browser's back and

forward buttons work naturally with this type of setup.

The truth is that nowadays, these URLs can even work without the hashtags

when you configure the server to be in what's called an HTML5 mode.

We're not going to mess with the server in this course, so

we'll stick with using the hashtags, but just so you know that that is possible.

There's another way to approach navigation from one view to the next.

This approach does not depend on the URLs whatsoever.

In it, we represent each view as a view state.

In other words, we represent the view using some JavaScript object

that holds the data to reproduce the same visual setup over and

over, Including the data associated with that state.

This is a much more generic way of approaching the whole idea of

representing the state of a user interface at some particular point in time.

If you think about it, all URL did was encode the state of our user interface

with a unique string called a URL.

But we should in get stock on that,

we can encode the save data using a Java Script object in simply tell on

navigatius system to recreate a user interface base of an object.

So the point such setup is that your role on the browser address bar is not updated

only programmatic state of the view is a updated.

Now there are options when it comes to which package you use for

your routing implementation in an angular JS app.

I'll describe two of the most commonly used ones.

One is called ngRoute and the other ui-router

ngRoute gets installed in your application as a separate JavaScript file.

It is not part of the core of angular JS.

It is developed by Google and

the Community meaning it's open source, but it has no concept of a UI state.

Every route must be represented by a URL.

There's also no concept of a nested view, and

those couple of features leave it for an okay router to use for

prototyping projects How ever for more full feature type of implementation.

Ui-router is the choice.

It is also made as a separate JS file and it is not develop by Google but

simply as a open source project that's develop by the community.

In ui-router, UI state is a central concept.

In fact you can have a route with no unique URL for that route whatsoever.

However, URL routing is is also supported so

you can have a state that is associated with a particular URL.

Now, a UI state is updated based on that URL.

Also, nested views are supported.

And if you don't know what that is, you will see that in a few lectures.

And you'll understand their power and why they're so

important to use on a day to day basis.

So all in all, that's really a better choice for more serious projects.

And that's why we're going to cover ui-router in this course.

Truth be told is that when you know how to use ui-router using NG

package would be very easy familiar.

It's always possibly living Since it lacks some of the really nice features

which is described..

Let's go over the steps of using some of the basics of ui-router.

The first step is to reference the UI router package in our HTML.

Since UI router depends on the core angular package it

needs to be referenced and loaded by the browser after the core angular package.

Step two is to designate some part in our HTML page

where our interchangeable view can be dynamically placed.

When the view of our particular state is loaded it will be inserted into

body of the UI router provided custom directive called ui-view.

The third step is to declare the ui router as a dependency.

This is fairly straight forward.

We have seen how to declare other modules as dependency before.

Note that the name of the modules is ui.router,

slightly different Then the name of the project itself uses a dash.

Since UI router handles UI states in routing through a URL as two independent

functions, it all makes sense why it comes with two essential services,

dollar sign state and dollar sign UI router.

However, before we can use the state and

URL routing services,we need to preconfigured them

with some knowledge about the states and URLs in our application.

You already know how to do this.

You use the the Angular.config method and

inject the provider versions of those services into it, so

you can configure what data those services will be instantiated with.

First we configure our UI states.

We give each state a unique name that we'll be able to refer to

throughout our application.

We can also optionally associate a URL with a particular UI state.

Finally we specify an HTML template,

the contents of which will be inserted into the UI view tag in our HTML page.

You could also specify a template URL property and

just like in other configurations the contents of this URL will be

retrieved from the server using AJAX if and when this state is activated.

And then insert it into the url view tag.

The state method is chainable so you can continue to specify other state by

simply executing another state method right after the first one and so on.

Now it's very common for users to mistype a URL or have an outdated or

just a garbled URL for something.

A very common practice is to configure the URL router service provider

By executing it's otherwise method.

This configuration tells the UI router that when it tries to match a browser URL

with a URL associated with a particular declared state and it can't

find any matches, it should default to the URL declared in the otherwise method.

In this case any URL that URL router cannot match will default

to the URL/view1, which happens to be associated with the view1 state.

Okay that's pretty much it for the configuration.

Time to jump into the code editor and try this out in action.

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

Coursera
Acerca de
Liderazgo
Empleo
Catálogo
Certificados
Certificados MasterTrack™
Grados
For Enterprise
For Government

Comunidad
Learners
Partners
Developers
Beta Testers
Translators

Conectar
Blog
Facebook
LinkedIn
Twitter
Instagram
Youtube
Blog de Tecnología

Más
Términos
Privacidad
Ayuda
Accesibilidad
Prensa
Contacto
Directorio
Afiliados