Block Bindings: Use getEntityConfig instead of getPostTypes to get available slugs#66101
Merged
SantosGuillamot merged 6 commits intotrunkfrom Oct 17, 2024
Merged
Conversation
|
Size Change: +23 B (0%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
Member
|
It's close to the WP 6.7 RC1 so I would appreciate some help from the @WordPress/gutenberg-core team. It looks like this change improves the metric that regressed with the initial implementation for getting slugs for post types. The impact of this PR: 
|
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
youknowriad
reviewed
Oct 15, 2024
packages/core-data/src/entities.js
Outdated
| baseURLParams: { context: 'edit' }, | ||
| name, | ||
| label: postType.name, | ||
| slug: postType.slug, |
Contributor
There was a problem hiding this comment.
What is this change about?
Contributor
Author
There was a problem hiding this comment.
The idea was to add the post type slug to the entity object so it is available when calling getEntitiesConfig( 'postType' ). If I am not mistaken, it can be different than the name. We are using it to get the slugs of all registered post types.
The slug information is available when calling wp/v2/types here so, the same way we are adding the label, I added the slug. Can this become a problem? Is not expected to have the post type slug in the entity config?
Contributor
There was a problem hiding this comment.
But this function returns entity configs, not post types, if this was typescript, it would have returned an error. We shouldn't try to force something to be something else, just because it's convenient.
Contributor
Author
There was a problem hiding this comment.
Mmm okay. I somehow understood it was specific to post types reading the loadPostTypeEntitities function, but I get it now. Thanks for the clarification. I'll look for an alternative way to reuse the preloaded API call.
Contributor
There was a problem hiding this comment.
I understand the type problem, but what is the problem to enriching the type with slug? Genuine question, does slug have something which would dillute the entity config type?
Contributor
There was a problem hiding this comment.
We're not enhancing all the entity types with "slug", we're enhancing only the "post types" entity types
Oh indeed, I see! Thank you! 😄
Member
There was a problem hiding this comment.
It sounds like the solution would be to create a selector and resolver pair that abstracts the following lines:
const postTypes = await apiFetch( {
path: '/wp/v2/types?context=view',
} );and use the selector in both places rather than calling getEntitiesConfig which exposes additional details.
Contributor
Author
There was a problem hiding this comment.
I've been taking a deeper look at how the Template Hierarchy works and it seems that is uses the key and not the slug: link. I've been testing locally, and it seems to be the case. That means that we can use name instead of slug. I made this commit to see if it would work.
Having said that, I'm happy to explore the option of creating a new selector and resolver if this doesn't work or you think is better.
Member
There was a problem hiding this comment.
I see it's more nuanced, as you can still provide a custom slug for some reasons:
I'm not sure what the implications are though.
Contributor
Author
There was a problem hiding this comment.
Yes, that's what I tested. But the Template Hierarchy seems to use the key. At least is what I understood from the docs and what I saw in my tests.
|
Flaky tests detected in 8af840e. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/11364715400
|
youknowriad
reviewed
Oct 16, 2024
gziolo
approved these changes
Oct 16, 2024
Member
gziolo
left a comment
There was a problem hiding this comment.
I’m approving the PR based on the outcome of discussion. @youknowriad, everything good on your side in the current shape or would you recommend further refactoring?
Contributor
|
Yep looks good to me. |
gutenbergplugin
pushed a commit
that referenced
this pull request
Oct 17, 2024
…t available slugs (#66101) * Add slug prop to postType entity config * Use `getEntitiesConfig` instead of `getPostTypes` * Only fetch postTypes in templates * Add `post.type` to `useSelect` dependencies * Use `name` instead of `slug` * Rename variable to `postTypeEntities` Co-authored-by: SantosGuillamot <santosguillamot@git.wordpress.org> Co-authored-by: youknowriad <youknowriad@git.wordpress.org> Co-authored-by: draganescu <andraganescu@git.wordpress.org> Co-authored-by: gziolo <gziolo@git.wordpress.org>
|
I just cherry-picked this PR to the wp/6.7 branch to get it included in the next release: 5645548 |
Contributor
Author
|
Thanks a lot for the feedback! These are the results of the last performance tests. As can be seen, the 
|
2 tasks
karthick-murugan
pushed a commit
to karthick-murugan/gutenberg
that referenced
this pull request
Nov 13, 2024
…t available slugs (WordPress#66101) * Add slug prop to postType entity config * Use `getEntitiesConfig` instead of `getPostTypes` * Only fetch postTypes in templates * Add `post.type` to `useSelect` dependencies * Use `name` instead of `slug` * Rename variable to `postTypeEntities` Co-authored-by: SantosGuillamot <santosguillamot@git.wordpress.org> Co-authored-by: youknowriad <youknowriad@git.wordpress.org> Co-authored-by: draganescu <andraganescu@git.wordpress.org> Co-authored-by: gziolo <gziolo@git.wordpress.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
As discussed here, this other pull request introduced a performance regression that I aim to palliate with this one.
Why?
It should improve the performance metrics.
How?
Change the logic to rely on
getEntityConfiginstead ofgetPostTypes. The information needed is already preloaded as seen here, and it can be accessed withgetEntityConfig.This way, we skip an extra API call, which can be more important the more post types registered. This is an example of a movie template:
Testing Instructions
The firstBlock performance test should show an improvement.