I lied to you before :( I didn't read it correctly.
It would work as expected because there is just one setter and mobx can handle that.
But when we turn on mobx.configure({ enforceActions: true }) it would fail. And it would fail even with @action async someAction() {....} because await is asynchronous and outside the original @action function. In this example this.someState = await waits to await. So your original example was correct :)
It really depends on many things (enforceActions: true, @async decorator, etc ...). Great explanation on this (new for me) page mobx.js.org/best/actions.html :)
I lied to you before :( I didn't read it correctly.
It would work as expected because there is just one setter and mobx can handle that.
But when we turn on
mobx.configure({ enforceActions: true })it would fail. And it would fail even with@action async someAction() {....}becauseawaitis asynchronous and outside the original @action function. In this examplethis.someState = awaitwaits toawait. So your original example was correct :)It really depends on many things (enforceActions: true, @async decorator, etc ...). Great explanation on this (new for me) page mobx.js.org/best/actions.html :)
No, I did not write
enforceActions: true(noruseStrict(), old api) in my article. It's my fault, though thank you for clarification ;)As you mentioned, both
awaitandPromisewrap new function which change MobX's state sorunInAction, otherwise MobX shows caution.