sao2.0/AG_GRID_STYLING_NOTES.md

# AG Grid Styling Notes In SAO

## Contexte

Cette note sert de memo pour les prochaines retouches AG Grid dans SAO/Tryton.
Le point cle de la session: AG Grid fonctionnait bien cote logique, mais son rendu etait fortement perturbe par le vieux socle CSS global de SAO.

## Probleme racine

Le vrai probleme n'etait pas AG Grid lui-meme.
Le probleme etait la collision entre:

- le theme AG Grid
- les styles globaux SAO sur `input`, `select`, `radio`, `checkbox`
- les pseudo-elements `::before` / `::after`
- les wrappers de formulaires anciens
- les popups AG Grid rendus hors du conteneur principal

En pratique, on avait plusieurs couches CSS qui essayaient de controler les memes primitives HTML.

## Symptomes observes

- glyphes bizarres a la place des icones AG Grid
- checkbox et radios au mauvais rendu
- filtre popup mal positionne
- styles natifs AG Grid partiellement casses
- interactions radio `AND / OR` visuellement instables
- tri et filtre avec affichage incoherent
- barre de scroll horizontale parasite dans le popup
- ecarts visuels tres differents du style AG Grid standard

## Ce qui a marche

### 1. Remplacer les icones AG Grid critiques par des icones custom simples

Ce qui a aide:

- redefinir `grid_options.icons`
- utiliser un SVG simple pour le bouton menu
- utiliser des symboles HTML simples pour certains etats

Pourquoi:

- ca evitait la dependance aux polices/glyphes natifs qu'un vieux CSS pouvait casser

### 2. Utiliser des logs DOM cibles au lieu de corriger "a l'oeil"

Les logs qui ont vraiment aide:

- `HEADER_DEBUG`
- `FILTER_POPUP_DEBUG`
- `FILTER_CLICK_PROBE`
- `FILTER_RADIO_NODE_DEBUG_JSON`
- `FILTER_LAYOUT_DEBUG_JSON`
- `HEADER_LAYOUT_DEBUG_JSON`

Regle pratique a garder:

- preferer un JSON plat pour les traces a copier-coller depuis la console
- eviter les objets imbriques quand le but est un partage rapide dans le chat
- si besoin, garder en plus un log riche pour le debug local, mais toujours ajouter une variante `..._FLAT_JSON`
- produire ces traces plus frequemment et plus tot dans la boucle de debug
- si 1 ou 2 corrections "a l'oeil" ne suffisent pas, instrumenter tout de suite
- ne pas reserver cette methode aux seuls bugs CSS: l'utiliser aussi pour les bugs de state et de rendering

Pourquoi:

- ils ont permis d'identifier le vrai noeud responsable
- ils ont evite de corriger le mauvais element
- sur la session `Columns` / `Grouping`, c'est la combinaison `action/state/rowData` en JSON plat qui a permis d'identifier les vrais problemes de state

### 3. Diagnostiquer les pseudo-elements avec `getComputedStyle(..., '::before')` et `::after`

Tres utile pour trouver:

- les icones parasites du header
- le residu devant `OR`

Constat important:

- dans un des cas, le glyphe parasite etait porte par
  `.ag-radio-button-input-wrapper::after`
- pas par l'input
- pas par le texte
- pas par un vrai noeud visible dans le HTML dump

### 4. Mesurer les layouts reels

Le dump `FILTER_LAYOUT_DEBUG_JSON` a permis de voir:

- qui portait encore `overflow-x: auto`
- quelle hauteur avaient reellement les selects
- quelle largeur avait vraiment le popup

Le dump `HEADER_LAYOUT_DEBUG_JSON` a permis de voir:

- que le decalage a corriger concernait surtout le bouton/menu header visible
- pas seulement le conteneur de tri

### 5. Corriger avec des regles tres specifiques

Exemples utiles:

- viser `html[theme="default"] .ag-popup ...`
- viser `.ag-header-label-icon.ag-filter-icon`
- viser `.ag-radio-button-input-wrapper::after`

Pourquoi:

- plusieurs regles generales plus anciennes battaient nos premiers overrides

## Ce qui n'a pas marche ou a fait perdre du temps

### 1. Essayer de "prioriser AG Grid globalement"

On a tente de donner plus de priorite globale au CSS AG Grid.
Resultat:

- regression visuelle
- retour de vieux styles
- interactions plus difficiles a stabiliser

Conclusion:

- ne pas faire de grand changement de priorite CSS sans isolation claire

### 2. Corriger des symptomes sans identifier le noeud exact

On a perdu du temps quand on corrigeait:

- `ag-icon`
- puis `input[type=radio]`
- puis des wrappers

alors que le probleme venait parfois d'un pseudo-element plus precis.

Conclusion:

- si un glyphe resiste plus de 1 ou 2 passes, faire tout de suite un dump cible

### 3. Masquer completement les inputs radios

On a essaye `display: none` ou une neutralisation trop agressive.
Resultat:

- perte de l'interaction
- rendu incoherent

Conclusion:

- garder l'input pour la logique
- neutraliser seulement son rendu visuel ou piloter explicitement l'etat visuel

### 4. S'appuyer sur des hypotheses sur l'etat AG Grid

Par exemple:

- supposer qu'une classe AG Grid serait toujours presente
- supposer que le popup utile etait toujours `params.ePopup`

Conclusion:

- verifier avec logs si l'etat/classe existe vraiment

## Methode recommandee pour la prochaine fois

### Etape 1. Classer le probleme

Identifier si le probleme est:

- logique
- positionnement
- rendu visuel
- overflow/layout
- icone/glyphe/pseudo-element

### Etape 2. Si c'est visuel et resistant, mesurer avant de modifier

Faire directement:

- dump du HTML reel
- dump des dimensions reelles
- dump des `::before` / `::after`
- variante `..._FLAT_JSON` pour tout ce qui doit etre partage rapidement

### Etape 2 bis. Si c'est un bug de state, tracer avant de retoucher encore l'UI

Faire directement:

- trace de l'action utilisateur
- trace du state avant/apres
- trace de la donnee effectivement envoyee au composant

Format recommande:

- JSON plat
- une trace par etape cle
- noms explicites du type `ACTION_FLAT_JSON`, `STATE_FLAT_JSON`, `ROW_DATA_KIND_FLAT_JSON`

### Etape 3. Chercher le vrai proprietaire du rendu

Verifier si le rendu vient de:

- l'input
- le wrapper
- le parent
- une icone AG Grid
- un pseudo-element
- une regle globale SAO

### Etape 4. Ecrire la regle la plus locale possible

Preferer:

- un selecteur specifique AG Grid popup/header
- une correction locale

Eviter:

- les gros changements globaux de priorite
- les surcharges larges sur tout AG Grid si un seul noeud est fautif

### Etape 5. Enlever les logs une fois le sujet stabilise

Garder au maximum:

- les dumps de layout reactivables

Retirer:

- les probes tres bavards
- les logs de clic temporaires

Exception pratique:

- garder quelques points de trace reactivables sur les zones historiquement fragiles comme `Columns`, `Grouping` et les popups AG Grid, tant que le POC continue a bouger rapidement

## Memo supplementaire apres le dark mode V1

Le dark mode a confirme une autre regle utile:

- quand un bloc entier "reste clair", il faut d'abord identifier le conteneur parent exact qui porte encore le fond legacy
- dans SAO/Tryton, ce n'est pas toujours le composant visible qui porte vraiment la couleur, mais un wrapper `panel`, `panel-body`, `toolbar` ou `container-fluid`

Approche qui a fonctionne:

- corriger d'abord le shell principal
- puis les toolbars locales
- puis les composants modernes comme AG Grid
- laisser les composants fragiles hors perimetre tant qu'ils ne sont pas inventories

Pour les prochaines retouches dark mode:

- preferer des overrides locaux sous `html[data-theme-mode="dark"]`
- eviter les modifications globales du theme light existant
- garder le mode light strictement identique tant que possible

## Signaux d'alerte a retenir

Si on revoit l'un de ces symptomes:

- glyphe bizarre persistant
- style qui ne repond pas a un override simple
- radio/checkbox visuellement faux
- popup qui n'obeit pas a son CSS apparent

alors il faut supposer tres tot:

- conflit de pseudo-elements
- conflit de cascade avec le theme SAO
- mauvais noeud cible

## Recommandation structurelle

Pour gagner du temps a long terme, il faudrait idealement:

- isoler davantage AG Grid du CSS global SAO
- ou etablir une zone de styles AG Grid plus clairement encapsulee
- ou nettoyer les vieilles regles globales SAO qui touchent fortement les formulaires natifs

Sinon, chaque nouveau composant AG Grid complexe risque de reouvrir le meme type de debugging.