-
-
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
Deprecate string based actions #632
Conversation
4. typing in TypeScript | ||
5. compatible with Glimmer Components | ||
|
||
## Detailed Design |
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.
This is missing quite a bit of info I think.
- Which framework classes are affected?
- What are the replacement values for each of the various use cases for
.send
? - Shouldn't it also deprecate directly accessing
this.actions
(this is a thing some folks have done, and the@action
decorator still populates this actions hash)? - Does it deprecate specifying an
actions
hash? - What is the exact prose that will be included in the deprecation guide entry?
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.
Shouldn't it also deprecate directly accessing this.actions (this is a thing some folks have done, and the @action decorator still populates this actions hash)?
Added to unresolved questions for the moment.
Does it deprecate specifying an actions hash?
Added to unresolved questions for the moment.
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.
Which framework classes are affected?
Added.
What are the replacement values for each of the various use cases for .send?
Partially added.
What is the exact prose that will be included in the deprecation guide entry?
Help wanted here.
this.actionName(); | ||
} | ||
|
||
actionName() { |
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.
This should use @action
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.
@action
will not work with .extend(
; i.e. it would require a native class.
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.
I'm using @action
here to show what I mean, you can easily use that decorator in a classic Ember.Object.extend style class (just like computed):
export default Component.extend({
actionName: action(function() {
}),
})
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.
I'm doubtful we should be recommending this. This syntax is not shown in any guides, pre- or post-Octane, and will be unfamiliar.
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.
It was recommended in the 3.11 release blog post https://blog.emberjs.com/2019/07/15/ember-3-11-released.html, we used this syntax pretty extensively while migrating!
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.
If there is a gap in the guides (though I’m not sure there is) then we should fix it. That is something this RFC should work to address.
That fact does not change the direction we should advise folks to migrate to. Migrating as proposed in this RFC at the moment would be a non-trivial waste of time, and ultimately (IMO) not worth moving forward RFC wise.
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.
Ok. I'm putting this in. Where in the guides can we discuss this?
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.
Not 100% sure, maybe a "classic interop" thing in the advanced topics?
@emberjs/learning-team-managers - Thoughts?
## Drawbacks | ||
|
||
> Some older applications have thousands of string based actions throughout their codebases. | ||
We should consider writing a codemod to ease the transition. |
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.
This RFC's detailed design or transition path should include the details that the codemod should use. What would the codemod's heuristics be? How would it select what to update? How would it determine what to update to?
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.
Do you have an example RFC that does this?
|
||
## Unresolved questions | ||
|
||
> Can we also deprecate the use of the `actions` hash? Can we also deprecate using `this.actions`? |
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.
I think the difficult here is going to be less about "deprecating" this.actions
, it'll be more about figuring out how to teach people that the actions
key on a class no longer holds any special significance.
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.
I think I agree. Would you be willing to PR this PR and help out? Probably belongs in "How we teach this" section.
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.
Some small changes
<button {{action this.actionName}}>Action Label</button> | ||
``` | ||
|
||
it is recommended that the code is refactored instead to: |
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.
it is recommended that the code is refactored instead to: | |
it is recommended that the code is refactored instead to, because the above example looses its `this` context: |
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.
The action modifier does bind the this context correctly.
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.
That was about the bare function above.
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.
Yes, if there is an action modifier in the template, the function can be bare.
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.
If I remember correctly, once you do something like @someaction={{this.actionName}}
it breaks down. Which seems like a valid thing to want to do.
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.
Correct. However, you can fix it as @someaction={{action this.actionName}}
.
ab4f47e
to
cdee1bd
Compare
Co-authored-by: Ilya Radchenko <[email protected]>
cdee1bd
to
13099a4
Compare
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.
My middle name is Captain Pedantic!
Co-authored-by: Mehul Kar <[email protected]>
For cases where `send` is used to go from a controller to a route or from | ||
a route to a parent route, no direct replacement for this "action bubbling" | ||
behavior will be provided. | ||
Instead, users are recommended to inject the router service. |
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.
Could you explain this part? How does the router service remove the need to use "action bubbling"? As someone who has lots of instances of using send
in controllers/routes it would be good to have a concrete example in the Transition Path section too.
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.
Basically, there is no longer a need to use actions in a route because the router service exposes all the methods that used to be available on routes.
It may be that you have a good use case for keeping your actions in a route. If you do, let me know.
This is the idea: if you have an action in your route that would transition to a different route, move it to your component or any service and just call the routerService's transitionTo method.
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.
Thanks, that clarifies things a bit. I wonder if you could include some of this text in the rfc because that sentence is a bit vague. I'd also still recommend having an example in the Transition Path section.
I really like this, but there is one very important use case that we need to cover before we can do this. And this is the While you proposed a new |
Why can't you inject the router service into the controller or whatever component backs the template? |
The problem is that I only want to refresh the current route, not all parent routes. |
|
||
For cases where `send` is used to go from a controller to a route or from | ||
a route to a parent route, no direct replacement for this "action bubbling" | ||
behavior will be provided. |
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.
Maybe we could elaborate on this a bit?
Our app has probably ~30% of all actions in routes. Right now this is treated more like a side-effect, but for us the biggest change here would probably be what to do with all our route actions? Or perhaps I've misunderstood something?
Since things like routable components (or something to that effect) isn't available, there isn't really a clear migration path? (that I'm aware of)
Also, if all the docs are already teaching the closure actions, maybe this could be put on hold until a replacement for "actions in routes" is available?
Overall still in favor of the change, but the effect this would have on action bubbling could be expanded a bit.
Is there still interest in moving this forwards? |
@ef4 Someone would need to take over this from me. |
@chriskrycho do you want to include this in #832? |
That would make sense to me. I keep forgetting these still exist—it got at least partially cleaned up by removing |
Thanks for your work here! This will be addressed as part of #832. |
For issue #629
Rendered