New Rule: no-async-actions

see http://ember-concurrency.com/docs/tutorial (scroll down to Version 4)

Bad:

actions: {
  async handleClick() {
    // ...
  }
}

actions: {
  handleClick() {
    return something.then(() => { /* ... */ });
  }
}

@action
async handleClick() {
  // ...
}

@action
handleClick() {
  return something.then(() => { /* ... */ });
}

Good:

actions: {
  handleClick() {
    return nothingOrSomethingThatIsNotAPromise;
  }
}

[bendemboski]

Is there a reason this is targeting actions specifically, as opposed to any member functions of EmberObject or glimmer Component sub-classes? Seems like the pitfalls aren’t unique to “actions,” and the @action decorator no longer even really implies that it’s called from a template, so targeting “actions” seems a little arbitrary?

[bendemboski]

@mansona I’m still not sold. Everything you said makes sense, but I think this will only partially address what it’s aiming for and could introduce further confusion. Async scenarios that this won’t cover:

1. A non-async action that calls an async function (without await’ing obviously)
2. An async function (not action) on a component triggered and this-bound by some eventing mechanism, e.g. @ember/object/events or eventemitter3
3. An async function on a service

All of the above have the same pitfalls as the targeted scenario, and only differ from the targeted scenario in that they are less common in practice (probably, although I think async service functions are pretty common).

Further points of confusion:

1. The rule says that it’s targeting components, but looking at the PR, it doesn’t look like that’s the case? Maybe I’m mis-reading, but it looks like it will flag any async function decoration by @action, whether in a component or not.
2. The original rationale (version 4 of http://ember-concurrency.com/docs/tutorial/) is a kinda deprecated scenario (not technically deprecated I don’t think, but clearly not Modern Ember) – using Ember.set(). There’s no runtime assertion if you set a @tracked property after its object is destroyed, and there’s no inherent harm – the autotracking system is unrelated to the isDestroying/isDestroyed, so its just like setting a property on a {} that your application logic has “stopped using”.

So it looks like this is partially addressing a problem that is not clearly rationalized for modern Ember code. Given that the problem itself, especially when considered in the absence of Ember.set(), is not at all specific to Ember (you always have to be careful with async functions inside class methods!), and @action already kinda confuses people and suggests that it’s more “magical” than it is in non-EmberObject usages, I really worry that this rule will end up doing more harm than good.

A couple of ways I could see improving the situation somewhat:

1. Target only EmberObjects, or perhaps only Ember.Components and Ember.Controllers (because they are much more likely to be using Ember.set() rather than @tracked)
2. Do the “deeper” parsing of the function, looking for Ember.set() invocations, so it’s really the lint-time warning about that specific runtime assertion.
3. Rationalize it as a use-ember-concurrency-for-async-behavior or something, where any async member function anywhere is flagged (perhaps with some post-await this checks or something). This would be putting a rule that’s not at all Ember-specific in Ember’s linting package, but I could see justifying that because we have a specific recommendation to make (ember-concurrency).

Regardless, at the very least I think we need to understand whether this rule is actually meant to target only components (and ensure that the implementation agrees with that), and if it’s meant to target more scenarios than just the Ember.set() assertion, provide document/examples of some of those other scenarios and the related pitfalls.