An Introduction to Component Routing with Angular Router

This article is part 4 of the SitePoint Angular 2+ Tutorial on how to create a CRUD App with the Angular CLI.

Part 0— The Ultimate Angular CLI Reference Guide
Part 1— Getting our first version of the Todo application up and running
Part 2— Creating separate components to display a list of todo’s and a single todo
Part 3— Update the Todo service to communicate with a REST API
Part 4— Use Angular router to resolve data
Part 5— Add authentication to protect private content

In part one we learned how to get our Todo application up and running and deploy it to GitHub pages. This worked just fine but, unfortunately, the whole app was crammed into a single component.
In part two we examined a more modular component architecture and learned how to break this single component into a structured tree of smaller components that are easier to understand, reuse and maintain.
In part three we updated our application to communicate with a REST API backend using RxJS and Angular’s HTTP service.
In this part, we will introduce Angular router and learn how it can update our application when the browser URL changes and vice versa. We will also learn how we can update our application to resolve data from our backend API using the router.

Don’t worry! You don’t need to have followed part one, two or three of this tutorial, for four to make sense. You can simply grab a copy of our repo, checkout the code from part three, and use that as a starting point. This is explained in more detail below.

Up and Running
Make sure you have the latest version of the Angular CLI installed. If you don’t, you can install it with the following command:
npm install -g @angular/cli@latest

If you need to remove a previous version of the Angular CLI, you can:
npm uninstall -g @angular/cli angular-cli
npm cache clean
npm install -g @angular/cli@latest

After that, you’ll need a copy of the code from part three. This is available at Each article in this series has a corresponding tag in the repository so you can switch back and forth between the different states of the application.
The code that we ended with in part three and that we start with in this article is tagged as part-3. The code that we end this article with is tagged as part-4.

You can think of tags like an alias to a specific commit id. You can switch between them using git checkout. You can read more on that here.

So, to get up and running (the latest version of the Angular CLI installed) we would do:
git clone
cd angular-todo-app
git checkout part-3
npm install
ng serve

Then visit http://localhost:4200/. If all is well, you should see the working Todo app.
A quick recap
Here is what our application architecture looked like at the end of part 3:

In this article we will:

learn why an application may need routing
learn what a JavaScript router is
learn what Angular router is, how it works and what it can do for you
set up Angular router and configure the routes for our application
create a resolver to fetch the todo’s from our REST API
update our application to fetch the todo’s using our new resolver

By the end of this article, you will understand:

when and why your application may need routing
the difference between routing on the server and routing in the browser
what Angular router is and what it can do for your application
how to set up Angular router
how to configure routes for your application
how to tell Angular router where to place components in the DOM
how to gracefully handle unknown URLs
what a resolver is and what it can be used for
how to use a resolver to resolve data using Angular router

So, let’s get started!
Why routing?
In its current state, our web application does not take the browser URL into account.
We access our application through one URL e.g. http://localhost:4200 and our application is not aware of any other URLs such as http://localhost:4200/todos.
Most web applications need to support different URLs to navigate users to different pages in the application. That is where a router comes in.
In traditional websites, routing is handled by a router on the server:

a user clicks a link in the browser, causing the URL to change
the browser sends an HTTP request to server
the server reads the URL from the HTTP request and generates an appropriate HTTP response
the server sends the HTTP response to the browser

In modern JavaScript web applications, routing is often handled by a JavaScript router in the browser.
What is a JavaScript router?
In essence, a JavaScript router does 2 things:

update the web application state when the browser URL changes
update the browser URL when the web application state changes

JavaScript routers make it possible for us to develop Single Page Applications (SPA’s).
A Single Page Application is a web application that provides a user experience similar to a desktop application. In a Single Page Application, all communication with a back-end occurs behind the scenes.
When a user navigates from one page to another, the page is updated dynamically without reload, even if the URL changes.
There are many different JavaScript router implementations available.
Some of them are specifically written for a certain JavaScript framework such as Angular, ember, React, Vue.js, aurelia, etc. Other implementations are built for generic purposes and are not tied to a specific framework.
What is Angular router?
Angular router is an official Angular routing library, written and maintained by the Angular Core Team.
It is a JavaScript router implementation that is designed to work with Angular and is packaged as @angular/router.
First of all, Angular router takes care of the duties of a JavaScript router:

it activates all required Angular components to compose a page when a user navigates to a certain URL
it lets users navigate from one page to another without page reload
it updates the browser’s history so the user can use the back and forward buttons when navigating back and forth between pages

In addition, Angular router allows us to:

redirect a URL to another URL
resolve data before a page is displayed
run scripts when a page is activated or deactivated
lazy load parts of our application

In this article, we will learn how to set up and configure Angular router, how to redirect a URL and how to use Angular router to resolve todo’s from our back-end API.
In the next article, we will add authentication to our application and use the router to make sure some of the pages can only be accessed when the user is signed in.
How Angular Router Works
Before we dive into the code, it is important to understand how Angular router operates and the terminology it introduces.
When a user navigates to a page, Angular router performs the following steps in order:

it reads the browser URL the user wants to navigate to
it applies a URL redirect (if one is defined)
it figures out which router state corresponds to the URL
it runs the guards that are defined in the router state
it resolves the required data for the router state
it activates the Angular components to display the page
it manages navigation and repeats the steps above when a new page is requested

To accomplish its tasks, Angular router introduces the following terms and concepts:

router service: the global Angular router service in our application
router configuration: definition of all possible router states our application can be in
router state: the state of the router at some point in time, expressed as a tree of activated route snapshots
activated route snapshot: provides access to the URL, parameters, and data for a router state node
guard: script that runs when a route is loaded, activated or deactivated
resolver: script that fetches data before the requested page is activated
router outlet: location in the DOM where Angular router can place activated components

Don’t worry if the terminology sounds overwhelming. You will get used to the terms as we tackle them gradually in this series and as you gain more experience with Angular router.
An Angular application that uses Angular router only has one router service instance; It is a singleton. Whenever and wherever you inject the Router service in your application, you will get access to the same Angular router service instance.
For a more in-depth look at Angular routing process, make sure to check out the 7-step routing process of Angular router navigation.
Enabling Routing
To enable routing in our Angular application, we need to do 3 things:

create a routing configuration that defines the possible states for our application
import the routing configuration into our application
add a router outlet to tell Angular router where to place the activated components in the DOM

So let’s start by creating a routing configuration.
Creating the routing configuration
To create our routing configuration, we need a list of the URLs we would like our application to support.
Currently, our application is very simple and only has one page that shows a list of todo’s:

/: show list of todo’s

which would show the list of todo’s as the homepage of our application.
However, when a user bookmarks / in their browser to consult their list of todo’s and we change the contents of our homepage (which we will do in part 5 of this series), their bookmark would no longer show their list of todo’s.
So let’s give our todo list its own URL and redirect our homepage to it:

/: redirect to /todos
/todos: show list of todo’s

This provides us with two benefits:

when users bookmark the todos page, their browser will bookmark /todos instead of /, which will keep working as expected, even if we change the home page contents
we can now easily change our homepage by redirecting it to any URL we like, which is convenient if you need to change your homepage contents regularly

The official Angular style guide recommends storing the routing configuration for an Angular module in a file with a filename ending in -routing.module.ts that exports a separate Angular module with a name ending in RoutingModule.
Our current module is called AppModule, so we create a file src/app/app-routing.module.ts and export our routing configuration as an Angular module called AppRoutingModule:
Continue reading %An Introduction to Component Routing with Angular Router%


Angular 2 VS Angular 4: Features, Performance

In the world of web application development, Angular is considered one of the best open-source JavaScript frameworks.
Google’s Angular team announced that Angular 4 would be released on 23 March. Actually, they skipped version 3. As all of you know, the long awaited release of Angular 2 was a complete makeover of its previous version.


Firebase: Real-Time Database Using Angular 2

What’s up guys, Eze is here. Those who follow me on Twitter (if you are not a follower you better do it now @skielo) already know I’ve been working on an app to show you how to use Firebase from an Angular 2 app. I have several posts talking about Firebase and how to use almost all its functionalities from an AngularJS app, in case you missed it you can check it here. Today, I want to show you how easy is to get an Angular 2 app up and running and connected to Firebase. This will be the first out of a series of posts where we are going to find out more about those tools.
The Skeleton of Our App
I want to show you first how to create a new Angular 2 app from the scratch. To do that we will need to install the angular cli tool onto our machines. The installation of this tool is really simple – we just need run the following command npm install -g @angular/cli. Please be sure you have a node version higher than 4 because it’s a requirement for this tool to run.


Learn ASP.NET Core Using Angular 2

In this article, we will learn ASP.NET Core using Angular 2 in Visual Studio 2017.

Why should we use Angular 2?
Why should we use ASP.NET Core?
What should we know about?
How do we use Angular 2 in ASP.NET Core?

Why Should We Use Angular 2?
Angular 2 is a great framework to use for getting the most out of the latest browsers and thus for creating better applications. Angular 2 can build applications that live on:


Angular 4: Front End for the Enterprise

When Angular 2 was released in September of 2016, it signalled a dramatic shift in enterprise front-end development. Not only was it a complete rewrite of AngularJS, but it was also built from the ground up with Typescript – Microsoft’s strongly typed superset of JavaScript.
Suddenly, enterprise developers experienced with type-safe languages such as Java, C# and Scala, were welcomed into the world of modern front-end development with a framework that seemed immediately familiar to them.
In March of 2017, Google announced the release of Angular 4, now known as simply Angular, which introduced many optimizations and improvements to the developer experience and the user experience, solidifying Angular’s stance as an ideal, front-end development framework for the enterprise.
This post highlights the benefits of Angular from both a development and a user-experience standpoint and reviews the improvements over Angular 2 that Angular 4 introduced to the framework.
Typescript and the Benefits of Strongly Typed Languages
Enabling developers to assign types, interfaces, classes and inheritance to their front end code, Angular 2 made complex applications both easier to develop across large teams and more importantly, easier to maintain and refactor.
The introduction of static types ensured that developers could be confident that any errors they might introduce into a code base would be caught immediately by the TypeScript compiler, and that code written by a colleague was well defined, easy to understand, and simple to consume.
Libraries vs Frameworks
In addition to the introduction of static typing, Angular 2 introduced common design patterns based on lessons learned from AngularJS’s evolution and the emergence of other front-end libraries such as React and Ember.
This difference is what makes Angular a framework and React a library. React does not dictate any decisions outside of the view layer. Where developing a complex application with React would require bringing in any number of external libraries in any number of ways, Angular provides modules and conventions that offer solutions to everything required of a complex front-end application, allowing developers to start delivering features straight out of the gate.
As a result, an Angular developer can be brought into any Angular project and will be immediately familiar with the code and conventions used to make it work. Developers will be familiar with the framework and many of the standard conventions that are used on any project; whereas a large React project would require significant time for a developer to familiarize themselves with the architectural decisions made to any particular project.
Angular 2… Angular 4…. Let’s Just Call it Angular
In December of 2016, the Angular team announced that they would be adopting semantic versioning, also know as Sem-ver, which prescribes a strict semantic relationship between code changes and version numbers. This numbering system aligns major numbers with breaking changes, minor numbers with new features without breaking changes, and patch numbers that represent bug fixes, Sem-ver lets a developer know whether or not upgrading a library will break their code.
So why the jump to Angular 4? Angular is a collection of distinctly separate modules, and one of these modules, the router, had gotten ahead of the rest of the library and had already made the jump to version 3. To get everything back in sync, and to fully support Sem-ver across all of the Angular framework, the core team decided to bump both the Angular framework and the router to version 4.
This jump in major numbering was confusing at first, but a necessary step for Angular’s version numbers to be truly representative of the changes being made to its codebase.
As a result, Angular 4 is now simply referred to as Angular. This is in contrast to AngularJS, which represents all 1.x versions of Angular. Whereas Angular 2 is a complete rewrite of AngularJS, all future major versions of Angular will not represent rewrites of the framework, but rather, further improvements, and the core team has a release schedule that includes major version upgrades every six months. Angular 5 is slated for release in September of 2017 and Angular 6 is due in March of 2018.
So What’s New in Angular 4?
Angular 4’s focus is on improving the performance and bundle size of Angular 2. It’s possible to consider Angular 2 a beta version of Angular itself, with Angular 4 introducing optimizations and improvements that the Angular community asked for.
Long-term Support (LTS)
At ng-conf 2017, the Angular Core team announced that Angular 4 will be its first version of Angular with LTS. This means that enterprises that don’t have the ability to constantly upgrade Angular and their applications can commit to Angular 4.
Faster Rendering and Smaller Bundle Sizes
Changes in the compiler reduce the size of the generated code for your components up to 60% in most cases – the more complex the template, the higher the savings. Further, by removing the animations package from @angular/core, your bundles won’t have to include it unless they require it, saving additional file size.
Better Minification
Angular 4 now ships with Closure annotations, which allows developers to use Google’s Closure compiler to drastically reduce the size of their bundles even more than what was previously possible with UglifyJS, thanks to smarter tree shaking.
TypeScript 2.3
Angular 4 uses a more recent version of TypeScript than Angular 2, and this allows for faster compilation time with the ngc compiler and better type checking.
Better Error Messages
A common source of frustration with Angular 2 was its somewhat cryptic set of error messages. With Angular 4, not only are error messages clearer and more informative but now thanks to new template source maps, they also point directly to lines of code within templates.
Server-side Rendering
Angular Universal, Google’s server-side rendering library, is now compatible with Angular 4. Universal allows developers to render their applications on the server side, benefiting both search engines and users alike.
*ngIf, Now With More Else
The *ngIf structural directive, a very commonly used part of any Angular application, now has an else statement. This means that developers can now simplify their conditional templates, no longer needing to use two *ngIf’s with opposite evaluations.
Angular 4 Is an Ideal Enterprise Front-end Framework
With the improvements made to Angular by the Angular Core team in Angular 4, Angular has solidified its position as the ideal front-end framework for enterprise applications.
Based on standard conventions, familiar design patterns, strongly typed code, and server-side rendering, enterprises can develop scalable applications across large teams that are highly performant and optimized for the server side and client side alike.
With a clear release schedule and the recent announcement for LTS versions, enterprises can adopt Angular for their front-end applications with full confidence that they are choosing the best framework for the job.


Web Applications Frontend and Backend Communication Using Angular 2 HTTP Observables

A frequent operation in most web and mobile applications is data request and response from/to a server using a REST architectural style via an HTTP protocol. Angular 2 implements Observables in its HTTP module for working with HTTP response and request. In this tutorial, we’ll look at how to get and post data from/to backend servers using Observables.
What you’ll learn in this tutorial:


The Recipe for Angular 2 in a Java EE Environment: Maven Build

This is the fifth article in our “The Recipe for Angular 2 in a Java EE Environment" series, with a more detailed description of the build of the Angular2 and JavaEE Project. It follows my fourth article about Angular 2 and Java EE that gave a detailed overview of the Frontend infrastructure of the Car Rental Project.
In this article, the build of the project is covered. That might not be considered the fun stuff, but to get Angular approved in a corporate environment you will have to learn to integrate with the existing Continuous Integration Infrastructure. The Deployment and Testing requirements also need to be met. This article should give you an example of how this could be done. 


Three Books on Angular

Programmers routinely use Stack Overflow as a brain extender these days, but there is still a place for long-form tutorials and well-organized reference guides. These can do more than inform: they can shape how a technology develops by guiding readers in particular directions, and simply by existing, they tell developers what their peers find interesting.
By this last measure, Angular is doing pretty well these days. Rangle’s Angular Training Book had the field pretty much to itself a year ago, but good alternatives are now on the market. As someone who was new to Angular six weeks ago, I found two particularly useful.
The first is Asim Hussain’s Angular 4: From Theory to Practice. This short, lively introduction to Angular covers everything you need to know to build your first Angular application, from components and data binding through dependency injection and services to routing, forms, and testing. The framework’s capabilities are introduced in a logical order, and the writing is light without being shallow. It took me a couple of tries to get through some parts, but that had more to do with the complexity inherent in an enterprise-scale framework like Angular (and in my unfamiliarity with modern JavaScript) than with the book itself.
The second book I would recommend is Frisbie’s Angular 2 Cookbook. As the title suggests, this is a collection of recipes for people who already have some idea of what they want to do, but aren’t sure how (or how best) to do it. The first chapter discusses upgrading from earlier versions of Angular; subsequent chapters cover the same topics as Hussain’s book, but in more depth. The author presents each example in small steps with changes highlighted to make it easy to follow along. I found Chapters 6 (routing), 8 (organizing and managing applications), and 10 (performance) particularly helpful, but have lots of sticky notes marking other places as well.
Note: this book was written before CLI 1.0. The CLI has become an essential part of Angular development and offers a good starting point for most applications. It might not matter as much for advanced users who care a lot about webpack configs and customizing the testing tools, but it should still be in every developer’s toolbox.
One book that I wouldn’t recommend is Fain and Moiseev’s Angular 2 Development with TypeScript. The authors clearly know their way around Angular, and individual sections of the book are quite useful, but the overall organization is confused, and terms and features are often used before they are explained. I liked the use of callouts to draw attention to particular aspects of example code, but found myself doubling back much more often than I wanted to.
Angular is complicated because the problems it solves are complicated. Its internal documentation is much better than it used to be, and tools like Augury dispel a lot of mystery, but there will always be a place for good tutorials and reference works. With Hussain and Frisbie’s books, Angular has at least one of each.

Yakov Fain and Anton Moiseev: Angular 2 Development with TypeScript. Manning, 2016, 978-1617293122.
Matt Frisbie: Angular 2 Cookbook (2nd ed). Packt, 2017, 978-1785881923.
Asim Hussein: Angular 4: From Theory to Practice. CodeCraft, 2017, B01N9S0CZN.

Learn More
If you’re looking for more Angular learning opportunities and in-depth tutorials, check out our various training options. Better yet, inquire about custom training to ramp up your knowledge of the fundamentals and best practices with custom course material designed and delivered to address your immediate needs.