0:00
[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.
0:40
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.
2:20
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.
4:00
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.
5:25
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.
5:40
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.
5:58
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.
6:58
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.
8:14
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.
9:08
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.
9:44
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.
10:46
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.
11:12
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.
Yaakov ChaikinAdjunct Professor, Graduate Computer Science
