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 actions #632

Closed

Conversation

Gaurav0
Copy link
Contributor

@Gaurav0 Gaurav0 commented May 23, 2020

For issue #629

Rendered

text/0000-deprecate-string-based-actions.md Outdated Show resolved Hide resolved
text/0000-deprecate-string-based-actions.md Outdated Show resolved Hide resolved
text/0000-deprecate-string-based-actions.md Outdated Show resolved Hide resolved
4. typing in TypeScript
5. compatible with Glimmer Components

## Detailed Design
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should use @action

Copy link
Contributor Author

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.

Copy link
Member

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() {

  }),
})

Copy link
Contributor Author

@Gaurav0 Gaurav0 May 24, 2020

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.

Copy link
Contributor

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!

Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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?

text/0000-deprecate-string-based-actions.md Outdated Show resolved Hide resolved
text/0000-deprecate-string-based-actions.md Outdated Show resolved Hide resolved
## Drawbacks

> Some older applications have thousands of string based actions throughout their codebases.
We should consider writing a codemod to ease the transition.
Copy link
Member

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?

Copy link
Contributor Author

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`?
Copy link
Contributor

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.

Copy link
Contributor Author

@Gaurav0 Gaurav0 May 25, 2020

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.

text/0000-deprecate-string-based-actions.md Outdated Show resolved Hide resolved
text/0000-deprecate-string-based-actions.md Outdated Show resolved Hide resolved
Copy link
Contributor

@knownasilya knownasilya left a 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:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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:

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@knownasilya knownasilya May 28, 2020

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.

Copy link
Contributor Author

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

text/0632-deprecate-string-based-actions.md Outdated Show resolved Hide resolved
text/0632-deprecate-string-based-actions.md Outdated Show resolved Hide resolved
@Gaurav0 Gaurav0 force-pushed the deprecate_string_based_actions branch from ab4f47e to cdee1bd Compare May 27, 2020 16:50
@Gaurav0 Gaurav0 force-pushed the deprecate_string_based_actions branch from cdee1bd to 13099a4 Compare May 27, 2020 16:56
Copy link
Contributor

@mehulkar mehulkar left a 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!

text/0632-deprecate-string-based-actions.md Outdated Show resolved Hide resolved
text/0632-deprecate-string-based-actions.md Outdated Show resolved Hide resolved
text/0632-deprecate-string-based-actions.md Outdated Show resolved Hide resolved
text/0632-deprecate-string-based-actions.md Outdated Show resolved Hide resolved
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.

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.

Copy link
Contributor Author

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.

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.

@luxzeitlos
Copy link

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 Route#refresh method.

While you proposed a new refresh method on the RouterService, which is good, it does not cover this use-case! There must be a way to refresh the current Route from the template/controller.

@Gaurav0
Copy link
Contributor Author

Gaurav0 commented May 29, 2020

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 Route#refresh method.

While you proposed a new refresh method on the RouterService, which is good, it does not cover this use-case! There must be a way to refresh the current Route from the template/controller.

Why can't you inject the router service into the controller or whatever component backs the template?

@luxzeitlos
Copy link

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.
Copy link
Contributor

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.

@wagenet
Copy link
Member

wagenet commented Jul 25, 2022

Is there still interest in moving this forwards?

@Gaurav0
Copy link
Contributor Author

Gaurav0 commented Jul 26, 2022

@ef4 Someone would need to take over this from me.

@wagenet
Copy link
Member

wagenet commented Jul 29, 2022

@chriskrycho do you want to include this in #832?

@chriskrycho
Copy link
Contributor

That would make sense to me. I keep forgetting these still exist—it got at least partially cleaned up by removing sendAction for v4.0, just needs the rest done.

@wagenet wagenet added the S-Proposed In the Proposed Stage label Dec 2, 2022
@wagenet
Copy link
Member

wagenet commented Jan 13, 2023

Thanks for your work here! This will be addressed as part of #832.

@wagenet wagenet closed this Jan 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-Proposed In the Proposed Stage
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants