`path` prop in plate elements is not being updated properly

[delijah]

Description

path prop in plate elements is not being updated properly. This leads to errors when making use of that variable.

Reproduction URL

https://codesandbox.io/p/devbox/pqm7xr

Reproduction steps

1. Place your cursor on the first (empty) line
2. Press enter
3. You can see, that the path of the last element did not update
4. Press enter again
5. Same behaviour
6. Place your cursor on the first line again
7. Press enter
8. You can see, that the path of every element below the current one, did not update

Plate version

49.2.6

Slate React version

0.117.1

Screenshots

Logs

Browsers

Chrome

[dosubot]

Hi @delijah! I'm Dosu and I’m helping the plate team.

This issue is likely caused by how Plate manages node paths and updates after document changes. Recent changes in normalization logic and selection handling could affect path updates, especially if plugins or custom handlers interfere with Plate's default behavior. Issues can also arise if you use custom break rules (like break: { default: 'lineBreak' }) or insert nodes via toolbar commands instead of markdown shortcuts—these can break node structure and prevent paths from updating as expected [discussion].

To debug: try removing any custom break rules, check your plugin order, and compare node insertion via toolbar vs. markdown shortcut. If the problem goes away in a minimal setup, add plugins back one by one to isolate the cause. The core path update logic lives in Plate's element rendering and normalization code, which recently changed in PRs #4512 and #4537 [PR #4512] [PR #4537]. If you still see the issue, sharing your plugin config or custom handlers may help pinpoint the problem.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[delijah]

Did some more investigations...

It looks like, the path prop will only update, when the node (data/content) has been modified and re-renders. So a valid question could be: should the component be re-rendered, just because the path changed? This could decrease performance.

1. Do not re-render the element, when only the path changed, but not the node itself
   Downsides: path variable is not reliable, might be confusing for developers
   Upsides: Performance

2. Do re-render the element, even if only the path changed, but not the node itself
   Downsides: Performance decline
   Upsides: path variable is always up to date

Now with option 1, one could argue: ok, but what is even the problem, when the path only updates when the component is re-rendered? The problem is, AFAIK, the path variable is not updated with the 1st re-render cycle, but only for subsequent ones, because we use useEffect in order to check if the path should be re-calculated:

plate/packages/core/src/react/utils/pipeRenderElement.tsx

Line 22 in 4b50472

const path = useNodePath(props.element)!;

https://github.com/udecode/plate/blob/main/packages/core/src/react/hooks/useNodePath.ts

plate/packages/udecode/react-utils/src/useMemoizedSelector.ts

Line 22 in 4b50472

React.useEffect(() => {

This is my assumption for now...

[delijah]

Another thought: i would expect that useNodePath triggers a re-render, whenever a nodes path has been changed. Regardless of this current scenario. But idk, maybe the editors performance has a higher prio than meaningful hooks 🤔

[zbeyens]

We need useNodeSelector(({ editor, node, path }) => ..., deps), so we could control the re-rendering. It can't be used by default for performance: insert a block at the top and every block would re-render.

[delijah]

Ok, in understand. It cannot be changed in that place. I've created a useNodePath hook therefore, which will trigger a re-render, whenever a path of a node has been changed, and can be used where needed. At least i've tried 😅

I guess you will ask me to do it with jotai selectors/atom stuff. I am a bit overwhelmed over there to be honest. Not sure how this works.

Here we go: #4547

[zbeyens]

So we'll keep this limitation for performance reason. Closing this issue then.