@digitaltoad What are you trying to do in connectOutlets of the root state? None of the test cases show connectOutlets on the root state. I'm not so sure that's the convention even though the original gist shows it done that way.

Sorry, I should have added a test for that as well. I've been going by the original gist. In current apps, instead of placing setup code in the root connectOutlets, I've created a single state inside root that would house the rest of my app states so that I would have access to the controllers there. This seemed like the way root was supposed to work. I'm not sure of a better way to defer the start of the router without the flag that I've inserted that wouldn't break any apps that assumed the router would automatically transition to the root state.

My problem arises from an example where the page is loaded at a state. For instance, http://jsfiddle.net/C7LrM/8/. I've extracted the navbar area. Where would the setup go for this. If the app loads at the home state, everything is fine. If the app loads at the profile state, the navbar is never loaded. Would the navbar have to be connected in every state or is there just a better way of handling this? This might of course just be a convention issue.

You're not gaining anything by using connectOutlets for that. The real power of connectOutlet is passing a context in. A navbar likely has no context. If any part of it is dynamic, you probably want to just bind to something on applicationController, or have your own navbarController. Just use the Handlebars view helper. see here

This does indeed make sense. I had gone down the route of using a view helper before I learned about outlets. However, the question remains, if connectOutlets is still fired in the root state, should everything be wired and ready at that point?

I agree that this is an important fix, but I think this hacks around the problem instead of addressing the core issue. Instead of special-casing the router to not automatically transition into the initialState, we should just make sure that the initialState's connectOutlets call back doesn't happen until the state manager has finished initializing.

I had tried to figure out a way to do this without a hack. Maybe if I revisit I can come up with something else. My first thought was indeed to only fire the initial transitionEvent after the state manager was completely initialized (including injections).

To clarify, both the initialState and the transitionEvent (connectOutlets) are handled by the StateManager class. Wherever we make the change, we're going to have to "hack" around it in the router. Delaying the initialState makes sense to me since the router really doesn't get kicked off until the first route call.

Sorry to pester, but were we going to pull this PR or wait to implement @tomdale's suggestion of making a statemanager's root state transitionEvent not trigger until the manager is done being initialized?