Make less assumptions on Yjs provider for collaboration

TipTap2 is making some strong assumptions on Yjs providers. Although accessing a provider directly makes sense for the awareness protocol, it might conflict with other uses of a Y.Doc.

If technically possible, I would suggest providing a Y.XmlFragment instead of a provider (or optionally). Also destroying the provider from the component does not seem to be a good idea.

The benefit from that would be, that the component could be used for multiple editors using the same provider simultaneous on the same page.

Not sure if that makes sense anyway 😉

[holtwick]

I see. I guess a rough priority ordering should still be possible for most cases, because you are ordering the extensions already now somehow 😉 If the priority ordering would already work for the extensions that come with TipTap itself, this is certainly a win. Those that do not need a priority could still keep the order they have in the configuration as it is right now. For example by default priority 0. All those that need to execute earlier a value > 0 and vice versa for the later ones.

[samwillis]

Perfect!

It would be something like this:

// Add Y.XmlFragment to root Y.Array
const yarray = ydoc.getArray('note_list')
const yxmlNested = new Y.XmlFragment()
yarray.push(yxmlNested)

// Retrieve fragment for TipTap
const yarray = ydoc.getArray('note_list')
Collaboration.configure({
  fragment: yarray.get(0),
})

The docs for Y.Doc and the fragments are here: https://docs.yjs.dev/api/y.doc