In my first blog, Basic AngularJS with Routing [Part 1], I discussed AngularJS Controllers with examples. In the second blog, Basic AngularJS with Routing [Part 2] I delved into Directive and Services. In this blog, I will deep dive into Routing.
What is Routing?
At a high level, here is what Routing is all about. You are building an application and you cannot put all the functionality that you need into a single controller in a single view. You have different features and you need different areas inside the application. That is going to require multiple views, multiple controllers. Each view and controller is responsible for a specific feature or area of functionality, and now that you have functionalities spread around, how do you know where the user is located in your application, how do you know what is supposed to be on the page, what are they seeing? Are they trying to view the details about a user, or are they trying to view the details about a repository for some user? And the first question is; how do I know the location of the user?
While the browser does have the concept of a URL, a Uniform Resource Location that is what appears in the address bar. We usually think of the URL as a way to reach some resource on the server, but when building an application with Angular, you can also start thinking of a URL as being able to locate the resource on the client too.
Routing with Angular
Here is how Routing works with Angular. First, we are going to need another script from the Angular code base; it’s called angular-route.js. This will give us access to a new module, a module that our application module will need to take a dependency on; this new module is called ng-route. Using a component in ng-route, we will configure our routing rules into the routing engine. Remember, this is where you describe the URLs for your application. You have to tell the routing engine how it should respond to a particular URL that appears in the browser. With ng-route, this is done using a component known as $routeProvider. It has an API where you describe what the URL looks like and then what to do for that URL. For each URL you can specify a templateUrl that is the HTML that Angular has to go and find and load up for that route, and then optionally a Controller that should be used to manage that template. And because the routing engine has to take that template and load it into the display, we are going to need to reorganize our application and our default.html file.
Our default.html file will become what some people call a layout view, or a shell view. A layout view is a view that contains the markup you will use on every page of your application. It might include some common features, like a navigation menu at the top that’s going to appear everywhere in your application, and perhaps a foot at the bottom that contains links to contact you and a copyright, but there will be space somewhere in that layout view, where the routing engine can load a template that corresponds to the current URL.
So let’s say we have two templates available; one to display userDetails and one to display repository details. We will tell the routing engine where to place these templates using a new directive, an ng-view directive. We will use that directive on an HTML element and it is that HTML element where Angular will insert the template when we’re at the right URL. And now, as the user clicks and navigates and enters information and saves information, the routing engine will swap out one template with another template inside the shell view, and our application is now scalable; it can support any number of templates and controllers. The routing engine is going to swap them in and out. When it does that, it will also coordinate with the browser history, so that if the user hits the Back button or the Forward button, they will still be navigating just inside of your application. So we have a little bit of work cut out for ourselves, but let’s try this out now.
Step1: provide link to angular-route.js in layout page
The first thing I will do is make sure I go out and add, that angular–route script that I can find if I do a Search for angular-route. Now you notice I get a couple Search results here, angular-route and angular-router. It’s angular-route that I want, it has the most up-to-date version of angular-route. I’ll just click the button, and that will add an additional script file for me in my page. This one going to code.angular.js, and it’s picking up angular-route.js. And now that we have that script included, the next step would be to set ourselves up so that we can configure the routing engine. One place we could do that, is inside of script.js where we create a githubViewer module, but script.js is already a little bit full. It’s really where we have MainController defined. So I would like to remove the creation of this githubViewer module from script.js and move it to the new file where we will create that module and also add the configuration. So, create a new file, this one I’ll call app.js because this is really what’s going to define the application, and it’s inside of here where I can have an IIFE, where I can have a line that will define the module, and what we’re going to find is that we can run and register configuration functions against our application, and inside of this configuration function where we can define our routes. And now that’s cleanly separated out from script.js, which is just going to get a reference to githubViewer.
Step2: Define the user for different controllers and views
Step3: On search of username, route to another controller “UserController”
Step4: In UserController define the logic to get the user details.
In the three blogs, we saw how Angular is a framework for building applications with HTML and we took a look at the primary components involved, including Controllers, Models, and Services. In this last blog of the series, we looked at Routing in detail. The primary takeaways for Routing are that Routing allows you to build navigation into your application and it also allows you to build an application from smaller pieces. You can divide responsibility for your features amongst multiple controllers, models, views, and services.