-
Notifications
You must be signed in to change notification settings - Fork 48
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
Deprecate Addon #109
Comments
Seems like a good idea to me... |
I've been away from the Ember community for a while now so I don't know if I have more to add here (I agree with this request)—but logistically I think only someone who is an admin of @DockYard can archive this. Maybe @brzpegasus can help if Brian doesn't see this? |
At the very minimum, just updating the README to clearly deprecate it would be a great first step if we're all in agreement! |
@bcardarella @brzpegasus any thoughts here? |
+1 to deprecating this addon. |
@elwayman02 before we called route-actions in childrens, and the action was declared at the top route level, for example:
please tell me what is the best practice in this case now |
@AmilKey I had the exact same problem, here's how I solved it. Add an action to the controllers of route3 and 5 with unique names. From these actions call |
To be honest, I'm writing a lot of boilerplate code to get the route action helper out of our application. Controllers with actions that only exist to manually trigger actions on higher level routes. |
I suspect you may need to rethink that architecture more thoroughly. It should not be common that you have to throw actions up through several levels of parent routes. |
I can think of a dozen scenarios where triggering an action on a high level route from a deeply nested route makes sense. It's just that Ember throws up all kind of restrictions, and the route action helper bypassed these restrictions, so in that sense I'm all for deprecating it. Having asked the community for input, it seems that moving all logic and state to services is the way. In general: make state global, and keep the result of state changes local. It's not necessarily how I would like it, but this is not the place for a broader discussion about Ember fundamentals. |
@Baukereg this is something @NullVoxPopuli has already been exploring here: https://github.com/NullVoxPopuli/ember-contextual-services |
@bcardarella @brzpegasus any updates here? |
@poteto @bcardarella what are your thoughts on officially deprecating this addon? It's been marked as "probably shouldn't use" for 4 years now, and it doesn't receive regular updates anymore. In general, I think Ember patterns have shifted such that we shouldn't be using addons like this to hijack action routing and should instead allow them to flow through controllers (or use the routing service, which is now widely available in Ember apps). We are working on creating a lint rule that will help people eliminate uses of this addon, but it would be great to get an official deprecation from the maintainers to signal to the community that they should no longer be adopting it. This addon is still in the top 10% most downloaded Ember addons, which signals that there's a significant portion of the community still using it even though they shouldn't.
The text was updated successfully, but these errors were encountered: