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 string based action handling #629

Closed
mehulkar opened this issue May 20, 2020 · 9 comments
Closed

Deprecate string based action handling #629

mehulkar opened this issue May 20, 2020 · 9 comments
Labels
Seeking Co-author T-framework RFCs that impact the ember.js library T-templates

Comments

@mehulkar
Copy link
Contributor

mehulkar commented May 20, 2020

We should deprecate all forms of string based actions. This includes:

@rwjblue rwjblue added Seeking Co-author T-framework RFCs that impact the ember.js library T-templates labels May 20, 2020
@rwjblue
Copy link
Member

rwjblue commented May 20, 2020

Thanks @mehulkar! I added a few labels to clarify where this is at. I personally think it should be possible to start charting out what that RFC would look like...

@chriskrycho
Copy link
Contributor

chriskrycho commented May 21, 2020

I was talking with team members around this same topic today, especially this.send. The only significant blocker for its removal I could think of is that it’s the normal and idiomatic way to trigger an action on a route from its controller, which is currently the only way to fully reload a route’s model (using Route.refresh). The only alternative I’m aware of is to look up the corresponding route using the container, e.g. getOwner(this).lookup('route:same-as-controller').refresh().

An obvious intermediate step there might be to support refreshing a route on the router service. That would need to be designed independently of this, but it’s the only thing I know of which actually requires this.send in idiomatic Ember today. That would also be a nice step along the path of removing places we still need controllers today, and in a direction well-aligned with current directions in Ember API design. (I think there’s actually an open issue for this somewhere but I can’t find it and am typing on mobile at the moment.)

cc. @gabrielcsapo @jackson-dean

@mehulkar
Copy link
Contributor Author

mehulkar commented May 21, 2020

FWIW, it's not required, per se. There are a few ways to do this without .send. None of them are good, but 🤷

  • Set Route.refresh as a property on the controller in setupController
  • Use lookup('route:${RouterService.currentRouteName}').refresh()
  • Use ember-route-action-helper addon

@rwjblue
Copy link
Member

rwjblue commented May 21, 2020

It isn't immediately obvious that we need per-route .refresh functionality to me (though maybe folks could share good use cases), and if that is the case then I think a top level router service .refresh method might be all we need.

@mehulkar
Copy link
Contributor Author

That would also be a nice step along the path of removing places we still need controllers today,

Also, for the record, my understanding from #574 (comment) is that the core team was not in favor of incremental progress towards removing controllers.

@chriskrycho
Copy link
Contributor

Certainly every use care I’ve hit for refresh would be solved by a single method on the router service. I’d also be curious if others can supply scenarios where that’s insufficient!

Also, note that ember-route-action-helper is deprecated; it’s a persistent source of issues for us and getting off of it is one of our motivations in this space.

@rwjblue
Copy link
Member

rwjblue commented May 21, 2020

Also, for the record, my understanding from #574 (comment) is that the core team was not in favor of incremental progress towards removing controllers.

IMHO, this case is a bit different. A couple reasons:

  • Deprecating .send actually simplifies the programming model for controllers as well as without them
  • Adding .refresh to router service addresses a gap (again regardless of controllers). It is a place where the dream/intent of the router service falls down: that there is "one router" and that router:main (app/router.js) vs service:router are indistinguishable.

Deprecating small pieces of functionality that only affects controllers, just for the sake of deprecating them, is the thing that seems bad/wrong (at least to this core team member). Deprecating a conceptual unit (this issue is discussing {{action + this.send for both controllers and routes) in phases is a very different thing.

@chriskrycho
Copy link
Contributor

FWIW, I second Rob’s take (as a non-Core-team member). I simply observed that this change—well-motivated already on its own—is a case where landing it also produces incremental progress toward a potential removal of controllers in the future, because there’s lower coupling and one fewer hard dependency on them. It’s a nice bonus from making the programming model more consistent, rather than the point.

@mehulkar
Copy link
Contributor Author

mehulkar commented Jun 4, 2020

Since #632 has been opened and only the details need to be worked out, I think this is good to close! Thanks @Gaurav0!

@mehulkar mehulkar closed this as completed Jun 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Seeking Co-author T-framework RFCs that impact the ember.js library T-templates
Projects
None yet
Development

No branches or pull requests

3 participants