Support for handling resolution errors for Editor data module

WordPress 6.0 no longer ignores the exceptions thrown by the resolvers.

In WordPress 5.9 and earlier, an exception thrown inside the resolver kept it in the resolving state forever. It never got marked as finished. In WordPress 6.0, the resolver state is set to error and the exception is re-thrown. This backwards compatibility-breaking change affects both resolvers from newly registered stores and the resolvers from the WordPress stores, e.g. the getEntityRecord resolver from the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. store.


Let’s register an example store where the resolver always throws an error:

const temperatureStore = 'my-store', {
    selectors: {
        getTemperature: ( state ) => state.temperature
    resolvers: {
        getTemperature: () => { throw new Error( 'Network error' ); }
    reducer: () => ({}), // Bogus reducer for the example
} ); temperatureStore );

Using that resolver has different results in different WordPress versions:

In WordPress 5.9:

const promise = temperatureStore ).getTemperature();

Error handling is unsupported, so this promise never gets rejected nor resolved.

In WordPress 6.0:

const promise = temperatureStore ).getTemperature();

Error handling is now supported, so this promise gets rejected with Error( ‘Networknetwork (versus site, blog) error’ )

The error details may be retrieved using the hasLastResolutionFailed, getLastResolutionFailure, and `getResolutionState` metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.-selectors available on every registered store: temperatureStore ).hasResolutionFailed( 'getTemperature' );
// the above returns: true temperatureStore ).getResolutionError( 'getTemperature' );
// the above returns: Error( 'Network error' ) temperatureStore ).getResolutionState( 'getTemperature' );
// the above returns: { "state": "error", "error": Error( 'Network error' ) }

The state returned by getResolutionState is one of: “resolving”, “finished”, “error”, undefined. The undefined indicates that the resolver hasn’t been triggered yet.

PRs #38669 #39317

#6-0, #dev-notes, #dev-notes-6-0