Core data: harmonize getRevision selector and resolver function signatures #56416
Conversation
This file contains 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
ramonjd
added
[Type] Bug
7 tasks
|
Size Change: +49 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Thanks for following up here! This appears to resolve the issue of calling getRevision resulting in an unnecessary API request if we already previously fetched the data as part of getRevisions 👍
An issue I ran into while testing, though, is that if I call getRevision to grab an individual global styles revision (prior to calling getRevisions), then the API call is still to fetch all revisions, rather than an individual one. I think the culprit might be that the following getRevisionsUrl signature doesn't support passing in a revisionId?
gutenberg/packages/core-data/src/entities.js
Line 214 in 8eb63dd
Example call:
wp.data.select( 'core' ).getRevision( 'root', 'globalStyles', 4169, 4180 );
This winds up calling to get all revisions for 4169:
Updating the getRevisionsUrl method to match what's used for postType seems to do the trick for me:
getRevisionsUrl: ( parentId, revisionId ) =>
`/wp/v2/global-styles/${ parentId }/revisions${
revisionId ? '/' + revisionId : ''
}`,
Does that sound okay to you, or is the root globalStyles entity meant to behave differently to postType?
Apologies if I'm barking up the wrong tree!
Ah yes!! Thanks for raising that. This change predates the following, recent update: Now that we support revision URLs I think we're safe to copy it over as you say.
You are too nice. This was a gross omission and deserves a proper flailing by the internet! 🤣 |
…r memoization since the function signatures are different.
…that any subsequent calls to `getRevision` for revisions that we've already fetched via `getRevisions()` are marked as resolved and therefore do not trigger the resolver (and therefore an API call).
Now that #55827 has landed we can start supporting individual global styles URLs as well.
ramonjd
force-pushed
the
fix/core-data-revisions-store-overload
branch
from
bf78d96 to
2bb2a99
Compare
andrewserong
approved these changes
Nov 23, 2023
There was a problem hiding this comment.
This is testing great for me now, @ramonjd, thanks!
For a moment I was worried that the per_page query param wasn't working for post revisions as I kept getting a response of only 10 revisions — then I double checked the post I was working on, and it happened to have only 10 revisions 🤦 😄
✅ getRevisions calls for posts and global styles works as on trunk
✅ getRevision calls for single post or single global style revisions will return the result from the resolved cache if found
✅ Using other query params still results in a fresh API call (the first time the fresh query params are used, with existing query params correctly matching a resolved response)
LGTM! ✨
Ha! Thanks a lot for testing so thoroughly. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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?
Follow up for:
Yo!
This amazing PR:
{}ongetRevision(). It messes up selector memoization since the function signatures are different.getRevisions(), the same waygetEntityRecordsdoes it.Why?
getRevisions()thengetRevision()doesn't return cached store item and replaces current items state.getRevisionfor revisions that we've already fetched viagetRevisions()are marked as resolved and therefore do not trigger the resolver (and therefore an API call).Testing Instructions
Check that the state survives multiple requests and that cached results are returned.
For example
Before
After