guides-source
guides-source copied to clipboard
ember-learn
Document @action async foo()
@action async foo() {} seems like a really nice way to write code, but there are some gotchas that should be documented. Probably should go here: https://guides.emberjs.com/release/components/component-state-and-actions/
Following a discussion in Discord with @acorncom @raido @bendemboski @Turbo87.
I would strongly recommend to not document this as a "really nice way to write code" because it is very error-prone, even when people are aware of the pitfalls.
I agree this should not be promoted as the "way". But guides also lack at the moment the pitfalls what can/will happen if you do async operations in your actions without handling isDestroyed state of the component for example.
I would strongly recommend to not document this as a "really nice way to write code" because it is very error-prone, even when people are aware of the pitfalls.
I'm curious which specific pitfalls you are thinking of. From my perspective using @action to bind functions that are passed down into children and whatnot is completely unrelated to the return value of those functions (indeed they can return anything!!), what makes returning a promise more or less error prone than any other value?
I'm curious which specific pitfalls you are thinking of
my main issue is that checking isDestroying and isDestroyed is very easy to forget and I've seen a lot of codebases where it wasn't done at all. I admit though that this is generally not limited to actions and applies to all kinds of async methods.
I'm curious which specific pitfalls you are thinking of
Less about whether a function returns a promise or not, and more about whether it yields to the system (awaits) and then runs more code potentially accessing state on a destroyed object, right?
