search

valtiojs / valtio-yjs

valtio-yjs makes yjs state easy
MIT License
264 stars 13 forks source link

Support for Xml Types #44

Open PhilGarb opened 9 months ago

PhilGarb commented 9 months ago

Problem

One of the main values of valtio-yjs is the ability to have a more natural way to interact with the underlying yjs doc. Currently this only extends to array and map. It would be great to have support for other yjs types as well. Currently these are converted to strings, because that is what the internal anyXmlFragment.toJSON() does.

Proposal

All the xml types should not be converted internally and be just exposed as they are, because the string is useless for their intended purpose: rich-text-editors. I have a prototype of this working, but the questions are:

  1. What should the insertion mechanism be? Should the consumer insert the xml type themselves or should there be a "config" abstraction like in synced-store
  2. Should xml types be tracked by default? Typically they are used in rich-text-editors that handle state management themselves, but it could still be valuable to be notified of updates to the type in other places.
raineorshine commented 9 months ago

If the main use case of XML shared types is in rich text editors that interface directly with YJS, then I don't see much value creating a separate valtio API. Just expose the YJS shared type as-is.

However, if there is a need to subscribe to XML changes outside the editor then we can design around that use case.

PhilGarb commented 9 months ago

For us the main issue steams from the xml type being part of a larger doc and therefore deeply nested. I agree that it is possible to work with the yDoc directly, but that means no types and a different way to access things. A situation where you might want to subscribe to the xmlfragment could be something like a markdown editor with a preview.

raineorshine commented 9 months ago

I think a good first step then is to add the ability to:

  1. Access deeply nested fragments from the proxy. e.g. store.parent.child.fragment
  2. Subscribe to changes to the entire fragment.

Subtree subscriptions can be considered separately.

PhilGarb commented 9 months ago

Yes. The access and subscription are the important ones. I haven't even thought about nested subscriptions. Do you want me to submit a PR with a proposal? I have a naive prototype running.

raineorshine commented 9 months ago

I don't actually use XmlFragment in my app, so I'll leave that up to you and @dai-shi. I'm just interested in this integration and in the YJS ecosystem in general.