[build] Replace $routeProvider with ui-router

[joshdmiller]

[rolaveric]

I had a go at implementing this (ce041e6553), and it works pretty well.

However, I found I had to duplicate my header and footer views between the home and about features - they couldn't inherit them from the ngBoilerplate module because the module inheritance goes in the opposite direction (ie. ngBoilerplate inherits from home and about, not the other way around)
It comes up enough that the ui-router team have added the issue to their FAQ.

The best solution I can think of is to add a new ngBoilerplate.rootState module to src/app/app.js, where it's own job is to declare an abstract state named rootState with the default views.

Thoughts?

[joshdmiller]

I added ui-router as a drop-in replacement and it works swimmingly. It's on branch v0.3wip for the moment but will be merged to master within the next few days. So I'm going to close this issue.

@rolaveric I didn't really follow that. I know this was a month ago, but would you mind elaborating?

[rolaveric]

@joshdmiller Sorry - I'm sure it made perfect sense to me at the time, but it looks like I lost the plot part way through.

I was trying to use the nested states and views that ui-router provides, splitting index.html to have 3 ui-view directives - header, content, and footer - and wrap them all up under a state called (creatively) rootState.
The trouble is that I had created a dependency between the child modules (ngBoilerplate.home and ngBoilerplate.about) and the root ngBoilerplate module, rather than the other way around.
ie. Before state about can be loaded into $stateProvider, it needs the rootState state to have been loaded first, otherwise ui-router throws an error.

My previous solution, which I mentioned in my last comment, was create a separate ngBoilerplate.rootState module which solely handles initialising the root state for the application, and can then be passed around to the child pages to attach to.
That was a terrible idea because it means you can't just pick up those child pages and put them in another application without rewriting it.

A better solution (Which I will push to my fork when I get home this evening) is to simply never call $stateProvider.state() within your components - only in your application.
Instead just declare them in a module.provider() that your application can request and initialise at will.
eg:

// Component that could be used by any application
angular.module('myComponent', []).provider('myComponentStates', function () {
  // Provider boilerplate
  var provider = this;
  provider.$get = function () {return provider;};

  // Declare my states as objects
  provider.states = [
    {name: 'myComponent', template: 'myComponent.tpl.html'},
    {name: 'myComponent.childState' /* ... */}
  ];

  // Specify what state should be attached when including this module
  provider.rootState = provider.states[0];
});

// Application which wants to use 'myComponent' under route "/feature1"
angular.module('myApp', ['ui.states', 'myComponent']).
config(['$stateProvider', 'myComponentStatesProvider', function ($stateProvider, myComponentStatesProvider) {
  // Declare my root page state, with headers and footers, etc.
  var pageState = {name: 'page', /* ... */};

  // Attach the rootState for mycomponent
  myComponentStatesProvider.rootState.parent = pageState;

  // Set it's URL to 'feature1'
  myComponentStatesProvider.rootState.url = '/feature1';

  // Now you can safely initialise all the states
  $stateProvider.state(pageState);
  angular.forEach(myComponentStates.states, $stateProvider.state);
}])

There's a discussion on how to build this into ui-router natively, but there hasn't been any activity for about 2 weeks:
angular-ui/ui-router#160 (comment)

[rolaveric]

Here's a commit for my 'better solution'(tm): 9ef2e62
I realised a provider is overkill and that a constant would work just as well.

I also realised that the latest tagged version of the ui-route directive doesn't support ui-router, but it does in the master branch.