Most of the angular applications today have an application router for dealing with the routes of the application. So the web interface for sTeam had the usage of ui.router a library for helping people write routers for complex and big applications. So before i contextualize the usage of ui.router and also give an essence of how routing works with ui.router let us just have a look at the syntax :

angular.module('steam', 'ui.router')

.config(['$locationProvider', '$stateProvider', '$urlRouterProvider', '$provide',
  function ($locationProvider, $stateProvider, $urlRouterProvider, $provide) {

.state('state_name', {
  url: '/route_goes_here',
  templateUrl: '/path_to/templates_go_here.html',
  controller: 'controller_comes_here',
  requireLogin: false || true // depending on the requirement
 })

}])

In the above snippet we can see how to initialize a bare minimum router for an angular application. But to use the ui.router for couple of routes is very much not using the router to the fullest of the features.What are states ?
$state is nothing but a service which is part of the ui.router module. So it can be considered as a service that is responsible for transitioning states accordingly from one state to another. There are many types of states that we can deal with while writing a router for a complex application that deals with multiple and nested states.

• parent State
• sibling State
• grand child state

The parent states generally go with the normal implementation, all we have to use is the state name while declaring the state. But things are not same with sibling state and grandchild state. Let us have a look as to how things are different with them :

// sibling state
.state('^.sibling_name_goes_here', {
  url: '^/route_goes_here',
  templateUrl: '/path_to/templates_go_here.html',
  controller: 'controller_comes_here',
  requireLogin: false || true // depending on the requirement
 })

// grand child state
.state('^.sibling_name_goes_here.grandchild_name_goes_here', {
  url: '^/route_goes_here/:path',
  templateUrl: '/path_to/templates_go_here.html',
  controller: 'controller_comes_here',
  requireLogin: false || true // depending on the requirement
 })

How should multiple routes be handled and how should views be added to the config ?
As explained in my previous article there is a way to use the ui-view in order to write reusable components for the angular application. So let us have a look at how views are to be added to the router’s config :

// state with views
.state('state_name_goes_here', {
  url: '/route_goes_here',
  requireLogin: true || false, // depending on the requirement
  views: {
    'view_name_goes_here': {
      templateUrl: '/path_to/templates_go_here.html',
      controller: 'controller_name_goes_here'
    },
    'view_name_goes_here': {
      templateUrl: '/path_to/templates_go_here.html',
      controller: 'controller_name_goes_here'
    },
    'view_name_goes_here': {
      templateUrl: '/path_to/templates_go_here.html',
      controller: 'controller_name_goes_here'
    }
  }
})

NOTE : We can have the possibility of an application that has a silbing route and all the routes of the parent route are inherited to the sibling route. Enabling this to happen is the beauty of ui.routerNow taking the above syntax we can just add more and more states to the config. It is pretty much that easy to write router config for an application dealing with multiple states. Therefore taking this ahead we can write application router’s for applications that need to handle many routes, but the point here is to understand the point of how the ui.router can be leveraged to the maximum in order to take the best of its features.

Thats it folks,
Happy Hacking !!