Peut-on construire une recherche instantanée sans expédier un bundle React entier au visiteur pour trois champs de résultats ? C’est la question posée par un client dont le site cataloguait plusieurs milliers de fiches produits indexées chez Algolia, avec un front-end jusque-là entièrement statique en dehors de ce composant de recherche. La proposition d’Interactivity API, discutée depuis le début de l’année sur make.wordpress.org et disponible en test via le plugin Gutenberg, offrait une piste à explorer avant même sa stabilisation en cœur de WordPress.
Un point de vigilance s’impose d’emblée : à la date de cet article, l’Interactivity API n’est pas encore intégrée au cœur de WordPress. Elle n’est utilisable qu’en installant le plugin Gutenberg en version récente, ce qui limite ce bloc à un contexte de test ou de développement tant que la fonctionnalité n’aura pas atteint une version stable de WordPress.
Le principe : des directives déclaratives plutôt qu’un rendu virtuel
L’Interactivity API repose sur des directives ajoutées directement dans le HTML rendu côté serveur, lues et interprétées par un petit moteur d’exécution client, sans passer par un DOM virtuel ni une phase de rendu React côté navigateur. Le bloc de recherche expose son état (terme recherché, liste de résultats) via un store déclaré côté serveur avec wp_interactivity_state(), et le HTML utilise des attributs comme data-wp-bind, data-wp-on et data-wp-each pour réagir aux changements de cet état.
<div
data-wp-interactive="acme/recherche-algolia"
data-wp-context='{ "terme": "", "resultats": [] }'
>
<input
type="text"
data-wp-on--input="actions.rechercher"
data-wp-bind--value="context.terme"
/>
<ul>
<template data-wp-each--produit="context.resultats">
<li data-wp-text="context.produit.nom"></li>
</template>
</ul>
</div>
Interroger Algolia directement depuis le store
Le fichier de vue du bloc, chargé via viewScript, déclare le store avec la fonction store() fournie par le module expérimental @wordpress/interactivity. L’action de recherche appelle directement l’API REST publique d’Algolia, sans passer par un point de terminaison WordPress intermédiaire, puisque la clé utilisée est une clé de recherche en lecture seule, prévue par Algolia pour un usage côté navigateur.
import { store, getContext } from '@wordpress/interactivity';
store( 'acme/recherche-algolia', {
actions: {
*rechercher( event ) {
const context = getContext();
context.terme = event.target.value;
const response = yield fetch(
`https://${ appId }-dsn.algolia.net/1/indexes/produits/query`,
{
method: 'POST',
headers: {
'X-Algolia-API-Key': searchOnlyApiKey,
'X-Algolia-Application-Id': appId,
'Content-Type': 'application/json',
},
body: JSON.stringify( { query: context.terme } ),
}
);
const data = yield response.json();
context.resultats = data.hits;
},
},
} );
Le point crucial de sécurité tient dans le choix de la clé : Algolia distingue une clé d’administration (jamais exposée côté client) d’une clé de recherche restreinte, spécifiquement conçue pour être visible dans le code source d’une page publique, avec des droits limités à l’interrogation d’un index précis. Utiliser par erreur la clé d’administration exposerait l’intégralité du tableau de bord Algolia à quiconque inspecterait le code source de la page.
Ce que ce choix évite, et ce qu’il impose
En s’appuyant sur l’Interactivity API plutôt que sur une bibliothèque de recherche instantanée classique embarquant son propre moteur de rendu JavaScript, le bloc évite de charger un bundle applicatif complet pour une fonctionnalité somme toute limitée. En contrepartie, le développement s’appuie sur une API encore marquée comme expérimentale, avec une syntaxe susceptible d’évoluer avant sa stabilisation officielle annoncée pour une future version majeure de WordPress.
- Installer et maintenir à jour le plugin Gutenberg sur l’environnement de développement, l’API n’étant pas disponible en cœur à cette date.
- Documenter clairement, dans le code du plugin, que la syntaxe des directives est susceptible de changer avant stabilisation.
- Prévoir un plan de migration une fois l’API stabilisée en cœur de WordPress, en particulier si la syntaxe des directives évolue d’ici là.
Sur une API encore expérimentale, je documente systématiquement dans le code la version du plugin Gutenberg utilisée au moment du développement : c’est la seule façon de retrouver rapidement ce qui a changé le jour où la stabilisation modifiera la syntaxe.
Pour aller plus loin
Ce bloc reste un prototype avancé plutôt qu’une solution de production au sens strict, tant que l’Interactivity API n’aura pas rejoint le cœur de WordPress dans une version stable. Il démontre néanmoins qu’une recherche instantanée réactive ne nécessite pas systématiquement d’expédier un framework complet au navigateur, une piste qui mérite d’être suivie de près à mesure que cette API se stabilisera.
