[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.