Mobx: Can React's "time-slicing" and "Suspense" cause problems when used with MobX?

[AjaxSolutions]

This is a question.

I'm reading a blog written by the maintainer of react-redux, and I came across an interesting paragraph, which I quote below:

The largest reason is to improve compatibility with "concurrent React", because the entire tree will see a single consistent state value. The very short explanation on this is that React's "time-slicing" and "Suspense" features can potentially cause problems when used with external synchronous state management tools. As one example, Andrew Clark has described "tearing" as a possible problem, where different parts of the component tree see different values during the same component tree re-render pass. By passing down the current state via context, we can ensure that the entire tree sees the same state value, because React takes care of that for us.

My attention was caught by this fragment:

_...React's "time-slicing" and "Suspense" features can potentially cause problems when used with external synchronous state management tools._

Since MobX is an external synchronous state management tool, would React's "time-slicing" and "Suspense" features cause problems when MobX is used?

[mweststrate]

My understanding as the problem this far:

React has always had a different philosophy on what state is then MobX: A bit short through the corner: for React the state is the state that was rendered. This why state updates in React are async: they are only a proposal, that only becomes the truth when this state is rendered out.

The MobX model is the opposite: The state is what the state is; the source of truth, and eventually consumers of the state, such as rendering, will catch up with that truth.

The React model makes perfect sense for UI state, such as: which tab in a tab control is currently active? Because trough suspense the UI can be 'forked', so can it's state.

For domain state this model makes less sense to me, as it is more simple to reason about records that can be in only one state at the time. (E.g. I did approve an invoice, or I didn't).

Since domain state lives typically outside the component tree in MobX stores (that is what I recommend at least), and UI state lives typically in the components, I for now don't foresee much trouble in practice; keep domain state outside react and manage with MobX, keep fast paced UI interaction state inside the component tree and use setState to leverage suspense features. With that I think we should be fine.

[mweststrate]

Elaborated a bit more on this in https://michel.codes/blogs/ui-as-an-afterthought

[mweststrate]

Closing for now, can be reopened later, but since there is no documentation in any form, it would become too much of a wild guess

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs or questions.