Router Helpers

[chadhietala]

Rendered

[rwjblue]

I'm definitely in favor of this, thanks for working on it!

[raido]

Less magic and more control for advanced UX 👍

[gossi]

Is this correct for {{is-active}}? According to the signature you mentioned above, this should be class={{if (is-active 'profile') 'active'}} or is there some magic going on between is-active and url-for helper? I'd like the short syntax you used here, thought then it looks like overloading in that very special location?

[rwjblue]

Agree here, I believe it should be updated to use the inline if snippet above.

[gossi]

How does it related to #339 ? Will it make that one obsolete?

[lennyburdette]

Is is-active too generic of a name? Would is-route-active be more appropriate?

(Or will I not care soon because it will be a matter of {{use is-active as is-route-active from "@ember/route-helpers"}} to distinguish them? 😁)

[luxzeitlos]

So I think the primary difference to #339 is that this assumes ordered params and not named params?

[juggy]

I am not 100% sure what transition-to adds to the html of the anchor. Does it add the href url and an action? Something like:

<a href={{url-for "my.route" model}} onclick={{transition-to-action 'my.route' model}}> Link </a>

So it would be a shortcut? (made up transition-to-action for the example)

Can I have a component use the transition-to as an action?

{{my-comp onSave=(transition-to 'my.route')}}

[chadhietala]

@gossi and @luxferresum that is the primary difference in regards to the helpers, but this RFC also makes <a href="/">Home</a> also "just work".

@lennyburdette these APIs are intended to map directly onto those provided my the router service.

@juggy Yes it adds the href in the modifier form. I think we could have a sub-expression API as well.

[lennyburdette]

Mirroring the router service API makes a lot of sense, but I would argue that the API is actually router.isActive() not just isActive on its own.

I also agree that a transition-to helper would be helpful in addition to the transition-to element modifier, but I am concerned about creating another point of confusion similar to {{action}}/(action). Maybe it'll be clearer after the Element Modifier Manager RFC is implemented and element modifiers become a documented feature of the framework?

[sandstrom]

Great RFC! 🏆

It would solve all the workarounds we have around link-to in our app (we use something similar to ember-cli-active-link-wrapper).

---

Just a small thought on the drawback you mention in the RFC:

By proxy this may cause people to encapsulate all of these primitives into a single component and thus creating a user-land version of {{link-to}}. -- this RFC

Later, when the RFC is shipped, the documentation around these helpers/modifiers could include a short snippet on how to put together a link-to component (under an 'advanced' section or similar), as a starting point for anyone that needs to encapsulate app-specific logic into a link component.

(I don't think this drawback/scenario is much of a problem, but in case people think it is, it can be solved with useful docs and hence it shouldn't hold this rfc back)

[rwjblue]

@sandstrom

The documentation around this could include a short snippet on how to put together a link-to component (under an 'advanced' section or similar), as a starting point for anyone that needs to encapsulate app-specific logic into a link component.

There is a “kitchen sink” example here which shows all the things that a {{link-to does.

[alexparker]

This RFC expands the surface area of the templating layer by exposing the primitives that make up {{link-to}}

Would also be worth exploring not just breaking apart the helpers, but parts for building ones own light-weight link components. I recently just ended up creating a nav-link component of my own instead of link-to and using the new router service api has been really really nice with that.

[sandstrom]

@alexparker Perhaps I misunderstand your question, but the purpose of this RFC is precisely about making it easier for you to make your own nav-link components.

[locks]

Does it have to be "kill controllers"? :X

Suggested change

Looking at a template you would have no idea that rendering the `{{link-to}}` would result in the query params being serialized. From an implementation point of view, this is problematic as we are forced to `lookup` the `Route` and the associated `Controller` to grab the query params. This can add a non-trivial amount of overhead during rendering, especially if you have many `{{link-to}}`s on a route that link many different parts of your application. As a side-note, this is one of the things that needs to be dealt with if we are ever to kill controllers.

Looking at a template you would have no idea that rendering the `{{link-to}}` would result in the query params being serialized. From an implementation point of view, this is problematic as we are forced to `lookup` the `Route` and the associated `Controller` to grab the query params. This can add a non-trivial amount of overhead during rendering, especially if you have many `{{link-to}}`s on a route that link many different parts of your application. As a side-note, this is one of the things that needs to be dealt with if we are ever to kill controllers.

[chadhietala]

After the core team call on Friday I have updated the RFC to reflect the consensus. These changes include:

• Removal of {{transition-to}} modifier.
• Removal of all deprecations
• Addition of transition attribution

The reason to remove the {{transition-to}} modifier largely dealt with the fact that we need HTMLAchorElements to have the href populated during server-side rendering. Modifier's do not run during SSR therefore all the anchor tags in the HTML output would not work if the JavaScript failed to load.

We decided to remove all the deprecations that this RFC originally introduced because there is no way of passing the in memory model to the route you are transitioning to. This functionality requires a bit more thought and a solution may be introduced in a subsequent RFC.

This RFC now introduces the notion of a transition attribution. This is simply a formalization of the Transition.data parts of the RFC. I have amended the RFC with 2 examples showing how this functionality could be used.

[alexparker]

@sandstrom Sorry wasnt really clear i'd only seen proposals for breaking out the helpers, but I was thinking more in terms of reusable parts inside the component.js, but the parts could be reused in components just fine

[jneurock]

I like these changes. Thank you!

But perhaps only tangentially related, they don't address the only reason I ever extended LinkComponent...

Is there a story for dynamically generated route names that allow for an arbitrary list of models? I.E., a named models (or similar) parameter where I can pass a list?

In some of my apps I have code like this (after extending LinkComponent):

{{#each linkableThings as |linkableThing|}}
  {{link-to linkableThing.title linkableThing.routeName dynamicModels=linkableThing.models}}
{{/each}}

The implementation code was trivial and it made me wonder "why isn't this a thing?" It also made me think a spread operator in Handlebars would be pretty awesome.

[rwjblue]

@jneurock - Great point! I totally agree that this should be possible with any new helpers that we add. One possible solution would be to make the various helpers take position arguments or named arguments. So for example, we could do:

Using positional arguments:

<a href="{{url-for "foo" someModel}}"></a>

OR using named arguments:

<a href="{{url-for routeName=linkableThing.routeName models=linkableThing.models}}"></a>

What do you think @chadhietala?

[chadhietala]

@rwjblue I think it is useful for the models to be a positional or named params, but I don't think it makes sense for the route name as there are never more than one passed.

[rwjblue]

Derp, yes that makes sense thank you!

[chadhietala]

After our Friday meeting we decided to move this into final comment period.

[acorncom]

@chadhietala A question for you here. Everything else on this RFC looks awesome and I'm quite eager to see it all land. When it comes to this change though, I'd like to raise a potential snag we should make sure we address.

Specifically, in a "switching into Ember" scenario for a primarily server-rendered app, will there be enough safety valves as part of this change to allow folks to safely drop Ember in on their site without it unexpectedly hijacking all <a> tags? If a wildcard route is NOT setup as below, then Ember's router should continue to function in whitelist mode and only intercept click events for <a> tags that it has been setup to handle, correct? Thought it was worth clarifying so we don't inadvertently cause ourselves problems for our npm install your way to Ember story down the road ...

[sandstrom]

Good question! The event dispatcher is only hooked up on the ember application rootElement, so it's fine to drop in Ember on a server-rendered page, even after this change.

https://github.com/emberjs/ember.js/blob/aa838632/packages/%40ember/-internals/views/lib/system/event_dispatcher.js#L241

[chadhietala]

@acorncom Yes they should continue to work in an SSR'd page since the events are rooted on the rootElement. The app that is migrating needs to make sure the root element is not body. I think this is typically what people to do in this case.

[xg-wang]

PR and this RFC name should be updated

[locks]

done, thank you!