Gutenberg: 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

[kadencewp]

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.