I’m using y-websocket server implementation and it has CALLBACK_URL and CALLBACK_OBJECTS environment variables.
For now, if I set CALLBACK_OBJECTS as '{"quill":"XmlFragment"}' I will get content of the document as a text. The issue here that it loses all the formatting.
Is it possible to get the whole html document as a callback?
I want to save the result into the database as html document.
Hi @achempion,
The quill editor uses the Y.Text type; not the XmlFragemnt. If configured correctly, you will retrieve a Quill delta that you can use to generate an HTML document.
Any other custom conversion technique should be implemented in the y-websocket server (for example in a fork). Yjs is a generic shared editing framework and does not handle conversions.
Thank you for reply.
I looked at the callback.js and it doesn’t implement Y.Text as an option to pass into the CALLBACK_OBJECTS variable.
Right, it is just named 'Text'.
The Text option returns just the text without any formatting. The same as XmlFragment.
Right, that makes sense. I think it would be better if it returned a quill delta instead. I will adapt the behavior in the next major y-websocket release (in a few weeks). For now, you need to adapt the behavior manually, by forking the server implementation. Instead of toJSON(), you need to call .toDelta() in https://github.com/yjs/y-websocket/blob/e160a17e3a3feb1b6860b54e90b2b00d43732b03/bin/callback.js#L25.
I created a ticket for the feature request: https://github.com/yjs/y-websocket/issues/50 Since this is a breaking change, we need to wait for a major release before releasing it.
Is it possible to add new option to have an ability to send html page as well?
The callback workflow seems ideal to persist changes to the backend api with very little effort. To implement this, I think that we have to create a new Quill object, load the delta and ask quill for html content.
What do you think?
Exactly, that would be the ideal solution!
But I can’t implement the HTML conversion in the generic y-websocket server. Yjs supports a lot of editors and I can’t provide conversion techniques for every single editor format in the y-websocket provider.
The ideal solution for projects that need specific behavior is in most cases to for the server and adapt it.
Is it reasonable to add new option with javascript code which would be executed and result put as a key into the callback response? Something like CALLBACK_OBJECTS as '{"js": "return doc.getText(context.objName)"}' ?
Looks like a very dirty hack but other option is to fork server implementation and forget about easy version upgrades.
Never mind, it seems that server still has to know about editor and in order to do that you have to install it and build the new version.
Most reasonable approach is to have separate node-service which will construct html page from delta content and editor instance.