Composant visuel intermediaire qui affiche un champ de recherche DSFR et filtre les données en amont avant de les redistribuer aux composants en aval.

Position dans le pipeline

Cas d'usage

• Recherche textuelle : filtrer des cartes, tableaux ou graphiques par texte libre
• Recherche + facettes : combiner recherche textuelle et filtres categoriques
• KPI dynamiques : les indicateurs se recalculent selon la recherche
• Recherche avec highlight : mettre en surbrillance les termes trouves dans les cartes

Attributs

Recherche serveur sur plusieurs colonnes (#1026)

En server-search, le gabarit search-template accepte {fields} : il devient les champs de fields séparés par |, la grammaire des champs multiples (nom|commune:contains:martin, un OU entre les champs). C'est le gabarit par défaut sur Tabular, {fields}:contains:{q}, traduit en or=(nom__contains.martin,commune__contains.martin) : le compteur lit le total serveur, juste sur tout le jeu et non sur les lignes chargées. fields est alors obligatoire. Côté serveur, contains est insensible à la casse mais sensible aux accents ; la recherche locale, elle, les ignore — on ne l'aligne pas, pour ne pas rendre deux compteurs différents selon le chemin. Un terme que l'API ne sait pas transmettre (, . ( ) " & sur Tabular) retombe sur une recherche dans le navigateur, sur les seules lignes chargées, et un avertissement le dit.

Recherche portée par le contexte (ADR-159)

Avec context="id", la recherche est confiée au dsfr-data-context, qui la diffuse à ses sources cibles, porte l'URL et le tag « Recherche : terme ». Ce n'est pas un filtre contains : un filtre est une règle exacte écrite par l'intégrateur, une recherche est ce que tape un visiteur. Le contexte porte le terme, le champ unique de fields et operator, et chaque source cible traduit la recherche selon ce que son API sait faire.

Confiée à l'API, la recherche entre dans le where de la source : une cible en server-side pagine les seules lignes trouvées, et des dsfr-data-facets server-facets voisines comptent le même ensemble. Le composant laisse alors passer les lignes de sa source sans les refiltrer, et son compteur (count) annonce le total du serveur. Calculée dans le navigateur, elle exige que la source charge le jeu : une cible en server-side, ou des server-facets voisines, passent en erreur de configuration. Le résultat n'est donc pas identique d'un fournisseur à l'autre ; c'est ce tableau qui le dit.

Source en panne

Quand la source échoue, le champ est désactivé (lecture seule, aria-disabled, toujours atteignable au clavier) sous la phrase « Filtres momentanément indisponibles. », et le compte de résultats n'est plus affiché. Le terme déjà saisi est gardé : il s'applique de nouveau au retour des données. La touche Échap efface toujours le terme. Voir Quand la source est en panne.

En attente d'un filtre

Quand l'amont porte require-where, aucune requête n'est partie : le compteur de count céderait la place à un « 0 résultat » trompeur. Il est remplacé par le texte de idle-message (« Choisissez un filtre pour afficher les données » par défaut), qui dit que rien n'a encore été demandé. Le champ de saisie, lui, reste utilisable — c'est souvent lui qui pose le premier filtre et débloque la source. Le mécanisme est décrit sur dsfr-data-source.

Exemple 1 : recherche simple + tableau

Recherche textuelle sur les champs Produit, Marque et Catégorie. Le tableau se filtre en temps réel avec un compteur de resultats.

Code

<dsfr-data-search id="searched" source="clean"
  fields="Produit, Marque, Catégorie"
  placeholder="Produit, marque ou catégorie..."
  operator="words"
  min-length="2"
  count>
</dsfr-data-search>

<dsfr-data-list source="searched"
  columns="Produit, Catégorie, Marque, Date"
  sort="Date:desc"
  pagination="10">
</dsfr-data-list>

Exemple 2 : recherche + facettes + cartes

La recherche et les facettes se combinent. La recherche reduit le jeu de données, les facettes affinent. Les cartes affichent les resultats.

Code

<dsfr-data-search id="searched" source="clean"
  fields="Produit, Marque, Catégorie"
  placeholder="Rechercher un produit rappele..."
  operator="words"
  count>
</dsfr-data-search>

<dsfr-data-facets id="filtered" source="searched"
  fields="Catégorie, Marque"
  labels="Catégorie:Catégorie | Marque:Marque"
  max-values="6">
</dsfr-data-facets>

<dsfr-data-display source="filtered" cols="3" pagination="9">
  <template>
    <div class="fr-card">
      <div class="fr-card__body">
        <div class="fr-card__content">
          <h3 class="fr-card__title">{{Produit}}</h3>
          <p class="fr-card__desc">{{Marque}}</p>
        </div>
        <div class="fr-card__footer">
          <p class="fr-badge fr-badge--sm">{{Catégorie}}</p>
        </div>
      </div>
    </div>
  </template>
</dsfr-data-display>

Exemple 3 : recherche + KPI + graphique

Les KPI et le graphique se recalculent en temps réel selon la recherche. Rechercher par nom d'entreprise, département ou region.

Code

<dsfr-data-search id="searched" source="clean"
  fields="Entreprise, Region, Departement"
  placeholder="Entreprise, region, departement..."
  operator="words"
  count>
</dsfr-data-search>

<dsfr-data-kpi source="searched" value="count" label="Projets" color-token="bleu"></dsfr-data-kpi>
<dsfr-data-kpi source="searched" value="montant_investissement:sum" label="Investissement" format="euro"></dsfr-data-kpi>

<dsfr-data-query id="stats" source="searched"
  group-by="Region"
  aggregate="nombre_beneficiaires:sum:Beneficiaires"
  order-by="Beneficiaires:desc"
  limit="10">
</dsfr-data-query>

<dsfr-data-chart source="stats" type="bar"
  label-field="Region"
  value-field="Beneficiaires"
  selected-palette="categorical">
</dsfr-data-chart>

Événements

En plus de la ré-émission des données filtrées sur le data-bridge sous son propre id (dsfr-data-loaded / -loading / -error), le composant émet un événement custom à chaque recherche effective :

document.addEventListener('dsfr-data-search-change', (e) => {
  const { sourceId, term, count } = e.detail;
  console.log(`${count} résultats pour « ${term} » (${sourceId})`);
});