Gutenberg doesn’t react on changes which were caused by external scripts

[lex127]

We are trying to add an extra functionality to Gutenberg but faced with a critical a problem. Gutenberg doesn’t see changes that are caused by external scripts. For example, if we try to change text using browser Range API, Gutenberg won’t react on (ignore) these changes. What is critical here – those changes won’t be applied after Updated/Publish actions. And this is quite frustrating, this is not what the end user might have expected when finally published a post, or updated a page.

We have tried to subscribe on saving post (see code below) but changes still are not applied.

wp.data.subscribe(function() {
    if (wp.data.select('core/editor').isSavingPost()) {
        // What should we call to apply our changes before Upload
    }
});

…..
Could you please suggest if there is something else we can try to overcome this problem? Or probably this is the case that must be taken into account, as other developers might face the same issues.

[gziolo]

if we try to change text using browser Range API, Gutenberg won’t react on (ignore) these changes.

Yes, this is the expected behavior. You should be using wp.data.dispatch (https://github.com/WordPress/gutenberg/tree/master/packages/data#dispatch-storename-string--object) to trigger update inside the editor instead which is going to be reflected in the DOM. @aduth do we have a more detailed document explaining those concepts in depth?

[aduth]

There's not currently a document which describes programmatic edits, but yes, this is the way you'd want to do it. Gutenberg uses its store as the source of truth, not the DOM.

Specifically, one of the following actions can be used to edit the attributes of a post or of a block, respectively:

• https://wordpress.org/gutenberg/handbook/designers-developers/developers/data/data-core-editor/#editpost
• https://wordpress.org/gutenberg/handbook/designers-developers/developers/data/data-core-editor/#updateblockattributes

I'm not positive whether these changes can take effect at the specific time a save starts. Ideally they'd be done earlier, as soon as it becomes relevant that a change be made. This is also discussed elsewhere in #13413, #7020.

In your specific code example, you should want to be careful to consider that subscribe will be called on any change to any store, so it's not just going to satisfy your condition of isSavingPost the one time it transitions from not-saving to saving.

You'll need to track the previous value to see whether it had changed. See similar: https://github.com/WordPress/gutenberg/blob/master/packages/edit-post/src/store/utils.js

I'll proactively consider the help request as resolved, with potential for further pre-save validation / behaviors as tracked at #13413.

[lex127]

Why do you not listen MutationObserver for handling all changes in the DOM?

How do you plan to work with native browser spell check?

There are many other third party scripts which make changes using Range API (for changing some part of text). So you will ignore these changes too.

We can emulate changes after replace some part of text with Range API. We do it using fake InputEvent which we fire on editable field. But this is not clear solution. And this fake event doesn't work for Classic block (TinyMCE editor).

Solutions suggested by you is not applicable in our case.

[aduth]

The block editor uses its internal data stores as the single source of truth, not the DOM. An implication of this is that you must interact with the store using the exposed actions as an interface, not by mutating the DOM directly.

That being said, the role of a component like RichText is to interpret events from the DOM and translate them to the corresponding state changes. This is how something like spell check would be handled. If you must manipulate the DOM directly and expect it to be reflected in the blocks state, you must do so in a way which would be understood by the implementation of the RichText component. Note that this is not a use-case which is officially supported, and the internal implementation of RichText may change over time. The data actions are the recommended interface.