Distpatching updateEditorSettings does not work

[patrickgalbraith]

Describe the bug
I have a usecase where we need to update the Gutenberg global color palette after the page has loaded using javascript. I am aware of the add_theme_support('editor-color-palette', ...) PHP option but that will not work in this case.

To reproduce
Call the following:

wp.data.dispatch( 'core/editor' ).updateEditorSettings( {colors: [{name: 'test', slug: 'test', color: '#00FF00'}]} );

This works to update the editor settings, which can be confirmed using:

wp.data.select( "core/editor" ).getEditorSettings()

However nothing changes in the UI to reflect the new settings.

Expected behavior
UI updates with new settings applied.

Additional context
Wordpress v5.2.1 and Gutenberg plugin v5.8.0.

Stack overflow issue: https://stackoverflow.com/questions/56438265/updating-gutenberg-global-color-palette-in-javascript

[benjaminritner]

With the change over to select( "core/block-editor" ) there doesn't seem to be a way to update editor settings. I'm also looking for a solution to this.

[oxyc]

I think it's now called updateSettings. At least it works the same for templateLock and template asupdateEditorSettings did.

[AnthonyLedesma]

This now works as updateSettings. I was able to configure color controls by passing an array with objects as follows:

		updateSettings( {
			colors: [{...}],
		} );

[talldan]

Confirmed this issue. It looks like both core/editor and core/block-editor have very similar settings state, but many of the settings, like colors, draw from the block-editor state.

I don't fully know why it's this way. Usually core/editor is for more WordPress specific code and the core/block-editor package is for non WordPress generic block editor code.

However, I think it's misleading that they both share the same state while having different purposes, and also that they can become de-synchronized very easily, so I'm tentatively labeling this as a bug.

[gwwar]

Reading your comment, it sounds like we have two data packages that are pretty similar so folks are getting confused on which one to use. (Or there might be some props in the wrong package).

@talldan did we have any suggested next steps here? For example should we clarify package docs, or do we need something like an audit if data is being placed in the wrong store?

[paaljoachim]

I am also wondering if this is something that should be added to the Block Editor documentation.
@mkaz

[talldan]

Probably a docs clarification would be good, however I also wonder if there are some APIs here that need to be deprecated if they're no longer useful.

[apieschel]

I don't believe this issue will be solved with a docs clarification. I think it applies to some other properties in core/editor that haven't been reproduced in other data stores. I've been trying to use wp.data.dispatch( 'core/editor' ).updateEditorSettings( { availableTemplates: whitelistedTemplates } ) to restrict certain blocks to certain page templates, but dispatching updateEditorSettings to change the state does not trigger a UI update to actually change which page templates are available to the user.

[johnstonphilip]

The recommended alternative here seems to not be working. The code I am attempting to use:

wp.data.dispatch('core/block-editor').updateSettings({
  colors: [{name: 'test', slug: 'test', color: '#00FF00'}]
})

While this does update the state and can be confirmed by calling:

wp.data.select( 'core/block-editor' ).getSettings()

There is no update/change in the UI.

[htmgarcia]

The custom calls to wp.data.dispatch('core/editor').updateEditorSettings() are executed, however the moment after
a new call is triggered overriding our changes.

In the image below, the first one is my call to only allow 2 block types. The second call is triggered right after overriding my changes.

1. To reproduce, enable script debug by adding this to wp-config.php define( 'SCRIPT_DEBUG', true );
2. Go to wp-includes/js/dist/editor.js
3. Add the code below to log any call to updateEditorSettings (around line 4712 using 6.2 RC-4)

console.log('settings',settings);

Line above will log all the editor settings. To only log the settings we're trying to modify, use the appropriate syntax. In my example I'm using:
console.log('settings.allowedBlockTypes',settings.allowedBlockTypes);

UPDATE: I must mention this happens when the call is executed on load after wp.domReady