Conversation
| 4. typing in TypeScript | ||
| 5. compatible with Glimmer Components | ||
|
|
||
| ## Detailed Design |
There was a problem hiding this comment.
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@actiondecorator still populates this actions hash)? - Does it deprecate specifying an
actionshash? - What is the exact prose that will be included in the deprecation guide entry?
There was a problem hiding this comment.
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.
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.
@action will not work with .extend(; i.e. it would require a native class.
There was a problem hiding this comment.
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.
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.
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.
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.
Ok. I'm putting this in. Where in the guides can we discuss this?
There was a problem hiding this comment.
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.
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.
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.
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.
I think I agree. Would you be willing to PR this PR and help out? Probably belongs in "How we teach this" section.
| <button {{action this.actionName}}>Action Label</button> | ||
| ``` | ||
|
|
||
| it is recommended that the code is refactored instead to: |
There was a problem hiding this comment.
| 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.
The action modifier does bind the this context correctly.
There was a problem hiding this comment.
That was about the bare function above.
There was a problem hiding this comment.
Yes, if there is an action modifier in the template, the function can be bare.
There was a problem hiding this comment.
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.
Correct. However, you can fix it as @someaction={{action this.actionName}}.
Co-authored-by: Ilya Radchenko <knownasilya@gmail.com>
mehulkar
left a comment
There was a problem hiding this comment.
My middle name is Captain Pedantic!
Co-authored-by: Mehul Kar <mehul.kar@gmail.com>
| 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.
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.
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.
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.
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. |
|
@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