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
Closed
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
90 changes: 90 additions & 0 deletions text/0000-deprecate-string-based-actions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,90 @@
- Start Date: 2020-05-23
- Relevant Team(s): Ember.js
- RFC PR: (after opening the RFC PR, update this with a link to it and update the file name)
- Tracking: (leave this empty)

# Deprecate String Based Actions

## Motivation

> In Ember 1.13 we introduced [closure actions](https://github.com/emberjs/rfcs/blob/00ac2685c86f27d41547012903f485a4ef338d27/active/0000-improved-actions.md) have been recommended over string based actions. This officially deprecates string based actions in favor of closure actions,
Gaurav0 marked this conversation as resolved.
Show resolved Hide resolved
which provide many benefits such as

1. simpler passing through components
2. less need for an actions hash
Gaurav0 marked this conversation as resolved.
Show resolved Hide resolved
3. ability to return a value
4. typing in TypeScript
5. compatible with Glimmer Components
Gaurav0 marked this conversation as resolved.
Show resolved Hide resolved

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


We will deprecate the following:

1. The `send` api.
2. The use of a string parameter to the `action` helper.
3. The use of a string parameter to the `action` modifier.

## Transition Path

Users will transition to closure actions.

From:

```js
export default Component.extend({
someMethod() {
this.send('actionName');
},

actions: {
actionName() {
// do something
}
}
});
```

To:

```js
export default Component.extend({
someMethod() {
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?

// do something
}
});
```

From:

```hbs
<button {{action 'actionName'}}>Action Label</button>
```

To:

```hbs
<button {{action this.actionName}}>Action Label</button>
Gaurav0 marked this conversation as resolved.
Show resolved Hide resolved
```

## How We Teach This

> We already teach closure actions exclusively in the guides. Other than a new
deprecation guide, no additional material should be necessary.

## 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?


## Alternatives

> Closure actions are now the standard in Ember, so other alternatives have not been
seriously considered.

## Unresolved questions
Gaurav0 marked this conversation as resolved.
Show resolved Hide resolved

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