Changes in @wordpress/data API

As of #26655, it is now possible to pass a store definition instead of the string when referencing a given store registered with @wordpress/data APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. This change impacts mostly the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ project. It is fully backward compatible, so pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme authors can continue using hardcoded names when referencing data stores.

The store registration has now two new methods register that takes the store definition as a param to register a store. There is also a new helper method createReduxStore that creates a data store definition for the provided Redux store options containing properties describing reducer, actions, selectors, controls, and resolvers.

Example of the store usage before this change:

registerStore( 'my-store', {
    reducer: ( state = 'OK' ) => state,
    selectors: {
        getValue: ( state ) => state,
    },
} );
import { select } from '@wordpress/data';

const blockTypes = select( 'my-store' ).getBlockTypes();

Example of the new recommended usage:

import { createReduxStore } from '@wordpress/data';

export const store = createReduxStore( 'my-store', {
    reducer: ( state = 'OK' ) => state,
    selectors: {
        getValue: ( state ) => state,
    },
} );

register( store ); 
import { select } from '@wordpress/data';
import { store as myStore } from './store';

const blockTypes = select( myStore ). getValue();

This new capability enables additional static analysis in the Gutenberg project that improve code quality. We can ensure now that all stores used in a given module are always properly defined as dependencies. In effect, it provides the correct loading order of JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. files. It also opens possibilities for new store implementations that share the same high-level API.

Finally, there is a new optional ESLint rule @wordpress/data-no-store-string-literals available in @wordpress/eslint-plugin package. It ensures that string literals aren’t used for accessing @wordpress/data stores when using API methods. The store definition is promoted as the preferred way of referencing registered stores.

This dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. was written by @gziolo.

#5-7, #block-editor, #dev-notes