From b8229fe6619f94202f698270818a02f6e02b50ec Mon Sep 17 00:00:00 2001 From: Dave Smith Date: Thu, 29 Jun 2023 11:35:35 +0100 Subject: [PATCH] Fix fetching Nav fallback ID flushing Navigation entity cache (#52069) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Only flush the `getEntityRecords` cache if the fallback isn’t already in state * Save the edited entity record to a const and then invert it to determine whether we should invalidate the recordds --------- Co-authored-by: scruffian --- packages/core-data/src/resolvers.js | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/packages/core-data/src/resolvers.js b/packages/core-data/src/resolvers.js index 32baa691ddd82..93dcfd6ee9014 100644 --- a/packages/core-data/src/resolvers.js +++ b/packages/core-data/src/resolvers.js @@ -573,7 +573,7 @@ export const getBlockPatternCategories = export const getNavigationFallbackId = () => - async ( { dispatch } ) => { + async ( { dispatch, select } ) => { const fallback = await apiFetch( { path: addQueryArgs( '/wp-block-editor/v1/navigation-fallback', { _embed: true, @@ -585,8 +585,15 @@ export const getNavigationFallbackId = dispatch.receiveNavigationFallbackId( fallback?.id ); if ( record ) { - const invalidateNavigationQueries = true; - + // If the fallback is already in the store, don't invalidate navigation queries. + // Otherwise, invalidate the cache for the scenario where there were no Navigation + // posts in the state and the fallback created one. + const existingFallbackEntityRecord = select.getEntityRecord( + 'postType', + 'wp_navigation', + fallback?.id + ); + const invalidateNavigationQueries = ! existingFallbackEntityRecord; dispatch.receiveEntityRecords( 'postType', 'wp_navigation',