Provide an API for refreshing data fetched by apiFetch

[danielbachhuber]

There are some components that use apiFetch() to fetch REST API data:

• packages/editor/src/components/post-taxonomies/flat-term-selector.js https://github.com/WordPress/gutenberg/blob/95f064039165c881e0f9e2821027a7fca1de2847/packages/editor/src/components/post-taxonomies/flat-term-selector.js#L79-L81
• packages/editor/src/components/post-taxonomies/hierarchical-term-selector.js https://github.com/WordPress/gutenberg/blob/3caec34c7bf7730427855c2b50f780ff07e87924/packages/editor/src/components/post-taxonomies/hierarchical-term-selector.js#L115-L122

These can't be updated to use the data storage layer until #11643 is addressed. In the interim, we should provide an API for refreshing this data to address needs like #7565

[chrisvanpatten]

See also #7549, which I think is potentially the same fundamental issue?

[youknowriad]

I'd suggest building a separate component in a separate sidebar or something like that instead of trying to hook into the default component. I don't think refreshing the data is the real use-case, the real use case is having a completely different behavior for this panel which can be addressed by providing different props but I think it's suboptimal.

[danielbachhuber]

I'd suggest building a separate component in a separate sidebar or something like that instead of trying to hook into the default component.

@youknowriad Is it possible to then de-register the default component?

[youknowriad]

It's possible to hide it

[danielbachhuber]

Huh. That's probably a sub-optimal user experience but could suffice for the immediate need.

@Chouby While a bit more work and moderately annoying, would this work for your needs?

1. Hide the original component.
2. Recreate the components that need to be editable in a plugin sidebar?

[youknowriad]

https://wordpress.org/gutenberg/handbook/data/data-core-edit-post/#toggleeditorpanelenabled

[danielbachhuber]

Those docs need a bit of work :)

[youknowriad]

Agreed it's suboptimal if you compare one by one regarding what was possible in the classic editor.

But we're not trying to mirror what was possible. We're adding more and more extensibility APIs but we want to keep these APIs semantically correct as it's easier to ensure forward compatibility this way, while specific UI element extensibility is likely to break often.

For example, Gutenberg could decide to move this panel elsewhere at some point, to the pre-publish panel or something else (just an example), if the API you used is to update this panel specifically, or if we change the prop name for this panel, it will break.

This is a valid use-case though and we'd like to see if the current approach is good enough before we come up with new APIs.

[danielbachhuber]

We're adding more and more extensibility APIs but we want to keep these APIs semantically correct as it's easier to ensure forward compatibility this way, while specific UI element extensibility is likely to break often.

Sure, totally reasonable. For the goal of getting to feature-parity in 5.0, I think the "less than ideal" implementation would suffice.

[Chouby]

I'd suggest building a separate component in a separate sidebar or something like that instead of trying to hook into the default component.

Thank you for the proposal. But I don't believe that we can go this way. Indeed:

1. From the user perspective this is not understandable. I imagine the tens of support requests such as "Polylang removes the taxonomies panels" ;-)
2. If two plugins need to customize the behavior of a panel and each create their own panel, I suspect that this messes everything. I know that the WP 4.9.8 category metabox is at least customized by Yoast SEO and multilingual plugins. So this is not an hypothetic situation.

Moreover, the current situation, although far from ideal, is better. The languages panel being in a plugin sidebar, we select the language when the document sidebar is hidden. Showing the document sidebar again refreshes it and refreshes the taxonomy panel which triggers a new REST request to display the terms in the correct language.

So we have a working solution to refresh the taxonomies panel. However our main issue it that this doesn't work for the page attributes panel (for page parents), as it looks like refreshing this panel doesn't trigger a new REST resquest. See https://github.com/WordPress/gutenberg/issues/7565.

For me this issue is valid anyway. As the from a UX perspective, Gutenberg should accept to add new panels to the existing document sidebar and not oblige all plugins to create their own sidebar (I suppose that there is already an opened issue for that but I could not find it), and in that case, it will be useful to refresh a panel without refreshing the complete sidebar.

[manooweb]

https://wordpress.org/gutenberg/handbook/data/data-core-edit-post/#toggleeditorpanelenabled

I tried to make this working a few months ago but I never succeeded to do it from another component - our legacy metabox. This is why I opened some issues you linked #7565 and #7549 and we also decided to start to develop our metabox in React technologies. But the gap is very big and often requires us to dive deeper in Gutenberg code to explore for understanding how we can do for lack of a sufficiently rich technical documentation.

Maybe, it just misses a action to dispatch to the categories / tags / "page attributes" panels ?? for making it easier or a more precise example of code ?

[aduth]

I'd suggest an action item here: If HierarchicalTermSelector and FlatTermSelector components are updated to consume data using core data, a "refresh" can occur by simply invalidating resolution for those resolved selectors.

Edit: I suppose this is what was suggested at #13849 . It's not entirely clear to me that the challenges presented in closing that issue are insurmountable.

[manooweb]

@aduth as I said after #7549 was closed the difficulty for external developer is to find the correct parameters we have to passed to invalidateResolution and maintain it in the future. IMHO if gutenberg components would be able to expose a method to invalidating resolution of their own datas that we can call at the right moment, it will be very helpful for us.

[aduth]

Okay, that reads to me as a different task than what's titled in the issue, however. It may be worthy of its own issue. That said, whether a specific component consumes resolved data seems like an implementation detail, or at least I'd have some hesitations in committing to it as part of a maintained public interface. There may be some rare exceptions as in the taxonomies components.

[manooweb]

To be clear in our case we had to invalidate resolution for the parent page attribute in the page attributes panel because we have to filter its results by language setted for the post. For taxonomies and tags, it was solved by itself because render these panels fetch each time the request and that our next metabox is developed in its own plugin sidebar. So, when you reopen document sidebar taxonomies and tags panels are rendered again and then refreshed. For our old metabox integrated automatically by Gutenberg, that can't work because the metabox is in the same document sidebar.

But in the future this behaviour might change and it would be fine if we will be able to do the same thing like the parent page attribute.

It was one of the reasons why we decided to redevelop completly our metabox with the Gutenberg technologies to be more close of our features before WP 5.0

[Mamaduka]

Should we close this issue since #11643 got resolved?

• The HierarchicalTermSelector component was refactored to use core data - #33418.
• and FlatTermSelector refactoring is in progress - #33459.

[Mamaduka]

The entity selector resolution can be invalidated using the invalidateResolution meta action.

Considering that apiFetch is a small wrapper around fetch(), I don't think we should provide caching or invalidation support.

The component that might require manual refresh should use core data selectors.

Here's an example for the Tags panel:

function invalidateTagsResotuion() {
    const termIds = wp.data.select('core/editor').getEditedPostAttribute('tags');
    const query = {
        include: termIds.join( ',' ),
        per_page: -1,
        orderby: 'count',
        order: 'desc',
        context: 'view',
        _fields: 'id,name',
    }

    wp.data.dispatch('core').invalidateResolution( 'getEntityRecords', [
        'taxonomy',
        'post_tag',
        query,
    ] );
}