chore: release

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

dsfr-data@0.47.0

Minor Changes

• #1258 466e85b Thanks @bmatge! - Éléments d'un champ tableau dans compute (#1237) — complète la résolution du constat AM-103 du banc d'essai : l'accès au n-ième élément d'un tableau, que la note de la 0.45.0 disait non couvert.

  • element_at(arr, n) : l'élément de rang n. principale = element_at(denominations, 1) rend la dénomination principale (le premier terme d'une liste) en une expression, sans explode ni jointure. Les rangs se comptent à partir de 1, comme les positions de substr et comme element_at en SQL (Spark, Trino) ; un rang négatif compte depuis la fin (element_at(arr, -1) est le dernier élément). L'élément est rendu tel quel, sans conversion. Rang hors du tableau, tableau vide, valeur absente, rang absent ou non numérique : null. element_at(arr, 0) ou un rang non entier écrit en dur est une erreur de configuration (le décalage d'une habitude base 0) ; calculé, il rend null.
  • array_min(arr) et array_max(arr) : le plus petit et le plus grand élément. Le plus ancien poste d'une liste de dates n'est pas forcément le premier listé : plus_ancien = array_min(prises_de_poste), annee = year(array_min(prises_de_poste)) ; la première année d'une datation multivaluée s'écrit array_min(datation), là où il fallait quatre étapes (split, explode, numeric, min) et une jointure. Les éléments absents (null, chaîne vide) sont ignorés ; la comparaison est numérique quand tous les éléments restants sont des nombres (« 950 » avant « 1050 », décimale française comprise), textuelle quand aucun ne l'est (les dates ISO se rangent juste). L'élément gagnant est rendu tel quel ('01004' garde son zéro). Ce ne sont pas les agrégations min / max de dsfr-data-query, qui réduisent des lignes.
  • Une valeur qui n'est pas un tableau rend null — un scalaire n'est pas un tableau d'un élément. Une cellule « collée » ("1972 ; 1965 ; 1980") est un texte : la découper avec split, dans le même dsfr-data-normalize (split s'exécute avant compute) — split="datation:;" compute="premiere = array_min(datation)".
  • Un tableau mixte rend une valeur vide, et le dit. Sur 950 ; 1050 ; vers 1970 — des nombres et du texte — array_min et array_max rendent null avec un avertissement en console, au lieu d'un ordre de texte plausible et faux (« 1050 »). Les éléments se nettoient par attributs, en deux dsfr-data-normalize chaînés : compute="datation = replace(join(datation, ';'), 'vers ', '')" dans le premier, split="datation:;" compute="premiere = array_min(datation)" dans le second (cellule collée ou vrai tableau). Sur un vrai tableau, replace-fields="datation:vers 1970:1970" suffit dans un seul normalize quand les valeurs à corriger sont connues.
  • Une colonne entièrement vide faute de split est signalée. Quand element_at, array_min ou array_max ne reçoit aucun tableau sur l'ensemble des lignes alors que le champ porte des valeurs, un avertissement console (relayé par le volet Diagnostic) nomme le champ et le split à poser — une fois par composant et par cause. Rien n'est dit quand la colonne est réellement vide, ni quand une partie des lignes porte un tableau.

  Ce qui n'est pas livré : pas de syntaxe d'index arr[n], pas de séparateur en argument (c'est le rôle de split), pas de tableau littéral, ni filtrage, tri ou transformation des éléments d'un tableau, ni somme ou moyenne de ses éléments (explode puis une agrégation de dsfr-data-query).

Patch Changes

• #1259 0d7b5c5 Thanks @bmatge! - Studio IA et volet Diagnostic : un code département, un code postal ou un libellé terminé par un nombre n'est plus annoncé comme une date (#1224).

  Le type d'un champ était lu sur une seule valeur, par Date.parse — qui, sous V8, lit « 75 », « 01004 » et « Zone 12 » comme des dates. Le modèle du Studio recevait donc un champ géographique présenté comme temporel, ce qui l'orientait vers une courbe au lieu d'une carte ou d'un classement.

  Un champ est désormais une date quand toutes ses valeurs renseignées, sur les 100 premières lignes, ont la forme ISO (AAAA-MM-JJ, heure facultative) : c'est la forme que le reste de la bibliothèque traite en date (minimum et maximum d'une agrégation, pivot), reconnue par la même fonction. Une année seule écrite en chaîne (« 2024 ») et une date française (« 03/01/2024 », « 4 décembre 1837 ») sont du texte ; un nombre reste numérique.

• #1260 b8734ed Thanks @bmatge! - Cohérence entre le graphique et son tableau équivalent (#1244) : six défauts voisins des lots 3 et 5 du banc d'essai.

  • label-field de dsfr-data-chart accepte champ:Libellé — suite du constat PG-032 du banc d'essai. dsfr-data-a11y accepte cet alias depuis la 0.45.0, le graphique ne l'acceptait pas : label-field="dep:Département", recopié du tableau équivalent, cherchait une colonne « dep:Département » et tous les libellés de l'axe devenaient « Non renseigné ». Les deux composants passent maintenant par le même analyseur. La colonne lue est dep ; le libellé devient l'en-tête de la colonne de libellé du tableau de la DataBox — il ne sert nulle part ailleurs, DSFR Chart n'ayant pas de titre d'axe. Sans deux-points, rien ne change ; une colonne dont le nom contient réellement un deux-points reste lue telle quelle.

  • Le tableau de la DataBox écrit ses nombres en français — suite du constat BUG-035 du banc d'essai. Il affichait 2.27 là où le tableau de dsfr-data-a11y affiche « 2,27 » pour la même ligne. Les deux tableaux passent par une seule fonction de format : nombres en fr-FR, au plus deux décimales, chaînes intactes (un code « 01 » reste « 01 »). Les valeurs passées au graphique ne changent pas. La colonne de libellé porte désormais ce que l'axe affiche : une année numérique reste « 2024 », et une catégorie vide porte empty-label (« Non renseigné ») au lieu d'une cellule vide — ce que faisait déjà le format long.

  • dsfr-data-a11y lit ses colonnes par chemin pointé, comme le graphique — suite du constat PG-032 du banc d'essai. value-field="fields.total", recopié de dsfr-data-chart, cherchait une colonne à plat nommée « fields.total » : le tableau gardait ses lignes et rendait une colonne vide. Le tableau, son pivot au format long (series-field), le CSV téléchargé et l'avertissement « colonne introuvable » lisent maintenant par chemin. Une colonne à plat dont le nom contient réellement un point (taux.brut) reste lue telle quelle.

  • color-map par libellé d'axe colore les points — suite du constat BUG-033 du banc d'essai. Quand les modalités de color-map nomment des libellés de l'axe et non des séries, une courbe, un radar ou un nuage de points ne coloraient aucun point ; pire, le trait entier prenait la couleur de la première modalité, la pastille de légende aussi, et l'aire d'un radar devenait opaque. Chaque point nommé prend désormais sa couleur ; le trait, l'aire et la légende gardent celle de la série. Les barres et les camemberts, qui suivaient déjà, ne changent pas.

  • order-by sur une part, un cumul ou un écart est appliqué, et n'est plus délégué — aggregate="n:share_percent" order-by="n__share_percent:desc" envoyait le tri au serveur sur une colonne qu'il ne connaît pas (order_by=n__share_percent sur Opendatasoft, sort= sur Grist ; Tabular refusait la requête et la query n'affichait plus rien), et les lignes n'étaient triées sur aucun adaptateur, même après un group-by : le tri passait avant le calcul de la colonne. Un tri qui nomme une colonne produite par share, share_percent, running_sum ou diff (ou son alias) reste désormais côté client et s'applique après le calcul, avant limit — « les cinq plus grandes parts » sont bien les cinq plus grandes. Les autres clés du même order-by ordonnent toujours les lignes avant un cumul ; un cumul trié sur sa seule colonne est calculé dans l'ordre des lignes reçues, et un avertissement console le dit. Le tri sur une colonne issue d'un compute n'était pas en défaut.

  • Podium : value-unit suit une espace insécable — comme subtitle-unit et l'unité de dsfr-data-kpi. « 2 300 hab. » ne se coupe plus en fin de ligne entre le nombre et son unité ; le libellé lu par les lecteurs d'écran porte la même espace.

• #1259 986b8eb Thanks @bmatge! - Export du Studio IA et du Tableau de bord : un tableau sur une source Tabular ne demande plus que les colonnes qu'il lit (#1225, reprise de #985).

  L'ancien Assistant IA limitait les colonnes demandées à l'API Tabular pour un tableau ; l'optimisation était partie avec lui. L'export partagé pose de nouveau select sur la source — que l'adaptateur traduit en columns= — avec les colonnes affichées, le champ de tri et les champs du filtre du tableau. Le tableau affiche les mêmes lignes : seule la requête change.

  Une source étant émise une seule fois pour tout le document, le select n'est posé que si tous ses consommateurs savent énumérer leurs colonnes : le tableau seul lecteur de sa source, ou plusieurs tableaux sans recherche (l'union de leurs colonnes, champs d'un bloc de filtres compris). Dès qu'un graphique, un KPI, une carte ou un composant libre lit la même source, ou qu'un tableau porte une recherche locale (elle cherche dans toutes les valeurs de la ligne), la source garde toutes ses colonnes. Pas de select non plus quand le tableau affiche tout, quand un nom n'est pas un champ connu de la source (l'API répondrait 400) ou quand la source n'a aucune ligne chargée.