Gutenberg: Reset core resolvers on site change

[Copons]

Changes proposed in this Pull Request

• Reset Gutenberg's core resolvers on site change in order to avoid accidentally sending REST request to the previously selected site.

To manage to do this, I've introduced:

• A new gutenberg/calypso store (name can be changed: I don't have any preferences compared to calypso/gutenberg, and even simply calypso) with a single selectedSiteId attribute.
  It keeps track of the most recent selected site ID on the last Gutenberg editor load.
  This is needed so that, when we open Gutenberg again, we can check if meanwhile we changed the site.

• A more granular way of resetting single Gutenberg stores.
  Before: registry.reset() knew by itself which stores to reset.
  After: registry.reset( 'core/foobar' ), the store name needs to be provided explicitly.

• A resolver invalidation function inspired by Core Gutenberg (props to @jsnajdr) called when navigating to Gutenberg, if the selected site has changed since last time Gutenberg was loaded.

Context: #28302 (review)

Testing instructions

• Open Calypso locally and enable the Gutenberg debug: localStorage.debug = 'calypso:gutenberg' (a reload is required). Filter the console for "reset" to remove the noise.
• Navigate to Gutenberg at /block-editor.
• Make sure core/editor and core/notices are reset:

> calypso:gutenberg Resetting core/editor store
> calypso:gutenberg Resetting core/notices store

• Navigate back to the posts list and change site.
• Navigate back to Gutenberg.
• Make sure core/editor, core/notices, and the core resolvers are reset:

> calypso:gutenberg Resetting core/editor store
> calypso:gutenberg Resetting core/notices store
> calypso:gutenberg Resetting core store resolvers: getPostType,hasUploadPermissions

• Navigate back to the posts list and, this time without changing site, open Gutenberg again.
• Make sure only core/editor and core/notices are reset.

Regression check 1:

• Create a post with Gutenberg and publish it.
• Keep on screen the publish sidebar and the success notice, and press ^+⌥+H to open the keyboard shortcuts modal.
• Navigate back to the posts list with the browser's back arrow.
• Open another Gutenberg.
• Make sure that the publish sidebar is closed, and the success notice and the modal are hidden.

Regression check 2:

• With the Gutenberg debug still enabled, filter the console for sending api.
• Update a post with Gutenberg.
• Make sure all the console logs report the currently selected site:

calypso:gutenberg Sending API request to: /wp/v2/sites/first-site.wordpress.com/posts/123

• Navigate back to the posts list and change site.
• Clear the console.
• Update a post with Gutenberg on the new site.
• Make sure all the console logs report the currently selected site:

calypso:gutenberg Sending API request to: /wp/v2/sites/second-site.wordpress.com/posts/456

Fixes #29369

[matticbot]

Test live: https://calypso.live/?branch=update/29369-gutenberg-reset-core-data-on-site-switch

[Copons]

@aduth @jsnajdr
This part here that extends all the stores with a reset method, is not applied to core/data (aka the store in the data package) as well.
It's easily testable by adding a console.log( namespace ) here, and observe that it "traverses" all expected stores, except core/data.
I'm not sure why, and I always get lost in the logic behind the Gutenberg data module.

In other words, this function here allows me to reset core (aka the store in the core-data package) but not core/data.

[jsnajdr]

The reason why the core/data ignores the call to reset() is that it's created and registered very early as part of the createRegistry function.

At that time, the registerStore function is not yet extended with the use( addResetToRegistry ) plugin and the registered reducer is not wrapped with the HoR that reacts to the GUTENLYPSO_RESET action.

I don't think that being able to fully reset the core/data store is even wanted. The core/data store is a bit special: it maintains the resolution flag for all other stores' selectors. We only ever want to reset the resolution flags for one store at a time, not for all of them.

Fortunately, some support for resetting core/data state was added in WordPress/gutenberg#10089 and we can use it for our purposes. Inspired by the resolvers cache middleware, we can implement a function that resets all resolution state for one store:

function resetStoreResolutions( registry, reducerKey ) {
  const resolvers = registry.select( 'core/data' ).getCachedResolvers( reducerKey );
  Object.entries( resolvers ).forEach( ( [ selectorName, resolversByArgs ] ) => {
    resolversByArgs.forEach( ( _, args ) => {
      registry.dispatch( 'core/data' ).invalidateResolution( reducerKey, selectorName, args );
    } );
  } );
}

Then we can add a call to this new function to the reset function:

reset() {
  resettableStores.forEach( reducerKey => {
    registry.stores[ reducerKey ].dispatch( { type: 'GUTENLYPSO_RESET' } );
    resetStoreResolutions( registry, reducerKey );
  } );
}

This should reset everything on site change. There is just one race condition bug that remains: if a request for entities from site ID=1 is in flight, and we switch to site ID=2, then the response from site ID=2 will be received into store with site ID=2!

The cache invalidation code in WordPress/gutenberg#10089 probably has a similar bug: it won't invalidate resolution for selector whose request is in flight. There can be "get a list" and "add to list" requests happening at the same time, and if their "issue request from client", "perform request on server" and "receive response on client" are performed in a certain order, the resulting state will miss the just-added entity.

[aduth]

Created an issue for tracking at WordPress/gutenberg#12984

[mmtr]

This tests well for me. Good work @Copons!

The code also looks good to me, but I'd prefer if someone else can confirm it since I'm not feeling confidence enough yet with the data layer (especially with the complexity we're handling here) and I might miss something :)

[vindl]

Tests well for me!

[vindl]

Neat. :)