Search Rendering & Filters Overview

Ce document résume les fichiers concernés par le rendu SSR/CSR de la recherche et la gestion des filtres.

Fichiers côté serveur

• apps/odalys-v4/lib/search/buildSearchRequest.ts

  • Parse searchParams, reconstruit les FacetLike issus de l'URL et prépare la matrice de filtres attendue par FetchHitsEstablishments.
  • Retourne également les facettes (searchRequest.facets) pour que l’UI puisse afficher les tags sélectionnés.

• apps/odalys-v4/lib/search/remapFacetLabels.ts

  • Construit un mapping facetName:valueId → facetName:libellé à partir de holidayHits.filters.
  • remapSearchFiltersMatrix convertit la matrice envoyée au client ([["services.fr:77"], …]) en version déjà labelisée ([["services.fr:Wifi"], …]).
  • remapFacetLikeArray applique le même mapping sur les FacetLike (utilisé pour les tags/facettes côté UI).

• apps/odalys-v4/lib/search/searchFilters.ts

  • buildFiltersFromUrl convertit les paramètres d’URL en FacetLike (promotion, services, range, etc.).
  • buildFacetFiltersMatrix convertit ces facettes en matrice de filtres Algolia ([["facet:value"], …]).
  • syncFiltersToSearchParams réécrit l’URL lors des interactions.

Fichiers côté client / hydratation

• apps/odalys-v4/atoms/search/searchFiltersAtom.tsx

  • Stocke les filtres sélectionnés dans l’application (Jotai) et gère les redirections spécifiques (vacation types, promotions…).
  • HydrateSearchFiltersFromUrlAtom remappe les valeurs URL avec les valueIds existants pour éviter les divergences SSR/CSR.

• apps/odalys-v4/components/Search/SearchFiltersInitialiser.tsx

  • Pré-charge l’atom Jotai avec les facettes remappées livrées par le SSR, puis indique que l’état est hydraté (searchFiltersHydratedFromSSRAtom).

• apps/odalys-v4/components/Search/SearchPlace.tsx

  • Vue client pour les pages lieu (région/pays/station). Réutilise initialResults et ne relance FetchHitsEstablishments que lorsque les filtres changent réellement.

• apps/odalys-v4/app/[locale]/search/SearchPageClient.tsx

  • Équivalent pour la page /search : même logique client, sans filtres « fixes » supplémentaires.

• apps/odalys-v4/app/[locale]/thematicPage/[slug]/SearchThematicClient.tsx

  • Variante thématique. Ajoute systématiquement les filtres métier (roomIds) aux facettes utilisateur avant de comparer/exécuter la requête Apollo.

• apps/odalys-v4/components/SearchBar/SearchBar.tsx

  • Déclenche la recherche Algolia (auto-suggestions, dates). Sa logique est désormais neutre vis-à-vis du SSR grâce au remapping et aux garde-fous.

Workflow (exemple : /location-montagne/haute-savoie?search=Haute+Savoie&datedebut=2025-10-11&duree=7&nbpax=2&services=77,83&range=611)

1. SSR

   • buildSearchRequest parse l’URL et génère la matrice de filtres.
   • FetchHitsEstablishments récupère les hits, filtrés par filterEstablishmentsWithStock.
   • remapSearchFiltersMatrix remplace 77,83,611 par leurs libellés (Wifi, PMR, Prestige).
   • Le HTML initial contient déjà la liste et les tags sélectionnés.

2. Hydratation

   • SearchFiltersInitialiser injecte ces facettes dans Jotai.
   • HydrateSearchFiltersFromUrlAtom recalcule l’état depuis l’URL, remappe les valeurs et constate qu’il n’y a rien de nouveau : aucun refetch.

3. Interactions

   • Lorsqu’un filtre change (ex: bouton “Réinitialiser”), Jotai met à jour l’état.
   • Les composants clients (lieu/général/thématique) comparent une clé normalisée et ne relancent Apollo que lorsqu’il y a une divergence effective.

Ainsi, à l’arrivée (avec ou sans filtres dans l’URL), il n’y a qu’une requête SSR. Les requêtes supplémentaires n’apparaissent qu’en réponse aux actions utilisateur (ajout/suppression de filtres, changement de dates, etc.).