Article: MobX likes mutability. React does not

[joaovct]

Hey guys, just recently posted an article about the integration with MobX and React. When I started playing with both, coming from Redux, I was used to the "immutable" way of doing things. That made me struggle with some small things. So maybe this article is helpful to some people out there.

Let me know what you think and any possible mistakes of mine 😛

Article here 👈🏽

[urugator]

Nice. With that we should be done. Except that nothing really works now.

This is a little bit misleading, the immutable update would normally "solve" the problem, you would just loose the fine grained subscriptions mechanism - it would re-render whole subtree (and invalidate the useEffect).
The problem is you're just updating variable, there isn't any component update (not even at root), so the immutability doesn't play any role here. Understanding that variable itself doesn't count as observable state, can be an issue, but of a different kind I think.

Use primitives values as useEffect dependencies

Passing primitives is a good recommendation, but [array, array.length] not so much, because it won't play well with eslint and it won't work for nested updates. The general recommendation is to pass a deep copy using toJS (admittedly not super efficient).

Another possible solution would be “trust”

Not a good suggestion, don't run side effects in render.

why not move the console.log to the actions that triggers the update

This is imo the best way to go if the effect doesn't depend on props, DOM or other state.

Note these problems are well detectable with configure({ observableRequiresReaction: true }) (except for memo).

I am trying to address these here:

#3224

Feedback welcome.

[joaovct]

And I will take a look on that discussion

[urugator]

"The problem it’s that, because we are mutating apples, React is receiving the same reference over and over, hence, it’s supposes nothing has changed. Maybe solution it’s to keep the MobX state immutable as well?"

If you keep Mobx state immutable everything will work as if you wouldn't use Mobx at all. Meaning you still need a way to call setState somewhere (eg in root component), so that the immutable state can propagate and invalidate components (including observer), effects etc.

Consider:

const state = observable({
 apples: [],
});

const addApple = action((apples) => {
  // !!!!
  // the array update is immutable
  // the resulting array is observable (proxied)
  // it does fix the problem with effect
  // it won't break anything
  state.apples = [...state.apples, "Apple number " + apples.length];
});

const App = observer(() => {
  return <Apples apples={state.apples} />;
}

const Apples = /* same */

The article correctly identifies the problem (React is receiving the same reference over and over) and then the conclusion sounds a bit like: "if you use mobx, replacing reference won't work, you have to mutate existing array."

useEffect has a complex expression in the dependency array

I think it should be fine like this?

const _array = toJS(array);
useEffect(() => doSomething(_array), [_array]);

it will trigger the useEffect even when apples did not update

Fair point. You would have to expose it somewhere as computed (so the result is cached).

these two flows (side effect and re-render) will always run together.

In concurrent mode:
React can re-render any time and throw away the output, without running effects.
React can re-run effects without render. Dunno if it actually does somewhere, but afaik in principle it's possible (EDIT: ok I am actually not sure if it can do this, I think it could cause problems with mutable state).

Am I losing something here?

You can't perform any interesting effects in render:
You can't access DOM safely.
You can't update state of other components.
You can't do anything which requires disposal.
As noted above, anything you do in render (eg fetching data) can be a waste, because react may decide to ignore that render.

[urugator]

receive only that one state we want to run a side effect based on and does not have any other internal state (maybe a little bit idealistic)

Subscribing in render and moving effect itself to useEffect would be fine:

toJS(array); // subscribe
useEffect(() => effect(array)) // run with every (commited) render

[joaovct]

Consider:

Didn't think about this possible solution, which seems great BTW. The solution seems good, but I do opine that it isn't sometimes practical. I will edit the article including this code.

The article correctly identifies the problem (React is receiving the same reference over and over) and then the conclusion sounds a bit like: "if you use mobx, replacing reference won't work, you have to mutate existing array."

Wasn't my intention, but I will edit the article as well clarifying that, for avoiding any confusion.

You can't perform any interesting effects in render:
You can't access DOM safely.
You can't update state of other components.
You can't do anything which requires disposal.

Well... at least you can console.log 😛 (you're right tho)

Subscribing in render and moving effect itself to useEffect would be fine:

Interesting. Can you provide more explanation on that?

[urugator]

The solution seems good, but I do opine that it isn't sometimes practical.

It's not good or idiomatic solution. One should prefer mutating existing references with mobx, which admittedly leads to the problems you described. My point simply is that you can change the reference with immutable update, even with Mobx, as long as the immutable update leads to a component update in some ancestor - the updated array then propagates as usual. It's no different than eg in redux, you can't just assign new state to variable - there must be some subscription mechanism - at least at the root.

Interesting.

Not really. It's the same thing as "these two flows (side effect and re-render) will always run together" just the effect is moved to correct place. It's also the same thing as passing toJS(array) as depedency, but since toJS(array) yields different array every render, we omit it.

[nighca]

I'd like to share how we use MobX with React in our projects - these projects' sizes vary from thousands to ten thousands lines (of Typescript & React code), so we've gone through most of the problems introduced in above article.

For simple components (with simple state & logic), we use React state (useState), and ensure that data passed to them by props immutable, so that components can consume data properly with React hooks (like useEffect).

For complex components, which always consist of complex state & logic among these states, we use MobX — it helps us make state logic simpler & more testable, in contrast to hooks like useState or useReducer.

Here is a sample how we do this:

// We make a hook names `useLocalStore`,
// which do simple binding between local store and component: init & dispose
function useLocalStore() {}

// and a base class `Store`, which provides some basic abilities like `init`, `collectDisposer`, ...
abstract class Store {}

// `LocalStoreForCounter` is a store class which holds local state & logic for component `Counter`, which inherits from base class `Store`
// When we do component testing, it's easy to test state logic (the local store) separately
class LocalStoreForCounter extends Store {

  // I like class & decorator personally, though the spec for decorator is a headache
  @observable num = 0

  @action.bound increase() {
    this.num++
  }

  // `init` is a abstract method defined on base class `Store`,
  // which will be called when corresponding component mounted (the time for effect)
  // Almost all effects of one component will be implemented here, because the MobX way (such as `reaction` / `autorun`)
  // is apparently easier to use than the React way (such as `useEffect`)
  init() {
    // `collectDisposer` is a method provided by base class `Store`
    // which collects all disposers and do dispose when corresponding component unmounts
    this.collectDisposer(reaction(
      () => this.num,
      num => console.log(num)
    ))
  }
}

// For complex components, all its states & state-related logic should be placed in local store class, instead of React state
// so inter-ops between MobX state and React state are avoided
export default observer(function Counter() {
  const store = useLocalStore(LocalStoreForCounter)
  return (
    <p>
      num: {store.num}
      <button onClick={store.increase}>Increase</button>
    </p>
  )
})

We also made a DI tool to simplify dependencies among local stores, global stores and React components. But that is not related with topic here, so details are omitted in upper sample codes.

Overall, we made a convention on when and how to use MobX state in React project, which avoids most of the inter-op problems and gives us capability to maintain complex component logic.

[joaovct]

Really interesting! As the project grows, at some point it's needed to have a more opinionated way of managing the state.

Although I have more experience using mobx-state-tree than raw MobX, I noticed that, in both cases, the good practice to not mix the React state with the MobX state are always appliable, for having a maintainable code.