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

Deprecate Addon #109

Open
elwayman02 opened this issue Jul 20, 2021 · 12 comments
Open

Deprecate Addon #109

elwayman02 opened this issue Jul 20, 2021 · 12 comments

Comments

@elwayman02
Copy link

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

@rwjblue
Copy link
Contributor

rwjblue commented Jul 20, 2021

Seems like a good idea to me...

@poteto
Copy link
Collaborator

poteto commented Jul 20, 2021

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?

@elwayman02
Copy link
Author

At the very minimum, just updating the README to clearly deprecate it would be a great first step if we're all in agreement!

@elwayman02
Copy link
Author

@bcardarella @brzpegasus any thoughts here?

@shankarsridhar
Copy link

+1 to deprecating this addon.
I am curious if there are any updates regarding this.

@AmilKey
Copy link

AmilKey commented Dec 16, 2021

@elwayman02 before we called route-actions in childrens, and the action was declared at the top route level, for example:

route1 -> route2 -> route3 (call route-action "route1")
      \-> route4 -> route5 (call route-action "route1")

please tell me what is the best practice in this case now

@Baukereg
Copy link

Baukereg commented Jan 26, 2022

@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 this.send with the name of the action in the route (not controller!) of route1. This is the cleanest solution I could think of. Too bad this.send only bubbles through routes, not controllers.

@Baukereg
Copy link

Baukereg commented Feb 10, 2022

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.

@elwayman02
Copy link
Author

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.

@Baukereg
Copy link

Baukereg commented Feb 15, 2022

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.

@elwayman02
Copy link
Author

@Baukereg this is something @NullVoxPopuli has already been exploring here: https://github.com/NullVoxPopuli/ember-contextual-services

@elwayman02
Copy link
Author

@bcardarella @brzpegasus any updates here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants