Query loop: the 'Max page to show' setting doesn't preview in the editor

[afercia]

Description

Discovered while working on https://github.com/WordPress/gutenberg/pull/63020

The editor is supposed to provide a preview of the blocks (the entire page, I would say) that is as close as possible to the page on the front end. However, it appears the Query loop 'Max page to show' setting doesn't provide any preview in the editor. It just stays in its default view.

Not sure but this may happen because the Paginaion is actually a separate block. Regardless, as a user I'd be pretty disoriented by not seeing any change in the editor preview and think there's something not working as expected.

Step-by-step reproduction instructions

• Create a new post.
• Add a Query loop block > Start blank > Title & date.
• The editor will fetch some post titles and dates and will display them in the editor UI. Screenshot:

• Observe the Pagination link show Previous, all the pages link (with an ellipsis if there's a lot of pages) and the Next links.
• In the block toolbar, click 'Display settings'.
• Note: in https://github.com/WordPress/gutenberg/pull/63020 these settings will be moved to the Inspector panel.
• Change Items per page and observe the editor does update the preview accordingly.
• Change Offset and observe the editor does update the preview accordingly.
• Change 'Max page to show' to, for example, 2 and observe the editor does not update the preview. Screenshot:

• Save and go to the front end. Observe the pagination actually shows only two pagination links. Screenshot:

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[ankur0007]

Hi Mate, I am looking into this and let you know if I can fix it :)

[ankur0007]

Hi,

I've reviewed it, and here are my thoughts:

1. When clicking on pagination numbers, there's a setting in a separate block called "Number Of Links." This setting determines how many numbers will appear before and after the current pagination number. But this is not a solution.

2. To dynamically change the pagination number, we must fetch the count of posts from the selected post type when initializing the query loop block. Depending on the parameters selected—like Items per page, Offset, and Max pages to show—we'll dynamically generate the appropriate number of pagination links and replace them with the current ones.

Regarding 2, do you think implementing this will result in additional fetch requests to get the post count?

Regards, A. V.

[afercia]

do you think implementing this will result in additional fetch requests to get the post count?

It's a reasonable concern but this already happens when changing the 'Items per page' and 'Offset' values. At each change, posts are fetched including all the posts content, which may be potentially huge. As far as I see, the responses are cached so that subsequent requests with the same values won't trigger a new fetch.

On the other hand, triggering a new request at any React onChange event doesn't seem to be ideal. Especially when changing the values by using the number input arrows button or by using the keyboard. Say I want to change 'Items per page' form 10 to 20. That would trigger 10 requests each time the value changes. It's an UI / interaction issue. This kind of UIs that trigger requests should be implemented by 'debouncing' the request. WordPress Core does that in a few places:

• While the user is changing the valaues, debounce the request with a reasonable value. Generally core uses 500ms, I think.
• Trigger the request only after the user stops changing the value, after 500ms.

Debouncing should be a standard in these cases. Cc @youknowriad any thoughts? I guess it's worth creating a new issue.