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.