Core Data: Retrieve the pagination totals in the getEntityRecords calls #55164
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
youknowriad
added
[Package] Core data
youknowriad
requested review from
nerrad,
ajitbohra,
ryanwelcher,
juanmaguitar,
fabiankaegy and
ndiego
as code owners
youknowriad
commented
Oct 9, 2023
| @@ -97,8 +108,35 @@ export default function useEntityRecords< RecordType >( | |||
| [ kind, name, queryAsString, options.enabled ] | |||
| ); | |||
|
|
|||
There was a problem hiding this comment.
I noticed that this hook is using a special useQuerySelect. That felt a bit too magic to me, I'd have preferred as simple useSelect I think but it's not that important.
|
Size Change: +99 B (0%) Total Size: 1.65 MB
ℹ️ View Unchanged
|
ntsekouras
reviewed
Oct 9, 2023
| if ( entityConfig.supportsPagination && query.per_page !== -1 ) { | ||
| const response = await apiFetch( { path, parse: false } ); | ||
| records = Object.values( await response.json() ); | ||
| meta = { |
There was a problem hiding this comment.
Would we need error handling here, like we do inside apiFetch when we parse the response?
There was a problem hiding this comment.
Well, if we had proper error handling (like storing the error in the state and status) probably but right now, I don't think there's anything special happening even in the "parse: true" case. The error is just ignored it seems (the finally is triggered obviously).
|
Could we consider storing the full response headers in the data store and providing the convenience selectors on top of it? It would be very useful to have access to things like the |
|
Flaky tests detected in dae8f0b9bd588f6850439047581857ce7e08f8e0. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6457901116
|
ntsekouras
reviewed
Oct 9, 2023
There was a problem hiding this comment.
Impressive work and so fast Riad! 🚀
This looks good and I agree with @TimothyBJacobs that we could probably store all the headers.
|
core-data is meant to be an abstraction to retrieve data for users, not just a way to pass through REST API concepts. I'm ok adding more headers but we need to think properly about how to present them to the consumers. We already abstract "allow" headers using I'd like to take a use-case per use-case approach instead of just a pass through approach. |
youknowriad
force-pushed
the
add/add-pagination-totals-to-core-data
branch
from
dae8f0b to
6881750
Compare
ntsekouras
reviewed
Oct 10, 2023
ntsekouras
reviewed
Oct 10, 2023
ntsekouras
approved these changes
Oct 10, 2023
ramonjd
added a commit
that referenced
this pull request
Oct 11, 2023
ramonjd
added a commit
that referenced
this pull request
Oct 11, 2023
ramonjd
added a commit
that referenced
this pull request
Oct 16, 2023
This reverts commit f422d50a65a1e71e1d6a69d0a20aa806d3a5f928.
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.
Related to #55083
Follow-up to #55154
What?
This PR adds support for retrieving the total items and total pages from the response of the getEntityRecords calls. It also automatically adds these values to the
useEntityRecordsreturned object.Why?
This allows us to avoid the extra apiFetch request we're doing to fetch these headers in the page list in the site editor.
Note
I've noted a couple other places where these headers are directly consumed but I left these untouched for this PR.
Testing Instructions
1- Open the page list in the site editor
2- Play with pagination (totals should be rendered properly)