onChange shouldn't be fired when programmatically setting the editor's content

[cleverplatypus]

Question

Is there a way to prevent onChange when programmatically set the editor's content?

Context

The editor emits onChange event when calling editor.blocks.render(content) which, short of setting the config's data property, seems to be the only way to set the editor's content after initialization.

The problem is that if the onChange is used to detect whether a document needs to be saved, asynchronously loading data and using editor.blocks.render(content) will falsely inform the app that the content was changed.

Furthermore, even setting a previously saved content object will mutate the time value, making even relying on that value to assess whether the doc really changed non-viable.

onChange events are generally emitted upon user interaction with a widget, as opposed to programmatic content change.

Furthermore:

• the number of times onChange is called is inconsistent, so, even using the "just ignore the first time it's called" strategy doesn't work
• onChange is (sometimes) called even when just using the config.data property at creation time

Only way I found to make it work is as follows, which is not very elegant:

//...
onChange: () => {
          (async () => {
            const content = await editorJS.save();
            if (JSON.stringify(content.blocks) !== JSON.stringify(model.content.blocks)) {
              model.content = content;
            }
          })();
        },
//...

[BulavinaNk]

I have the same problem, using JSON.stringify is the worse solution, it will taken a lot of time

[jggc]

Same problem for us, there should be an option when inserting or updating a block where we can specify whether the onChange callback will be executed.

Another option would be to configure our onChange callback when we register it to specify which type of change we want to listen to.

[russelshane]

Spent hours trying to make editorjs collaborative and add auto save feature. In part of that, onChange event shouldn't be fired everytime the editor instance changes, best (but not good) solution I ever had was to artificially slow down the editorjs component.

[sadikyalcin]

Spent hours trying to make editorjs collaborative and add auto save feature. In part of that, onChange event shouldn't be fired everytime the editor instance changes, best (but not good) solution I ever had was to artificially slow down the editorjs component.

I'm also struggling with auto save. onChange fires even with just focusing in and out of a block.

[chf-gh]

When I use render to replace the old data, it trigger the onChange event, I was confused , I just want to replace the old data. what should I do ?

[neSpecc]

The blocks.render() should not lead onChange call. Give more information: editor.js version, browser.

[neSpecc]

Maybe, it needs more investigations

[altumsoftwareds]

@neSpecc @chf-gh any solution?

[neSpecc]

Do you use Safari? I see a problem in there, working on a fix

[altumsoftwareds]

@neSpecc I have data as a prop but onChange is triggered with this object: {time: 1697133260816, blocks: Array(0), version: '2.28.0'}. It overrides initial data and editor is empty

[altumsoftwareds]

@neSpecc also, editor is not rendering in some reasons. If I even try to make editor as read-only. it is not rendering data from props. on another page it works fine, can it be caused because of anything?