hi, @Fada
I have a simple idea here, which may be helpful to realize the binding you said.
Initialization
When constructing an EditorJS instance, it can specify the existing content by passing a parameter named data.
Persistence
Local to remote
When the editor’s content needs to be persisted to some place through YJS (usually in its onChange function), the latest version of the current editor can be obtained through the member method save of the EditorJS instance.
Remote to local
After the remote data changes are broadcast locally, we can apply the changes locally through EditorJS’
blocks API.
These blocks APIs can help us deal with block-level additions, deletions, and modifications.
For the internal changes of a single block, we need to decide which yType to use to build the content according to the specific block type. For example, for a block of paragraph type, we usually use yText to build its content. At this time, we need to differentiate the content of each block to ensure that only the changed part is applied.
Transformation
Since the editor’s contents are displayed in the format of native JSON, and we need to persist them to somewhere through YJS, we need to create a converter to convert them (JSON to YType)
My personal suggestion is that the entire editor’s content is an independent yDoc, and a yArray is created at its root, named blocks. Each item is a yMap, which stores the content or pointer of a specific block.