DataViews: Enhance filterSortAndPaginate function by allowing args for pagination items

[Mayank-Tripathi32]

Explore #70040

What?

Adds ability to pass totalItems & totalPages to filterSortAndPaginate to allow for hybrid approach for filtering and pagination.

Why?

When using the filterSortAndPaginate() function with paginated data from an API (where per_page=view.perPage), the function incorrectly calculates totalItems and totalPages based only on the records in the current page, not the total number of records in the database.

This causes pagination to break when using filterSortAndPaginate() with data from useEntityRecords() that's already paginated, as the function doesn't know about the total number of records available.

How?

This PR modifies the filterSortAndPaginate() function to accept an optional options parameter with totalItems and totalPages properties. When these values are provided, the function uses them instead of calculating pagination information from the data array.

This allows for a hybrid approach where:

• Data is paginated on the server side (using per_page=view.perPage)
• The API provides the total counts (totalItems and totalPages)
• filterSortAndPaginate() can still be used for additional client-side filtering/sorting while maintaining correct pagination information
• The implementation maintains backward compatibility with existing code while adding the flexibility needed to handle paginated data correctly.

Testing Instructions

• Create a component that uses useEntityRecords() with pagination (setting per_page=view.perPage)
• Use filterSortAndPaginate() with the records from the API
• Pass totalItems and totalPages from useEntityRecords() to filterSortAndPaginate()
• Verify that pagination works correctly, showing the correct total number of items and pages

Testing Instructions for Keyboard

No keyboard-specific testing is required as this change doesn't affect the user interface or keyboard navigation.

Screenshots or screencast

Not applicable as this is a functional change to an internal utility function with no direct UI impact.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin.
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Mayank-Tripathi32 <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.