The reason runInAction does not support asynchronous

[ascoders]

On the process of collecting, which is setter, if it is triggered by the asynchronous runInAction callback, setter can be added to the execution queue corresponding to the runInAction queue to solve the problem, but in fact don't know, unless the runInAction callback is synchronous, we can set the global variable to identify.

So can i do someThing like following?

const fn = () => {
  dynamicObject.someProperty = 666
}

// runInAction1
runInAction(async () => {
  await Promise.resolve()
  fn()
})

// runInAction2
runInAction(async () => {
  await Promise.resolve()
  fn()
})

In the pre bound setter of dynamicObject.someProperty, know which runInAction1 or runInAction2 trigger I am?

[andykog]

@ascoders, no, runInAction only applied to what runs synchronously. There is no mechanism in JS to do what you want reliably (if runInAction will wait until your promise resolved, how to know, if some was invoked in your promise or somewhere else?). You can make something like:

runInAction(async () => {
  fn() // this part runs sync, so everything ok
  await Promise.resolve()
  runInAction(fn) // this part needs another runInAction call
})

[ascoders]

Thanks @andykog, This is the most regrettable, only to see the way Babel pretreatment, but this is contrary to the code running mode, maintainability is not good.

But I think the principle is feasible, if the callback is async, all triggered setter corresponding triggered autoRun push to the isolated queue, when .then run this queue.

The focus is on how to isolate.

[andykog]

@ascoders, do you have some specific propositions on how to tell whether the “setter” was called as a result of some async operation that relates to action without reinventing javascript (event loop, promises…)?

[ascoders]

Not yet, as long as the problem solved, runInAction can support asynchronous callback. 😍

[andykog]

@ascoders, cool, then, closing the issue