# Elementor V4 et Algolia : brancher une recherche instantanée native

> Adapter un widget de recherche Algolia InstantSearch à l'architecture des composants de l'éditeur V4, après l'échec du widget hérité de la V3.

- Auteur : Clément Hadrot
- Publié le : 2025-07-21
- Mis à jour le : 2025-07-21
- Catégorie : Elementor
- URL : https://wpmoderne.dev.wordpress-developpement.fr/elementor/elementor-v4-algolia-recherche-instantanee/

## L’essentiel

- Le widget de recherche V3 ne s'affiche plus correctement dans le rendu atomique
- Un composant V4 personnalisé peut monter directement une instance InstantSearch.js
- La synchronisation des styles passe désormais par les variables globales V4

Comment brancher une recherche instantanée sur un site dont l'éditeur vient de passer en accès bêta à l'architecture atomique, sans perdre les résultats en temps réel qui faisaient la valeur du widget existant ? C'est la question posée en tout début de migration d'un widget de recherche Algolia vers l'éditeur V4 d'Elementor.

Le widget de recherche construit en V3 s'appuyait sur une intégration directe de la bibliothèque InstantSearch.js dans un widget personnalisé classique. Sous l'architecture atomique testée en V4, ce widget continuait techniquement de fonctionner, mais son rendu visuel se cassait : les classes CSS générées par InstantSearch entraient en conflit avec le nouveau système de classes globales de la V4. Ce billet documente la reconstruction du composant, sans revenir sur la configuration de l'index Algolia côté back-office ni sur les questions de facturation liées au volume de requêtes.

## Pourquoi l'ancien widget cassait sous l'architecture atomique

InstantSearch.js génère son propre balisage HTML avec des classes CSS préfixées `ais-`, pensées pour être stylées indépendamment de tout autre système. Le système de classes globales de la V4, qui applique automatiquement certains styles hérités aux éléments enfants d'un composant, entrait en collision avec ces classes générées dynamiquement, provoquant un affichage incohérent des filtres et des résultats.

La solution retenue consiste à isoler complètement le rendu d'InstantSearch dans un conteneur dédié, exclu du système de classes globales, plutôt que de tenter un compromis de style entre les deux systèmes.

## Construire le composant V4 personnalisé

> L'essentiel à retenir : Le widget de recherche V3 ne s'affiche plus correctement dans le rendu atomique ; Un composant V4 personnalisé peut monter directement une instance InstantSearch.js ; La synchronisation des styles passe désormais par les variables globales V4

Le composant s'appuie sur un conteneur vide fourni par l'éditeur V4, dans lequel InstantSearch.js prend le contrôle total du rendu, sans interférence des styles hérités :

```
instantsearch({
  indexName: 'produits_wpmoderne',
  searchClient: algoliasearch('APP_ID', 'SEARCH_API_KEY'),
}).addWidgets([
  instantsearch.widgets.searchBox({
    container: '#is-searchbox',
  }),
  instantsearch.widgets.hits({
    container: '#is-hits',
    templates: {
      item: (hit) => `<a href="${hit.url}">${hit.title}</a>`,
    },
  }),
]).start();
```

Ce montage minimal, en une vingtaine de lignes, se déclenche via un composant personnalisé enregistré dans l'éditeur V4, qui injecte simplement les conteneurs `#is-searchbox` et `#is-hits` dans le DOM au bon emplacement de la page.

## Relier les couleurs InstantSearch aux variables globales V4

Pour que la recherche reste visuellement cohérente avec le reste du site sans subir les conflits de classes rencontrés précédemment, la solution a consisté à récupérer les valeurs des variables globales V4 (couleurs, typographies) via l'API CSS de l'éditeur, puis à les injecter comme variables CSS personnalisées dans le conteneur isolé d'InstantSearch :

```
.is-search-wrapper {
  --is-primary-color: var(--e-global-color-primary);
  --is-font-family: var(--e-global-typography-text);
}

.is-search-wrapper .ais-Hits-item a {
  color: var(--is-primary-color);
  font-family: var(--is-font-family);
}
```

Cette technique permet de bénéficier de la cohérence de style apportée par les variables globales V4, sans laisser le système de classes globales interférer directement avec le balisage généré par InstantSearch.

## Ce qui reste à surveiller

L'éditeur V4 étant encore en phase bêta au moment de cette migration, les noms exacts des variables CSS globales (`--e-global-color-primary` dans cet exemple) ne sont pas garantis stables d'une version à l'autre. Une vérification systématique après chaque mise à jour de l'éditeur reste nécessaire tant que cette convention de nommage n'a pas été officiellement figée par Elementor.

- Isoler le rendu d'une bibliothèque tierce plutôt que de tenter de la faire cohabiter avec le système de classes globales
- Relier les couleurs via des variables CSS personnalisées, jamais via une dépendance directe aux classes internes de l'éditeur
- Revalider ce pont de style à chaque montée de version tant que la V4 reste en bêta

> Notre règle pour intégrer une bibliothèque tierce dans l'éditeur V4 : ne jamais laisser le système de classes globales toucher au balisage généré dynamiquement par cette bibliothèque, sous peine de conflits de style difficiles à diagnostiquer.

## En résumé

La migration d'un widget de recherche Algolia vers l'éditeur V4 d'Elementor a nécessité d'abandonner l'intégration directe héritée de la V3 au profit d'un composant isolé, qui laisse InstantSearch.js gérer son propre rendu sans interférence du système de classes globales. Le lien visuel avec le reste du site se fait via des variables CSS personnalisées plutôt que par une dépendance directe aux classes internes de l'éditeur, une approche plus robuste face aux évolutions encore fréquentes de la V4 en phase bêta.