Before diving into more advanced usage scenarios, let’s abandon our naïve implementation by converting our route definitions to the syntax used by the $route service.

In angularjs, routes can be defined during the application’s configuration phase using the $routeProvider service. The syntax used by the $routeProvider service is similar to the one we were playing with in our custom $location based implementation:

angular.module('routing_basics', [])
  .config(function($routeProvider) {
    $routeProvider
      .when('/admin/users/list', {templateUrl: 'tpls/users/list.html'})
      .when('/admin/users/new', {templateUrl: 'tpls/users/new.html'})
      .when('admin/users/:id', {templateUrl: 'tpls/users/edit.html'})

      .otherwise({redirectTo: '/admin/users/list'});
  })

The $routeProvider service exposes a fluent-style API, where we can chain method invocations for defining new routes (when) and setting up a default route (otherwise).

<div class="container-fluid" ng-include="selectedRoute.templateUrl">
    <!-- Route-dependent content goes here -->
</div>

<div class="container-fluid" ng-view>
    <!-- Route-dependent content goes here -->
</div>

In the naïve implementation, we were relying on a very simple route matching algorithm, which doesn’t support variable parts in URLs. In fact it is a bit of a stretch to call it an algorithm, we are simply looking up a property on an object corresponding to URL’s path! Due to the algorithm’s simplicity, we were using a URL query parameter in the query string to pass around the user’s identifier as follows:

/admin/users/edit?user={{user.id}}

It would be much nicer to have URLs where the user’s identifier is embedded as part of a URL, for example:

/admin/users/edit/{{user.id}}

With the angularjs router, this is very easy to achieve since we can use any string prefixed by a colon sign (:) as a wildcard. To support a URL scheme where the user’s ID is part of a URL we could write as follows:

.when('/admin/users/:userid', {templateUrl: 'tpls/users/edit.html'})

This definition will match any URLs with an arbitrary string in place of the :userid wildcard, for example:

/users/edit/1234

/users/edit/dcc9ef31db5fc

On the other hand, routes with an empty :userid, or the :userid containing slashes (/) won’t be matched.

.controller('EditUserCtrl', function($scope, $routeParams, Users){
  $scope.user = Users.get({id: $routeParams.userid});
  ...
})

In the approach taken so far, we defined a controller responsible for initializing the partial’s scope inside each partial using the ng-controller directive. But the angularjs routing system makes it possible to define controllers at the route level. By pulling the controller out of the partial, we are effectively decoupling the partial’s markup from the controller used to initialize the partial’s scope.

Let’s consider a partial providing a screen for editing a user’s data:

<div ng-controller="EditUserCtrl">
    <h1>Edit user</h1>
   . . .
</div>

We could modify it by removing the ng-controller directive as follows:

<div>
    <h1>Edit user</h1>
   . . .
</div>

Instead of that we can define the controller service in the route level as follows:

.when('/admin/users/:userid', {
  templateUrl: 'tpls/users/edit.html'
  controller: 'EditUserCtrl'})

By moving the controller to the route definition level, we’ve gained the possibility of reusing the same controller for different partials and more importantly, reusing the same partials with different controllers. This additional flexibility comes in handy in several situations. A typical example would be a partial containing a form to edit an item. Usually we want to have exactly the same markup for both adding a new item and editing an existing item, but behavior for new items might be slightly different as compared to the existing ones (for example, creating rather than updating when persisting the item).