[tree view] Stale item is being rendered in the tree view

[janschaible]

Steps to reproduce

Steps:

1. Open this link to live example: https://codesandbox.io/p/devbox/nervous-meadow-7jd768?from-embed=&workspaceId=ws_YZsbFftW4y4WpLsAiw2wZv
2. Open the test1 tree node
3. Click the remove button

Current behavior

CustomItem is rendered with the props test2 and test3 even though they are no longer part of items.

Expected behavior

CustomItem is only rendered with props for test1.

Context

I have tried to pass a callback to a item according to: https://mui.com/x/common-concepts/custom-components/#using-additional-props
But the items passed to the RichTreeView are inconsistent to the items being rendered.
Therefore when the callback tries to access an item by the passed id, it errors.

Maybe this is accepted behaviour - thx ?:)

Your environment

npx @mui/envinfo

  System:
    OS: Linux 6.8 Ubuntu 24.04.4 LTS 24.04.4 LTS (Noble Numbat)
  Binaries:
    Node: 24.16.0 - /home/jaschaib/.nvm/versions/node/v24.16.0/bin/node
    npm: 11.13.0 - /home/jaschaib/.nvm/versions/node/v24.16.0/bin/npm
    pnpm: 11.9.0 - /home/jaschaib/.local/share/pnpm/bin/pnpm
  Browsers:
    Chrome: 151.0.7922.108
    Firefox: 153.0.1
  npmPackages:
    @base-ui/utils:  0.3.2 
    @emotion/react: latest => 11.14.0 
    @emotion/styled: latest => 11.14.1 
    @mui/core-downloads-tracker:  9.3.1 
    @mui/material: latest => 9.3.1 
    @mui/private-theming:  9.3.0 
    @mui/styled-engine:  9.3.0 
    @mui/system:  9.3.0 
    @mui/types:  9.3.0 
    @mui/utils:  9.3.0 
    @mui/x-internals:  9.11.0 
    @mui/x-tree-view: latest => 9.11.0 
    @types/react: latest => 19.2.18 
    react: latest => 19.2.8 
    react-dom: latest => 19.2.8 
    typescript: latest => 4.9.5

Search keywords: RichTreeView additional-props stale

[noraleonte]

Thanks for the clear report and the sandbox. I reproduced it.

This seems to be an issue on our side. When items changes, the component renders one pass with the old list before it catches up. Nothing is visible on screen, but your slotProps.item callback is called with an id you have already removed, so your lookup fails.

We will look into fixing it internally.

In the meantime, the safest workaround is to read the item from the API instead of your own array:

 (ownerState) => {
    const item = apiRef.current.getItem(ownerState.itemId);
    return { /* your props */ };
  }

getItem() always returns the item the tree is currently rendering, so it cannot fail.

We are also looking at adding a removeItems() method, so removals could go through apiRef the way addItems() does today. That would avoid the problem for cases like yours. I will link it here if we open an issue for it.