Discussion on: MobX Tips: New Api named flow (confusing name...)

[Kay Gosho]

Thank you for the comment, David!

I do not have to use runInAction in this use case right?
Maybe that's true.

Actually I wrote multiple MobX state change like this with mobx.useStrict(true):

    @action
    async someAction() {
        this.loading = true
        const someState = await someApi.fetch()
        runInAction(() => this.someState = someState)
    }

as you pointed out, runInAction wrap action(fn)() with friendly syntax, while flow and yield block the state change in async flow.
When I faced the MobX's cation of @action and runInAction, I started to use runInAction so I would have to understand how MobX change states.

Anyway your comment improve my comprehension of MobX!
Thanks again.

[David Schovanec]

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 :)

[Kay Gosho]

I lied to you before :( I didn't read it correctly.

No, I did not write enforceActions: true (nor useStrict(), old api) in my article. It's my fault, though thank you for clarification ;)

As you mentioned, both await and Promise wrap new function which change MobX's state so runInAction, otherwise MobX shows caution.