# Query Loop et pagination côté client avec l’Interactivity API

> Depuis la version 6.5, la Query Loop peut paginer sans rechargement complet de page grâce à l'Interactivity API native. Configuration pas à pas, sans bloc personnalisé.

- Auteur : Clément Hadrot
- Publié le : 2024-11-13
- Mis à jour le : 2024-11-13
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/query-loop-pagination-interactivity-api/

## L’essentiel

- L'option native évite d'écrire du JavaScript pour ce besoin précis
- Le rendu reste côté serveur, seul le remplacement DOM change
- Un fallback sans JavaScript reste garanti par défaut

Un client dans l'édition de contenus m'a demandé, courant novembre, une pagination « qui ne recharge pas toute la page » pour son annuaire d'articles en Query Loop, un peu à la manière d'une application à page unique. Ma première réaction a été de penser à un développement de bloc personnalisé avec du `fetch` et un rendu React côté client. Ce n'était pourtant plus nécessaire depuis la version 6.5, sortie en avril, qui a intégré l'Interactivity API directement dans la Query Loop native.

Voici la configuration complète, sans une ligne de JavaScript à écrire, pour obtenir une pagination fluide côté client sur un bloc Query Loop standard.

## Activer le mode interactif de la Query Loop

Le bloc Query Loop dispose depuis la 6.5 d'un réglage `Activer les mises à jour côté client`, disponible dans le panneau d'inspection latéral lorsque l'on sélectionne le bloc racine Query Loop dans l'éditeur. Ce réglage correspond en réalité à l'attribut `enhancedPagination` stocké dans les métadonnées du bloc.

```
<!-- wp:query {"queryId":1,"query":{"perPage":6,"postType":"post"},"enhancedPagination":true} -->
<div class="wp-block-query">
  <!-- wp:post-template -->
    <!-- wp:post-title /-->
    <!-- wp:post-excerpt /-->
  <!-- /wp:post-template -->
  <!-- wp:query-pagination -->
    <!-- wp:query-pagination-previous /-->
    <!-- wp:query-pagination-numbers /-->
    <!-- wp:query-pagination-next /-->
  <!-- /wp:query-pagination -->
</div>
<!-- /wp:query -->
```

## Ce qui se passe réellement sous le capot

> L'essentiel à retenir : L'option native évite d'écrire du JavaScript pour ce besoin précis ; Le rendu reste côté serveur, seul le remplacement DOM change ; Un fallback sans JavaScript reste garanti par défaut

Contrairement à une intuition répandue, l'Interactivity API ne transforme pas la Query Loop en composant JavaScript rendu côté client. Le contenu reste entièrement généré côté serveur, en PHP, exactement comme sans l'option activée. Ce qui change, c'est le mécanisme de navigation : au clic sur un lien de pagination, WordPress intercepte l'événement, effectue une requête vers l'URL cible, récupère le HTML rendu côté serveur pour cette page, et remplace uniquement la portion de DOM concernée, sans recharger l'en-tête ni le pied de page.

Cette approche présente un avantage rarement mis en avant : le contenu reste indexable normalement par les moteurs de recherche, puisque chaque page de pagination possède toujours sa propre URL fonctionnelle et son propre rendu serveur complet, accessible même sans JavaScript activé dans le navigateur.

## Le fallback sans JavaScript, garanti par défaut

Un point que j'ai vérifié avant de livrer ce réglage au client : en désactivant JavaScript dans les outils de développement du navigateur, la pagination continue de fonctionner normalement, en rechargement de page classique. L'Interactivity API se contente d'améliorer l'expérience quand JavaScript est disponible, sans jamais la conditionner strictement.

### Ajuster le comportement du défilement

Par défaut, la page remonte automatiquement en haut du conteneur de la Query Loop après un changement de page, pour éviter que l'utilisateur reste visuellement bloqué en bas d'une liste vide de nouveau contenu visible à l'écran. Ce comportement, géré automatiquement par le module `@wordpress/interactivity` chargé nativement, ne nécessite aucune configuration supplémentaire côté thème.

## Étendre le comportement pour un besoin spécifique

Sur ce projet, le client souhaitait en plus un léger effet de fondu lors du changement de page. Comme l'Interactivity API repose sur des directives déclaratives (`data-wp-*`) plutôt que sur un script impératif classique, l'ajout s'est fait par une simple règle CSS ciblant la classe appliquée automatiquement pendant la transition :

```
.wp-block-post-template[data-wp-interactive] {
    transition: opacity 0.2s ease;
}
.wp-block-post-template.is-transitioning {
    opacity: 0;
}
```

Cette règle s'appuie sur la classe `is-transitioning`, ajoutée automatiquement par le cœur pendant le remplacement du DOM, ce qui a évité tout développement JavaScript supplémentaire pour ce simple effet visuel.

- Aucune dépendance JavaScript externe à charger : le module fait partie du cœur WordPress depuis la 6.5.
- Compatible avec les filtres de la Query Loop existants, y compris les filtres personnalisés ajoutés côté PHP.
- Le SEO reste inchangé : chaque page de pagination conserve son URL et son contenu indexable normalement.

> Avant d'écrire du JavaScript pour une interaction, vérifiez toujours si l'Interactivity API ne couvre pas déjà le besoin nativement depuis la 6.5 : c'est de plus en plus souvent le cas pour des interactions courantes comme la pagination ou les filtres.

## En résumé

La pagination côté client d'une Query Loop ne nécessite plus aucun développement personnalisé depuis WordPress 6.5 : une simple case à cocher dans l'inspecteur de blocs suffit, avec un rendu qui reste entièrement côté serveur et un fallback sans JavaScript garanti. C'est un des apports les plus concrets de l'Interactivity API pour un usage quotidien en agence.