[lexical-yjs][lexical-react] Feature: Allow custom Yjs XmlText

[flaviouk]

Description

• Added the ability to customise which Yjs XmlText element lexical uses. This is helpful in cases where we can have multiple editors in the same ydoc
• The existing example of multiple collaborative editors (sticky note) assumes this data will be placed in different yjs documents, but the same document can contain many editor data
• The other example is comments, this one uses the same yjs doc with a custom store interface (We can set/edit/delete them but we can't get cursors or realtime updates as the user types - obviously the same user, but in different devices)

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
lexical	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 1, 2024 8:20am
lexical-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 1, 2024 8:20am

[github-actions]

size-limit report 📦

Path	Size
lexical - cjs	29.05 KB (0%)
lexical - esm	28.86 KB (0%)
@lexical/rich-text - cjs	37.39 KB (0%)
@lexical/rich-text - esm	28.33 KB (0%)
@lexical/plain-text - cjs	36.02 KB (0%)
@lexical/plain-text - esm	25.6 KB (0%)
@lexical/react - cjs	39.29 KB (0%)
@lexical/react - esm	29.77 KB (0%)

[etrepum]

This changes a public API in a backwards incompatible way, so it might be tricky to accept as-is

[flaviouk]

This changes a public API in a backwards incompatible way, so it might be tricky to accept as-is

Thanks for reviewing @etrepum!

I thought about adding another param but I think a object param is probably better for the amount of parameters this function takes.
Either way, happy to make any change, just need a way to customise the XmlText element, let me know what you think

[etrepum]

I don't disagree that an options object probably makes more sense, but this is a module that gets a fair bit of use and I think it's unlikely to get approved without a migration plan that does not immediately break compatibility.

I think the other concerns will be around what the use case is (a more concrete description would probably make sense, since there are existing examples that use multiple editors in the same collab without this feature, e.g. sticky notes and comments in the playground), as well as the lack of tests and documentation around the new feature.

[flaviouk]

I don't disagree that an options object probably makes more sense, but this is a module that gets a fair bit of use and I think it's unlikely to get approved without a migration plan that does not immediately break compatibility.

I think the other concerns will be around what the use case is (a more concrete description would probably make sense, since there are existing examples that use multiple editors in the same collab without this feature, e.g. sticky notes and comments in the playground), as well as the lack of tests and documentation around the new feature.

Thanks for the feedback @etrepum. I've updated the API now to receive an additional parameter.

[Mati20041]

Hey, I have faced the same limitation/issue for multi document environment. Is it still planned to add this feature?

EDIT: I saw the refactor of collab plugin. Would be great if specifying field in a ydoc is possible for instance for multiple editors being able to share the source instead of making more connections #7616

[potatowagon]

Review: Allow Custom Yjs XmlText

Reviewed by: Navi (AI review assistant for @potatowagon)

Summary

Adds an optional getXmlText parameter to createBinding() and threads it through CollaborationPlugin, allowing consumers to customize how the root XmlText is obtained from the Yjs Doc. Default behavior (doc.get('root', XmlText)) is preserved.

What I Verified

• Backward compatibility: The parameter has a default value (getXmlText = (ydoc: Doc) => ydoc.get('root', XmlText) as XmlText), so existing consumers are unaffected.
• Typing: Flow types updated correctly. TypeScript infers from the default parameter.
• React hook deps: getXmlText is correctly added to the useEffect dependency array in CollaborationPlugin. Consumers should memoize this callback to avoid unnecessary rebindings.
• Scope: Minimal 8-line change in core binding logic + prop threading. No behavioral changes for existing users.
• CI status: Only CLA check passed (no full test suite ran, likely due to age of PR). The change is trivial enough that this isn't concerning.

Concern

• This PR is from June 2025 — it may have merge conflicts with the current main branch. Worth checking if it still applies cleanly.
• Consumers passing an unstable getXmlText reference would cause repeated binding recreation (the hook dep array issue). A doc comment suggesting memoization would help.

Verdict

✅ Safe to approve — clean, minimal API extension with sensible defaults. No regressions possible for existing users.

[potatowagon]

Review — Allow Custom Yjs XmlText

Assessment: Needs attention — minimal CI ⚠️

What I verified:

1. Feature scope: Allows consumers to provide a custom Yjs XmlText instance for collaboration, enabling more flexible Yjs document structures.

2. CI status: Only CLA check passes. No test suite has run — this is the oldest PR in the queue and likely needs a significant rebase.

3. Staleness: Last updated May 29 (likely automated), but the actual code may be quite outdated relative to the current collab infrastructure (especially given the Named Slots PR #8603 which heavily touches Yjs integration).

Recommendation:

Author should rebase and ensure compatibility with current collab architecture. Given the Yjs-related changes in other active PRs, this may need rework.

— via Navi on behalf of potatowagon