taxonomy data in core store doesn't get invalidated when new terms get added

[NicestRudeGuy]

Is there an existing issue for this?

• I have searched the existing issues

Have you tried deactivating all plugins except Gutenberg?

• I have tested with all plugins deactivated.

Have you tried replicating the bug using a default theme e.g. Twenty Twenty?

• I have tested with a default theme.

Description

I ran

wp.data.select("core").getEntityRecords("taxonomy", "category")

in console so i get the current categories in array which is fine . but when i add another category inside the editor it gets added in the backend and also in the category drop down but it doesn't update the wp.data redux store automatically a refresh is required.

I also tried useSelect and subscribe in the code but got the same result as the wp.data store isn't updated

Step-by-step reproduction instructions

1. Make a new page/post
2. open devtools and run wp.data.select("core").getEntityRecords("taxonomy", "category")
3. See the resultant array length
4. Add another category inside the editor
5. then run wp.data.select("core").getEntityRecords("taxonomy", "category") again ull see the new category isnt added to the store even if you hit update button.

Expected Behavior

Data with the newer categories added in wp.data redux store

Current Behavior

Refresh is required to get the new categories ( make need to add subscribe in the store for the changes )

Screenshots or screen recording (optional)

Video link showing this thing in action
https://www.loom.com/share/6497bce28d914e73aa6197f25dea96df

Code snippet (optional)

wp.data.select("core").getEntityRecords("taxonomy", "category")

WordPress Information

WP 5.8

Gutenberg Information

Haven't installed the gutenberg plugin just a clean WP site.

What browsers are you seeing the problem on?

No response

Device Information

Desktop

Operating System Information

Tested on Ubuntu LTS 20.4

[talldan]

Thanks for reporting. I don't think this is a bug, but how the system works. A page refresh isn't required.

What's happening is that when creating a new category, the entity cache is invalidated. Because of that, when using wp.data.select("core").getEntityRecords("taxonomy", "category") an HTTP request is made in the background to fetch the terms (check the network tab to see this happen).

Once that completes the store is updated and calling wp.data.select("core").getEntityRecords("taxonomy", "category") again will show the updated record. Some selectors, like getEntityRecords are tied to resolvers that handle the HTTP request. It's possible to check if an HTTP request is in flight by using the isResolving selector, e.g. wp.data.select("core").isResolving("taxonomy", "category"). That might be used to show a loading spinner or similar.

[NicestRudeGuy]

@talldan it never gets resolved automatically , I ran setInterval(() => console.log(wp.data.select("core").isResolving("taxonomy", "category")) , 2000); to see if it will ever get resolved but it never did i still see the older store

[fabiankaegy]

@talldan I am reopening this issue since I can also replicate that the store never seems to get invalidated.

I tested this via a useSelect hook which should subscribe to any changes in the store:

import { useSelect } from '@wordpress/data';
import { store as coreStore } from '@wordpress/core-data';

const terms = useSelect( (select) => {
    return select(coreStore).getEntityRecords( 'taxonomy', 'category' );
} ):

Expected result

After adding new categories at some point the newly added category should show up here.

Actual result

The new category never shows up. Even with manually trying to select the categories via the browser console.

[fabiankaegy]

It appears that new teams get created here:

gutenberg/packages/editor/src/components/post-taxonomies/flat-term-selector.js

Lines 58 to 74 in 8c68626

	return apiFetch( {
	path: `/${ namespace }/${ restBase }`,
	method: 'POST',
	data: { name: escapedTermName },
	} )
	.catch( ( error ) => {
	if ( error.code !== 'term_exists' ) {
	return Promise.reject( error );
	}
	return Promise.resolve( {
	id: error.data.term_id,
	name: termName,
	} );
	} )
	.then( unescapeTerm );
	}

via an apiFetch call. Unless I'm missing something this is the cause for the error here because the straigup up apiFetch POST request doesn't invalidate the store. The store is unaware of this change in data and therefore doesn't fetch new terms.

[fabiankaegy]

I believe this is pretty much what @Mamaduka mentioned here: #11700 (comment) and similarly here: #47746

I tried manually calling the invalidateResolution dispatcher and it worked.

wp.data.dispatch('core').invalidateResolution('getEntityRecords', [ 'taxonomy', 'category' ]);

CleanShot.2023-02-23.at.12.06.13.mp4

[fabiankaegy]

@Mamaduka can you share an example of how one would invalidate an entire suite of selectors simultaneously?

The issue I am currently running into when trying to solve this, is that when I invalidate invalidateResolution('getEntityRecords', ['taxonomy', taxonomyName]); but someone used invalidateResolution('getEntityRecords', ['taxonomy', taxonomyName. { per_page: 20 }]); the second one doesn't get invalidated.

Ideally, I would want to invalidate all responses for that particular taxonomy 🤔

[Mamaduka]

@fabiankaegy, I don't believe it's currently possible to do that. There's the invalidateResolutionForStoreSelector, but it will invalidate every getEntityRecords cache.

I think we need to update the FlatTermSelector component and fully move await from direct apiFetch calls.

[Mamaduka]

This was resolved in #50952.