Error when React 19 component has MST node as prop with observer defined later

[filipkis]

Bug report

• I've checked documentation and searched for existing issues and discussions
• I've made sure my project is based on the latest MST version
• Fork this code sandbox or another minimal reproduction.

Sandbox link or minimal reproduction code

CodeSandbox

Describe the expected behavior

When a component is defined as bellow, where item prop is a MST Node, if that node changes the component should update without any issue.

const Comp = ({ item }) => {
  return <div>Hello {item?.name}</div>;
};

const CompLaterObserved = observer(Comp);

Describe the observed behavior

However, on React 19, the above observer usage pattern spits out errors (one for each property of the node) shown at the end. The component still updates and everything works apparently, but it's annoying and very noisy in the log (especially since it's one per property, so a big model might spint dozens of errors).

If the observer is wrapped directly e.g.

const Comp = observer(({ item }) => { ...});

then no errors are shown.

I'm suspecting this might be a mobx issue and not an MST one, but I'm not sure even where to start creating a minimal example of pure mobx error.

Here is an example of an error:

index.js:27 Error: [mobx-state-tree] You are trying to read or write to an object that is no longer part of a state tree. (Object type: 'Item', Path upon death: '/item', Subpath: 'name', Action: ''). Either detach nodes first, or don't use objects after removing / replacing them in the tree.
    at warnError (mobx-state-tree.module.js:3811:16)
    at ObjectNode.value (mobx-state-tree.module.js:1932:13)
    at ObjectNode.value (mobx-state-tree.module.js:2026:12)
    at ObservableValue.dehanceValue (mobx.esm.js:1695:19)
    at ObservableValue.get (mobx.esm.js:1751:17)
    at ObservableObjectAdministration.getObservablePropValue_ (mobx.esm.js:4782:34)
    at Object.get [as name] (mobx.esm.js:5188:26)
    at ObservableObjectAdministration.get_ (mobx.esm.js:4832:24)
    at Object.get (mobx.esm.js:3518:27)
    at addObjectDiffToProperties (react-dom-client.development.js:3968:25)
    at addObjectDiffToProperties (react-dom-client.development.js:4016:23)
    at logComponentRender (react-dom-client.development.js:4130:22)
    at commitPassiveMountOnFiber (react-dom-client.development.js:15469:13)
    at recursivelyTraversePassiveMountEffects (react-dom-client.development.js:15439:11)
    at commitPassiveMountOnFiber (react-dom-client.development.js:15718:11)
    at recursivelyTraversePassiveMountEffects (react-dom-client.development.js:15439:11)
    at commitPassiveMountOnFiber (react-dom-client.development.js:15476:11)
    at recursivelyTraversePassiveMountEffects (react-dom-client.development.js:15439:11)
    at commitPassiveMountOnFiber (react-dom-client.development.js:15718:11)
    at recursivelyTraversePassiveMountEffects (react-dom-client.development.js:15439:11)
    at commitPassiveMountOnFiber (react-dom-client.development.js:15519:11)
    at flushPassiveEffects (react-dom-client.development.js:18432:9)
    at flushPendingEffects (react-dom-client.development.js:18358:14)
    at flushSpawnedWork (react-dom-client.development.js:18323:44)
    at commitRoot (react-dom-client.development.js:17955:9)
    at commitRootWhenReady (react-dom-client.development.js:16824:7)
    at performWorkOnRoot (react-dom-client.development.js:16722:15)
    at performSyncWorkOnRoot (react-dom-client.development.js:18972:7)
    at flushSyncWorkAcrossRoots_impl (react-dom-client.development.js:18814:21)
    at processRootScheduleInMicrotask (react-dom-client.development.js:18853:9)
    at eval (react-dom-client.development.js:18991:13)

[coolsoftwaretyler]

Looks like this is an MST problem, not MobX. I tried to convert over to MobX quickly, and with something like this:

import React, { useContext } from "react";
import "./styles.css";
import { makeAutoObservable, observable } from "mobx";
import { observer } from "mobx-react-lite";

export const AppContext = React.createContext(null);

// Plain MobX store class
class Store {
  item = {
    id: "1",
    name: "initial",
  };

  constructor() {
    makeAutoObservable(this);
  }

  updateItem(newValue) {
    this.item = newValue;
  }
}

// Component without observer
const Comp = ({ item }) => {
  return <div style={{ background: "lightblue" }}>Hello {item?.name}</div>;
};

// Wrapping existing component with observer
const CompLaterObserved = observer(Comp);

// Directly observed component
const CompDirectlyObserved = observer(({ item }) => {
  return <div style={{ background: "lightblue" }}>Hello {item?.name}</div>;
});

// Create store instance outside of component
const store = new Store();

export default observer(function App() {
  return (
    <AppContext.Provider value={store}>
      <button
        onClick={(e) => {
          e.stopPropagation();
          store.updateItem({
            id: Math.round(Math.random() * 100).toString(),
            name: `item${Math.random()}`,
          });
        }}
      >
        Update
      </button>
      {/* To test the other component make sure to comment out the other one */}
      {/* <CompDirectlyObserved item={store.item} /> */}
      <CompLaterObserved item={store.item} />
    </AppContext.Provider>
  );
});

I don't see the same errors. Here is a CodeSandbox.

Not exactly sure what's going on here, I'll have to dig in a bit more, but thanks for the reproducer and sorry for the inconvenience!

[coolsoftwaretyler]

No problem with useLocalObservable and plain MobX either, so it's not due to that:

import React, { useContext } from "react";
import "./styles.css";
import { useLocalObservable, observer } from "mobx-react-lite";
import { observable } from "mobx";

export const AppContext = React.createContext(null);

const Comp = ({ item }) => {
  return <div style={{ background: "lightblue" }}>Hello {item?.name}</div>;
};

const CompLaterObserved = observer(Comp);

const CompDirectlyObserved = observer(({ item }) => {
  return <div style={{ background: "lightblue" }}>Hello {item?.name}</div>;
});

export default observer(function App() {
  const store = useLocalObservable(() => ({
    item: observable({
      // Make sure item is observable
      id: "1",
      name: "initial",
    }),

    updateItem(newValue) {
      this.item = observable(newValue);
    },
  }));

  return (
    <AppContext.Provider value={store}>
      <button
        onClick={(e) => {
          e.stopPropagation();
          store.updateItem({
            id: Math.round(Math.random() * 100).toString(),
            name: `item${Math.random()}`,
          });
        }}
      >
        Update
      </button>
      {/* <CompDirectlyObserved item={store.item} /> */}
      <CompLaterObserved item={store.item} />
    </AppContext.Provider>
  );
});

https://codesandbox.io/p/devbox/mst-component-params-demo-forked-px5y98?file=%2Fsrc%2FApp.jsx%3A1%2C1-49%2C1&workspaceId=ws_QGa4cGacuoY7BgaNFKGDj8

[coolsoftwaretyler]

I will say, I see the warnings with CompDirectlyObserved and CompLaterObserved, which makes sense. There's no real difference between the two as written and used from what I can tell. There's not actually any timing when you wrap the component in observer in a separate line.

I do think there's a real problem between MST and React 19, but these two usage patterns aren't part of it.

[coolsoftwaretyler]

I think I've hacked together a bandaid solution in #2278. I still don't understand the root cause. React 19 is accessing nodes differently than React 18 does (I don't know how yet - still investigating). But if we assertAlive more selectively, we can reduce these warnings.

[coolsoftwaretyler]

This warning doesn't show up on React 19.0.0 or React 19.1.0, but it does on React 19.2.0, so if you want to stay on React 19, you could downgrade to either of those earlier versions for now.

This will also help us isolate what went wrong here. Gotta figure out what changed in 19.2.0.

I've got a reproducer over here: https://github.com/coolsoftwaretyler/react-19-mst-warning-problem, which allows you to swap between React 18, 19.0, 19.1, and 19.2 with some npm scripts.

[coolsoftwaretyler]

I suspect the issue is coming from the new logComponentRender function in React 19.2.0. From what i can tell, it's logging out the props passed to a given React component, and enumerate nested properties of objects. That's a problem if you ever pass in an MST node that dies. If React reads those properties in an MST node, it triggers the assertAlive check. In your case, since you are swapping out the instance in updateItem, the old item (the old node passed as a prop) is dead, which throws the warning.

Here's a PR that changes React's behavior by setting supportsUserTiming to false, which short-circuits logComponentRender: coolsoftwaretyler/react-19-mst-warning-problem#1

We have a few options here:

1. MST can relax its assertAlive checks like in Fix React 19 observer pattern warnings (issue #2277) #2278, and allow reads on dead nodes.
2. We can ask React for some way to opt out of logComponentRender, either by configuring React itself, or asking if there's a way for certain props to opt out of being enumerated.

I'm not sure what to do yet, but @filipkis, I think you have a few options on your end:

1. Downgrade to React 19.1.0
2. Patch React 19.2.0 similar to fix: patch react-dom and opt out of logComponentRender manually coolsoftwaretyler/react-19-mst-warning-problem#1, (this will break your logComponentRender and any related dev tools React has shipped on top of it).
3. Find a more sophisticated patch to make it so logComponentRender ignores MST nodes specifically.
4. Patch MST with changes from Fix React 19 observer pattern warnings (issue #2277) #2278. I'm not sure what this might break. It'll make our liveliness checking less strict.
5. You could also change your Root.updateItem action. Right now, you're fully replacing the original node with a new node. That means the first instance of the node is dead, but React is reading from it (because it was the original argument passed as a prop to the component). If you merely modified its properties instead of replacing it, you'd keep the same node alive, the properties would change, and React could read it without throwing warnings to you.

Sorry for the difficulty. We just need to figure out how we want MST to interact with these updated React tools.

[coolsoftwaretyler]

It's also possible this behavior is already configurable? We have some docs around getting the current behavior: https://mobx-state-tree.js.org/API/#livelinessmode

But I can't find how to change it at runtime. I will investigate later today.

[coolsoftwaretyler]

Yup, @filipkis - looks like we have setLivelinessChecking available, which you can set to 'ignore' for now and clean up these warnings. Here's an example:

import React, { useState, useContext } from "react";
import "./styles.css";
import { useLocalObservable, observer } from "mobx-react-lite";
import { types, flow, setLivelinessChecking } from "mobx-state-tree";

setLivelinessChecking("ignore");

export const AppContext = React.createContext(null);

const Item = types.model("Item", {
  id: types.identifier,
  name: types.string,
});

const Root = types
  .model("Root", {
    item: types.maybeNull(Item),
  })
  .actions((self) => ({
    updateItem: flow(function* (newValue) {
      self.item = newValue;
    }),
  }));

const Comp = ({ item }) => {
  return <div style={{ background: "lightblue" }}>Hello {item?.name}</div>;
};

const CompLaterObserved = observer(Comp);

const CompDirectlyObserved = observer(({ item }) => {
  return <div style={{ background: "lightblue" }}>Hello {item?.name}</div>;
});

export default observer(function App() {
  const store = useLocalObservable(() => {
    return Root.create({ item: { id: "1", name: "initial" } });
  });
  return (
    <AppContext.Provider value={store}>
      <button
        onClick={(e) => {
          e.stopPropagation();
          store.updateItem({
            id: Math.round(Math.random() * 100).toString(),
            name: `item${Math.random()}`,
          });
        }}
      >
        Update
      </button>
      {/* To test the other component make sure the comment out the other one */}
      {/* <CompDirectlyObserved item={store.item} /> */}
      <CompLaterObserved item={store.item} />
    </AppContext.Provider>
  );
});

And CodeSandbox.

This is a global setting, so you can't just do it on those particular models. I'll ask around other maintainers and see if we want to do something else there, but this is a pretty built-in way to avoid the problems you're experiencing.

[filipkis]

Thanks @coolsoftwaretyler for digging deep into it.

I was sure I had an example where I had component that didn't throw error and another that did. But somewhere in the process of making the example minimal I lost the case that doesn't throw the error. Too bad, as that might have helped figuring it out.

I'll let our devs know about setLivelinessChecking - I don't think, but I think until it becomes an obvious problem we're just going to keep them visible as it's better to be aware of potential issues (sometimes it's indeed because of our own code) then to silence them fully. Also I don't think we'll be downgrading to 19.1 as I don't see this issue causing any real damage (do let me know if I'm possibly missing some risks).

Thank you one more time for all the work!

[coolsoftwaretyler]

I was sure I had an example where I had component that didn't throw error and another that did. But somewhere in the process of making the example minimal I lost the case that doesn't throw the error. Too bad, as that might have helped figuring it out.

@filipkis - I would guess you had two examples:

1. One where you didn't replace the object, but just modified it (would not show a warning because the node is still alive)
2. This one, where your updateItem action replaces the object (effectively killing it, but then React 19.2 does a read and triggers the warning).

it's better to be aware of potential issues (sometimes it's indeed because of our own code) then to silence them fully

I tend to agree. Good to leave these in. Although in this case, I really think the warning is extraneous - React is just reading from a dead node in its dev tooling. It'd be nice to provide you with a way to suppress this specific warning, and leave the default behavior. I'll think about it a bit.

as I don't see this issue causing any real damage (do let me know if I'm possibly missing some risks).

I think you're in the clear. It's just a late read on a dead node. You might pay some perf costs with the console.warn calls since you'll get them on every render. You'll have to measure your app to figure out if that really matters (and if it happens in production, etc.)

[filipkis]

I'm getting another error that's again related to React 19.2 which I haven't had time yet to dig deeper in and create a reproducible example of, but I thought I'd share anyhow:

mobx.esm.js:1268 Uncaught Error: [mobx-state-tree] assertion failed: the creation of the observable instance must be done on the initializing phase
    at new MstError (mobx-state-tree.module.js:3939:1)
    at ObjectNode.value (mobx-state-tree.module.js:1665:1)
    at executeAction (mobx.esm.js:1265:1)
    at ObjectNode.value (mobx.esm.js:1250:1)
    at ObjectNode.value (mobx-state-tree.module.js:1651:1)
    at ArrayType.value (mobx-state-tree.module.js:2554:1)
    at ObjectNode.get (mobx-state-tree.module.js:1119:1)
    at ObjectNode.value (mobx-state-tree.module.js:2016:1)
    at ObservableValue.dehanceValue (mobx.esm.js:1390:1)
    at ObservableValue.get (mobx.esm.js:1447:1)

This one is not possible to silence with setLivelinessChecking.

(And, annoyingly, in our case this is actually brakes the UI in dev, luckily not in production. But it might be just related to how our code is setup)