Should all action handlers have an implicit await Promise.resolve()?

[NullVoxPopuli]

I've been seeing in increasing number of issue reports related to event handling and autotracking that are resolveable by placing an await Promise.resolve() at the top of their action-handling function (or concurrency task). Should this be a default?

For those that don't know, await Promise.resolve() is a bit of a hack you can add to any function that is invoked within a tracking context to "disconnect" that function from the tracking context, allowing you to bypass the infinite revalidation assertions due to the function running on the next task queue (which very likely isn't during an autotracking frame).

Example: glimmerjs/glimmer-vm#1342

[nightire]

So use next from @ember/runloop to wrap inner logic in actions should also work like await Promise.resolve(), right? I've already used it occasionally.

[chriskrycho]

Definitely not! In every case I've seen this, when we dug in it exposed actual bugs. Doing this would generally not have the desired outcome—it would just introduce needless delay into when actions get run—and as @runspired called out on that thread, this is absolutely not an issue with Ember's design and indeed not an Ember-specific issue. It is, rather, a case where we can and should make it easy for people to understand why it's happening (via docs, etc.).

[NullVoxPopuli]

Thanks for the explanation!

Now it's documented :D 💯