-
-
Notifications
You must be signed in to change notification settings - Fork 408
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
Router Helpers #391
Conversation
414c337
to
52a287f
Compare
I'm definitely in favor of this, thanks for working on it! |
52a287f
to
7ae9850
Compare
Less magic and more control for advanced UX 👍 |
text/0000-router-helpers.md
Outdated
**After** | ||
|
||
```hbs | ||
<a href={{url-for 'profile'}} class={{is-active 'active'}}>Profile</a> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree here, I believe it should be updated to use the inline if
snippet above.
How does it related to #339 ? Will it make that one obsolete? |
Is (Or will I not care soon because it will be a matter of |
So I think the primary difference to #339 is that this assumes ordered params and not named params? |
I am not 100% sure what
So it would be a shortcut? (made up Can I have a component use the
|
@gossi and @luxferresum that is the primary difference in regards to the helpers, but this RFC also makes @lennyburdette these APIs are intended to map directly onto those provided my the router service. @juggy Yes it adds the |
Mirroring the router service API makes a lot of sense, but I would argue that the API is actually I also agree that a |
Fixed some grammar and spelling
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:
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) |
There is a “kitchen sink” example here which shows all the things that a |
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 |
@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. |
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 (:lock: @jessica-jordan) - [x] emberjs/rfcs#392 (:lock: @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 (:lock: @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)
<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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it have to be "kill controllers"? :X
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. |
After the core team call on Friday I have updated the RFC to reflect the consensus. These changes include:
The reason to remove the 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 |
42e7fb5
to
032caaa
Compare
032caaa
to
ec7dd7e
Compare
@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 |
I like these changes. Thank you! But perhaps only tangentially related, they don't address the only reason I ever extended Is there a story for dynamically generated route names that allow for an arbitrary list of models? I.E., a named In some of my apps I have code like this (after extending {{#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. |
@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? |
@rwjblue I think it is useful for the |
Derp, yes that makes sense thank you! |
8fe7837
to
130ae28
Compare
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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 ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
@@ -0,0 +1,571 @@ | |||
- Start Date: (fill me in with today's date, YYYY-MM-DD) | |||
- RFC PR: (leave this empty) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR and this RFC name should be updated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done, thank you!
Rendered