-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block Bindings: Use getEntityConfig
instead of getPostTypes
to get available slugs
#66101
Block Bindings: Use getEntityConfig
instead of getPostTypes
to get available slugs
#66101
Conversation
Size Change: +23 B (0%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
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. |
packages/core-data/src/entities.js
Outdated
@@ -304,6 +304,7 @@ async function loadPostTypeEntities() { | |||
baseURLParams: { context: 'edit' }, | |||
name, | |||
label: postType.name, | |||
slug: postType.slug, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this change about?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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! 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
Yep looks good to me. |
…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 |
Thanks a lot for the feedback! These are the results of the last performance tests. As can be seen, the |
…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>
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
getEntityConfig
instead 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.