Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Router Helpers #391

Merged
merged 7 commits into from Nov 13, 2018

Conversation

@chadhietala
Copy link
Member

commented Oct 22, 2018

Rendered

@chadhietala chadhietala force-pushed the new-router-helpers branch 3 times, most recently from 414c337 to 52a287f Oct 22, 2018

@rwjblue

This comment has been minimized.

Copy link
Member

commented Oct 22, 2018

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

@chadhietala chadhietala force-pushed the new-router-helpers branch from 52a287f to 7ae9850 Oct 22, 2018

@raido

This comment has been minimized.

Copy link

commented Oct 22, 2018

Less magic and more control for advanced UX 👍

**After**

```hbs
<a href={{url-for 'profile'}} class={{is-active 'active'}}>Profile</a>

This comment has been minimized.

Copy link
@gossi

gossi Oct 23, 2018

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?

This comment has been minimized.

Copy link
@rwjblue

rwjblue Oct 23, 2018

Member

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

@gossi

This comment has been minimized.

Copy link

commented Oct 23, 2018

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

@lennyburdette

This comment has been minimized.

Copy link

commented Oct 23, 2018

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? 😁)

@luxferresum

This comment has been minimized.

Copy link

commented Oct 24, 2018

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

@juggy

This comment has been minimized.

Copy link

commented Oct 24, 2018

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')}}

@tylerturdenpants tylerturdenpants referenced this pull request Oct 24, 2018

Merged

Ember Times Issue 70 #3650

6 of 14 tasks complete
@chadhietala

This comment has been minimized.

Copy link
Member Author

commented Oct 24, 2018

@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

This comment has been minimized.

Copy link

commented Oct 24, 2018

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?

Alonski and others added some commits Oct 25, 2018

Merge pull request #393 from Alonski/patch-3
Fixed some grammar and spelling
@sandstrom

This comment has been minimized.

Copy link

commented Oct 25, 2018

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

This comment has been minimized.

Copy link
Member

commented Oct 25, 2018

@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 comment has been minimized.

Copy link

commented Oct 26, 2018

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

This comment has been minimized.

Copy link

commented Oct 26, 2018

@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.

tylerturdenpants added a commit to emberjs/website that referenced this pull request Oct 26, 2018

Ember Times Issue 70 (#3650)
Ideas, feel free to add to list or claim! 

- [ ] I've been getting a lot of questions about how tree-shaking is coming along. I would be willing to train anyone that wants to help on what's already done and what still needs to be done. Disclaimer: It's a lot of work! https://twitter.com/kellyselden/status/1050717338595745792
- [x] emberjs/rfcs#387 it seems this was covered in [last week's edition](https://www.emberjs.com/blog/2018/10/19/the-ember-times-issue-69.html#toc_a-href-https-github-com-emberjs-rfcs-pull-387-using-relationships-links-or-not-your-call-a)
- [ ] emberjs/rfcs#389
- [x] emberjs/rfcs#391 (🔒 @jessica-jordan)
- [x] emberjs/rfcs#392 (🔒 @jessica-jordan)
- [ ] Hacktoberfest roundup?
- [ ] Check https://github.com/jessica-jordan/whats-new-in-emberland (roundup of all the PRs in emberjs and ember-learn repos)
- [x] GraphQL with Ember? https://emberfest.eu/schedule/#rocky-neurock Or maybe we can reach out to them for a post-EmberFest writeup? See also the blog post: https://medium.com/kloeckner-i/ember-and-graphql-8aa15f7a2554 cc @simonihmig (🔒 @amyrlam)
- [ ] #30DaysOfEmber https://twitter.com/PoslinskiNet/status/1054446639719608320
- [x] Following the spirit of building shared solutions, ember-i18n is now deprecated in favor of ember-intl (https://github.com/ember-intl/ember-intl …)! Now we have a blessed way to internationalize Ember apps! Check the codemod we built @DockYard to help with the migration https://twitter.com/MiguelCamba/status/1054699605865177089 (🔒 @chrisrng )
- [x] Ember 3.5 released! (🔏 @kennethlarsen)

Ideas we are waiting on:

- [ ] EmberCamp talks, deep dive? http://embercamp.com/ and https://github.com/ember-chicago/ember-camp-2018-notes ... Maybe we wait for the talk videos to be published? Keep an eye on #ember-camp in Discord.
- [ ] EmberFest talks, deep dive? Keep an eye on #ember-fest in Discord.
- [ ] Include summary from pixelhandler (get input from him), see #issue-triage in Discord (check toward end of October)
Show resolved Hide resolved text/0000-router-helpers.md
Show resolved Hide resolved text/0000-router-helpers.md
Show resolved Hide resolved text/0000-router-helpers.md
Show resolved Hide resolved text/0000-router-helpers.md
<a href="/profile?someBool=true" class="active ember-view">Profile</a>
```

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.

This comment has been minimized.

Copy link
@locks

locks Oct 28, 2018

Contributor

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.
Show resolved Hide resolved text/0000-router-helpers.md
Show resolved Hide resolved text/0000-router-helpers.md
@chadhietala

This comment has been minimized.

Copy link
Member Author

commented Oct 29, 2018

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.

@chadhietala chadhietala force-pushed the new-router-helpers branch from 42e7fb5 to 032caaa Oct 29, 2018

@chadhietala chadhietala force-pushed the new-router-helpers branch from 032caaa to ec7dd7e Oct 29, 2018

@alexparker

This comment has been minimized.

Copy link

commented Oct 29, 2018

@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

This comment has been minimized.

Copy link

commented Oct 31, 2018

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

This comment has been minimized.

Copy link
Member

commented Oct 31, 2018

@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

This comment has been minimized.

Copy link
Member Author

commented Nov 1, 2018

@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

This comment has been minimized.

Copy link
Member

commented Nov 1, 2018

Derp, yes that makes sense thank you!

@chadhietala chadhietala force-pushed the new-router-helpers branch from 8fe7837 to 130ae28 Nov 2, 2018

@chadhietala chadhietala changed the title Router Helpers & Modifiers Router Helpers Nov 2, 2018

@chadhietala

This comment has been minimized.

Copy link
Member Author

commented Nov 5, 2018

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


### Event Dispatcher

In the past, only `HTMLAnchorElement`s that were produced by `{{link-to}}`s would produce a transition when a user clicked on them. This RFC changes to the global `EventDispatcher` to allow for any `HTMLAnchorElement` with a valid root relative `href` to cause a transition. This will allow for us to not only allows us to support use cases like the ones described in the [motivation](#anchor-tags), it makes teaching easier since people who know HTML don't need know an Ember specific API to participate in routing transitions.

This comment has been minimized.

Copy link
@acorncom

acorncom Nov 9, 2018

Member

@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 ...

This comment has been minimized.

Copy link
@sandstrom

sandstrom Nov 9, 2018

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

This comment has been minimized.

Copy link
@chadhietala

chadhietala Nov 9, 2018

Author Member

@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.

@chadhietala chadhietala merged commit 05f6075 into master Nov 13, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@chadhietala chadhietala deleted the new-router-helpers branch Nov 13, 2018

@@ -0,0 +1,571 @@
- Start Date: (fill me in with today's date, YYYY-MM-DD)
- RFC PR: (leave this empty)

This comment has been minimized.

Copy link
@xg-wang

xg-wang Nov 14, 2018

Contributor

PR and this RFC name should be updated

This comment has been minimized.

Copy link
@locks

locks Nov 15, 2018

Contributor

done, thank you!

locks added a commit that referenced this pull request Nov 15, 2018

@MelSumner MelSumner referenced this pull request Nov 28, 2018

Open

Octane Tracking Issue #17234

79 of 139 tasks complete

pzuraq added a commit to NullVoxPopuli/rfcs that referenced this pull request Dec 4, 2018

@locks locks referenced this pull request Dec 12, 2018

Closed

Analyze Section: Templates #252

0 of 2 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.