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