Introduce routing service

[tomdale]

This commit introduces a new routing service, so that we can decouple LinkView from knowing about the actual router’s internals.

Before this commit, LinkView tried to find the router off of its controller, and looked up the application controller to get current router state. This commit creates an initial API for working with a single uniform service that provides the information.

The implementation of the routing service is not yet ready to be made a public API, but it should be possible to expose once it stabilizes further. The long-term goal is to provide a robust enough service that end users could relatively easily implement their own LinkView using public APIs.

[mmun]

Very nice 👍

[workmanw]

👍 I can't tell you how many times I've wanted to do transitionTo from another service or component.

[rwjblue]

@tomdale - I believe that the node-land tests confirming {{link-to}} works (here) will need to be updated to handle the new service (that is the only failing test that I see).

[stefanpenner]

readOnly

[workmanw]

So from the looks of this, the routing service will remain private. Is that correct?

[rwjblue]

@workmanw - For now, yes. The long term plan would be to expose it as supported public API.

[tomdale]

This was incorporated into the Glimmer work: https://github.com/emberjs/ember.js/blob/master/packages/ember-routing/lib/services/routing.js

[workmanw]

@tomdale 😄 I've been slowly migrating to 2.0 component patterns, this was definitely much needed. Thanks!

[mixonic]

We need to push this through the RFC and public API process now!

[workmanw]

@tomdale @mixonic Oh. Sorry for the confusion. I didn't catch that it was still private.

It would be super great for it to be public. My primary need is for Components and Services to he able to 1) determine the current route path and 2) be able to transition to another route.

Thanks a lot for all the hard work on 2.0 :)

[rwjblue]

@workmanw - Those are definitely amongst the top reasons this needs to be formalized into public API.

[tomdale]

@workmanw Agreed that we need to expose this service into userland ASAP. The only reason we didn't was that the API is still a little rough, surfacing a rather unpleasant combination of Ember.Router and router.js implementation details into the service API.

The next step here I think is to draft an RFC that outlines what exact capabilities we want to expose publicly via the routing service, then try to come up with a pleasant API for that. The biggest obstacle is that currently many of the APIs rely on passing around "router state", an opaque object that includes tons of state we probably don't want to expose publicly. Perhaps @machty has some ideas about how to bundle up state without exposing the guts to the world.