cms-admin: Fix block editor keeping the previously selected block's content

[SebiVPS]

Summary

Clicking a block in the block preview opens that block's editor in the block list. If the newly selected block had the same type as the previously selected one, the editor kept showing the previous block's content — so after the first click, the panel appeared unresponsive.

Most visible with the TipTap rich text block: select one rich text block in the preview, then click a different one, and the editor still holds the first block's text.

Root cause

Two block factories render the active block's admin component without a key:

• createBlocksBlock.tsx — StackPage name="blocks"
• createListBlock.tsx — StackPage name="edit"

<block.AdminComponent state={match.props} updateState={createUpdateSubBlocksFn(id)} />

The routing layer is correct: the SelectComponent message arrives, history.push navigates, and state.blocks.find((c) => c.key === id) resolves the right block, passing the new state down. The problem is purely React reconciliation — the element sits at the same tree position with the same component type and no key, so React re-renders the mounted component rather than remounting it.

That is fine for editors that render straight from props, but not for editors that build internal state on mount. createTipTapRichTextBlock calls useEditor({ ..., content: state.tipTapContent }) without a deps argument, so @tiptap/react defaults to deps = []. With an empty deps, the hook never takes the refreshEditorInstance path and instead only calls editor.setOptions(). setOptions merges the new options but never rebuilds the document — options.content is consumed solely by createDoc() at construction time. The ProseMirror document therefore keeps whatever content it was created with.

This is also why the bug is type-specific: switching to a block of a different type swaps in a different component function, which forces a genuine unmount/mount and reloads the content correctly.

Changes

Key the admin component by the selected block's key in both factories, so React remounts it whenever the selection changes.

-<block.AdminComponent state={match.props} updateState={createUpdateSubBlocksFn(id)} />
+<block.AdminComponent key={id} state={match.props} updateState={createUpdateSubBlocksFn(id)} />

Keying at this level was chosen over passing deps to useEditor in createTipTapRichTextBlock, because it fixes the class of problem — any block editor holding mount-time internal state — rather than only the TipTap case.

Reproduction

1. Open a page or article with two or more rich text blocks in the admin.
2. Go to the Content tab.
3. Click one rich text block in the preview — its editor opens correctly.
4. Click a different rich text block in the preview.
5. Before: the editor still shows the block from step 3. After: it shows the newly selected block.

Verification

Verified manually in a consuming project by applying the equivalent change to the compiled @comet/cms-admin in node_modules: after the change, selecting successive rich text blocks in the preview updates the editor each time. Selecting blocks of differing types continued to work as before.
Verified in demo before and after the change.

[VPS-Obi]

Two things worth deciding before you open it:

Verification is single-path. I confirmed the fix against the TipTap rich text case only, via the patched compiled package. Adding a key changes remount behaviour for every block admin component, so it's worth a quick pass over other stateful editors (the list block's edit page especially) to be sure nothing relied on the old re-render-in-place behaviour — e.g. anything holding scroll position or uncommitted local edits across a selection change.

Comet is on GitHub, so this will be a pull request rather than a merge request — the description works either way, but gh pr create is the tool, not the GitLab MCP.

Please update the PR description by fixing the formatting and removing chat parts (the PR description will be the squashed commit's description). Or tell Claude to update it 😁

[VPS-Obi]

That is fine for editors that render straight from props, but not for editors that build internal state on mount. createTipTapRichTextBlock calls useEditor({ ..., content: state.tipTapContent }) without a deps argument, so @tiptap/react defaults to deps = []. With an empty deps, the hook never takes the refreshEditorInstance path and instead only calls editor.setOptions(). setOptions merges the new options but never rebuilds the document — options.content is consumed solely by createDoc() at construction time. The ProseMirror document therefore keeps whatever content it was created with.

Wouldn't the more appropriate fix be to provide state.tipTapContent as dependency for useEditor()? @nsams what do you think? Or would this result in an infinite update loop?

[VPS-Obi]

Adding a key to the admin component is probably a good idea (I wonder why this never made problems up until now). Still, we should fix the root cause as well, which is the missing dependency array for useEditor IMO.