Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Xml Types #44

Open
PhilGarb opened this issue Dec 2, 2023 · 5 comments
Open

Support for Xml Types #44

PhilGarb opened this issue Dec 2, 2023 · 5 comments
Labels
help wanted Extra attention is needed

Comments

@PhilGarb
Copy link

PhilGarb commented Dec 2, 2023

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.
@dai-shi dai-shi added the help wanted Extra attention is needed label Dec 2, 2023
@raineorshine
Copy link
Contributor

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
Copy link
Author

PhilGarb commented Dec 3, 2023

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
Copy link
Contributor

raineorshine commented Dec 3, 2023

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
Copy link
Author

PhilGarb commented Dec 3, 2023

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants