Ember Router v2 is on the road to excellence, but it's not there yet. Here's a generally-approved yet unofficial wishlist/roadmap of features so that each incremental addition can keep some perspective.
- - Query String support (GH Issue)
- - Routeless sub-states (GH Issue)
- - Haltable-transitions (GH Issue)
- - Re-marry the router with a state manager]
- - 404 / route not found page (GH Issue)
- - Unify
handleURL/transitionTobehavior (Gist)
What: the ability for routes to interpret query string URLs, e.g. the stuff after the ? in #/things/23?page=2&filter=active. The router presently supports a resource-based url scheme, but this limits you to being able to only pass one piece of information to a given route, namely the value for the single dynamic segment, i.e. 23 for :thing_id. Being able to pass in more information via a query string would facilitate linkable lists with filters, pagination, etc.
There's also a lot of opportunity for out-of-the-box conventions to kick in, such as, without writing any ember code beyond Ember.Router.map, changing to #/things/23?page=2 would trigger an Ember data ajax request for /things/23?page=2
What: the ability to declare states in the Ember router that aren't connected to a URL. This is desirable because not every state within an application ought to be representable/linkable by a URL. For instance, you might want to add a success screen that says "Congrats, you just sent a message to X", and plug in that state nicely into your application with Ember.Router.map and get all the Router/Controller/Template logic for free, but not actually have a transition to SuccessRoute change the url, nor be reachable by a link.
Some work has been done on this, but it's unlikely that it's read for prime-time.
Presently, you have total control over the transitions that can be made by all links / buttons / UI actions in an Ember app. But for transitions caused by URL changes, you have no control to prevent a transition if 1) the transition from A to B makes no logical sense for your app or 2) route A doesn't want to allow the transitions. An example of 2 would be if you're in a route editing a form and you accidentally hit the back button on your browser; such a transition should be blockable by route A (i.e. you could have the user confirm that they actually wanted to abandon their form).
There's a million other use cases, both generalized and nit-picking that would be facilitated by having the ability to halt a transition. Please see the Github issue for an exhaustive TLDR; note that the original ideas behind that issue are out of date.
Router v1 tightly coupled the Router with Ember.StateManager, which had benefits that were ultimately overwhelmed with the drawbacks, the drawbacks being:
- It was confusing to many
- You had to declare tons of View and Controller classes, even entirely empty ones (this could have been fixed though, as painlessly as it was for the v2 router)
- The implementation was bloated and hard to optimize;
Ember.StateManagerhad to be enhanced in a bunch of bizarre ways to handle all the responsibilities that the Router should have been in charge of.
It's good that we stepped away from this approach in favor of the v2 router, which offers an excellent DSL and rests on an unbloated implementation appropriate to the problem being solved. Unfortunately, we've lost a few nice features along the way:
The ability to essentially draw out a state chart for your application, which is a convention that Ember should push on its users. A StateManager/StateChart-based approach seals your apps from winding up in a bad state by constraining the transitions that can be made to ones that you've specified ahead of time, i.e. if I'm in state A, I should only be able to transition to B or C, but definitely not to D. The way you'd "draw" out the valid transitions was by specifying actions on your Ember.Routes that could be fired off from UI events in your templates.
Now, considering that there's presently no way to halt a transition, this lack of transition-drawing doesn't really affect us in any way, but if we're to adequately solve the haltable-transition problem (which is really the ultimate presently-unsealable hole in our ember applications), we'll want a way to draw out the valid transitions in our applications....blahlbalalg will write more later.