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.

• Required label: Any label starting with [Type].
• Labels found: [Package] Block library.

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.

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.

• Required label: Any label starting with [Type].
• 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.

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: jillro <jillro@git.wordpress.org>
Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>

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

I haven't looked at the code deeply here. But can we not achieve this by refactoring the existing jerky pagination blocks rather than creating full duplicates of it?

@fabiankaegy I considered this option, but went with a separate block, because most of the code of both blocks are branch conditions on the query, and there is little in common between a post query and a term query.

For example, query-pagination has to handle the global $wp_query; case, which is not necessary for Terms Query which is always provided by context. On the other hand, WP_Query handles part of the pagination logic (calculating max page, for example) which WP_Term_Query does not provides, so the pagination block has to do it itself.

If the display logic of numbers and previous / next is common, it seems to me it is only a very small part of the code, and I'm not sure if it would be worth the complexity of factorizing it.