Handle node view desc ref churn

[goranmoomin]

This PR fixes the issue from https://github.com/goranmoomin/react-prosemirror-node-ref-churn-repro as well as https://github.com/goranmoomin/react-prosemirror-mark-ref-churn-repro, the first repository also being a test case for #276.

CleanShot.2026-08-19.at.16.36.34.mp4

CleanShot.2026-08-19.at.16.37.52.mp4

Both are cases where the node view or the mark view uses a callback ref (I personally encountered them when using shadcn/ui popover inside a node view). This is also a patch that we've been using for quite some time, but renamed a few variables and cleaned up.

The issue is that getDOM() can be null when a callback ref is used due to the cleanup call of the callback, and as soon as that happens, the current code just loses the view descriptor altogether. This fix includes some logic to make sure that we don't churn the view desc if getDOM() dips to null and then gains the dom element back. Unfortunately, this means that if the ref gets null permanently (i.e. the node/mark view renders null) then we can't cleanup the view desc, but I think that's a non-problem for now (since that's just not a valid case) as well as we would be able to clean up the descriptor when it does actually render something again or if the component unmounts. (At least that was my personal, non-LLM assessment.)

The same issue exists for the mark view, TBH I don't remember 100% on what the issue was for the mark view in our application, but we did have issues around the losing the descriptor as well, the repro case is a bug and we have been holding this patch for like at least a month or two, so pushing it together in the PR as well.

[goranmoomin]

Edit: I was having Fable play around for the patch and realized it breaks for StrictMode (which seems obvious in hindsight), so I pushed a fix for that as well.

[smoores-dev]

There's some nuance here, I need to dig into this a bit more. Thank you for reporting, by the way! I think we need to overall handle unstable callback refs better — this solution works fine until you add a node decoration to the node with an unstable ref. Then the app crashes with a max recursion limit 😕 (that was true before this change, to be clear). I think we may need to step back and take a wider look at how we're handling ref updates!