Refactor Footer Component and restyle with the new-look Slash DS #838

pplancq · 2025-02-05T15:58:53Z

Description:

This PR introduces significant changes to the Footer component, including a restyle with the new-look Slash DS and new simple html structure. The following breaking changes are included

closes #809

add change

add storybook add viewport for check responsive component
add new grid and breakpoint https://zeroheight.com/4b1e27a45/v/latest/p/5045af-breakpoints

Breaking Change

new structure html for footer composent(use display grid)
new props version for set version of application in footer.

Screenshot:

johnmeunier · 2025-02-14T08:12:00Z

Je pense que cette PR mélange énormément de sujet très structurant, pour la faire avancer le plus simple serait de séparer les sujets. Par exemple pour l'ajustement visuel du footer, ca pourrait partir dans une v1 si seulement il y avait que ça. La grid ou les autres sujets pourraient être tirer à part, quand ils auront été validés en équipe

MartinWeb · 2025-02-14T08:13:16Z

slash/react/src/Grid/Grid.tsx

@@ -0,0 +1,37 @@
+import {


ça serait bien de séparer le système de Grid dans une autre PR pour réduire la complexité de celle-ci.
De plus, @samuel-gomez a déjà mis en place une Grid sur L&F, pourquoi en redévelopper une nouvelle plutôt que capitaliser sur celle-là ?

Je peux effectivement séparer la grid dans une autre PR, mais j'en aurais besoin pour cette PR.
Pour ce qui est de la grid slash ce c'est pas la même que celle de L&F. dans notre cas nous avons qu'une seul collonne.
https://zeroheight.com/4b1e27a45/v/latest/p/5045af-breakpoints

on n'a pas qu'une seule colonne actuellement sur slash étant donné qu'on utilise bootstrap. Les breakpoints n'influent pas sur la grille que l'on a ensuite derrière

Alors je ne remet pas en cause l'utilisation de la grid bootstrap, cependant quand je lit les règles du DS sur zeroheight il y en a aucun mentions, alors il y a 2 solutions, sois c'est un oublie, auquel cas les UX/UI devrait corriger la doc zeroheight, sois c'est effectivement le cas et on aura plus besoin de la grid bootstrap, d'ailleurs il prévue de ce séparer de la grid bootstrap mais on a pas de remplaçant actuellement.

La grid bootstrap va disparaitre c'est une certitude, mais ce n'est pas encore pour tout de suite. La suppression de bootstrap est prévue en v3 dans la roadmap, mais en attendant on doit la conserver et au sein de la grid on doit bien continuer à avoir les 12 colonnes (en mode full) comme bootstrap pour le moment.
La Grid que @samuel-gomez a implémenté sur L&F permet cela et il me semble qu'on avait bien dit qu'elle serait repris ensuite sur Slash. @JLou tu confirmes ?

La suppression de la grille c'est prévu pour la v3, là on serait vraiment trop en avance de phase je pense.

On peut pas juste garder la grille actuelle et "corriger" les marges et taille pour correspondre à ce qu'attend le zero height ?

Ben justement je n'ai pas supprimé la grid bootstrap elle est toujours la et peut être utiliser au besoin.
Et je le re dit si slash dois avoir une grid en 12 colonnes cela doit être indiqué dans les règles du DS sur zeroheight.
Si ca n'est pas présent sur zeroheight cela n'a donc rien à faire dans ce toolkit.

MartinWeb · 2025-02-14T08:15:26Z

MIGRATION-GUIDE-SLASH-FROM-V1.md

+- <Footer title="Axa">
+-   <strong>@ {new Date().getFullYear()} AXA</strong>
+- </Footer>
+ <Footer version="1.0.0" />


que se passe-t-il si l'on veut mettre autre chose qu'une version dans le footer ? ne plus avoir de children bloque complètement l'utilisation du composant je trouve

Justement vue les règles du design system on ne peut rien mettre d'autre dans le footer que le logo, le copyright et la version
https://zeroheight.com/4b1e27a45/v/latest/p/64fb51-footer/b/15c512/t/f7f70e223c

j'ai peur que ça ferme le composant et qu'on se retrouve possiblement bloqué là-dessus. Qu'en pensez-vous @JLou @samuel-gomez @johnmeunier ?

J'en ai parler parler avec @adrien-dos (notre UX sur slash) est il ma dit que le footer b2b ne devrait contenir rien autre.
Si c'est pas le cas il faut l'indiqué dans les règles du DS sur zeroheight.

Je suis partagé, j'avais failli faire la remarque.

Effectivement le zero height ne parle pas de children. Après j'aime pas bloquer le consommateur, ici juste donner la possibilité de débrancher le footer et ajouter un children "au cas où" l'UX sur le projet consommateur demanderait une spécificité permettrait au consommateur de toujours utiliser le composant footer et répondre au besoin. Un bon compromis je pense

Je suis d'accord, j'ai déjà eu le coup sur des composants côté L&F où j'avais trop restreint en me basant sur la maquette et sur les règles théoriques. Au final on a eu un cas exceptionnel sur notre projet où on avait besoin de modifier un petit truc et on était bloqué.
Au moins avec une valeur par défaut qu'on peut remplacer si besoin ça permet une certaine flexibilité tout en gardant le comportement voulu de base.

Oui c'est un peu l'une des préco de mettre des ReactNode plutôt que des string pour avoir un peu plus de souplesse sur nos composants

MartinWeb · 2025-02-14T08:20:29Z

slash/css/src/common/breakpoint.scss

@@ -0,0 +1,36 @@
+@use "sass:map";


dans le fichier common je vois qu'on a déjà beaucoup de code qui s'apparentent à des breakpoint, est-ce qu'il ne faudrait pas tout mettre au même endroit ?

Justement c'est ce but de ce fichier, sauf que au lieu de tous séparer je déplace/place ce dont j'ai besoin afin qu'a therme la seul chose qui reste du common parte à la corbeille.

pourquoi ne pas supprimer du common également du coup ?

parce que je ne sais pas se qui est utilisé ou pas actuellement dans notre toolkit slash.
Je préfère le faire à la fin.

MartinWeb · 2025-02-14T08:21:47Z

slash/react/.storybook/viewPorts.js

@@ -0,0 +1,51 @@
+/** @type { import('@storybook/addon-viewport').ViewportMap } */


c'est le même fichier que dans le package css ? ne peut-on pas le mettre dans un dossier commun ?

J'ai tenté mais cela ne pas marché si tu as une solution je suis preneur

slash/react/src/Layout/Footer/Footer.stories.tsx

MartinWeb · 2025-02-14T08:23:36Z

slash/react/src/Layout/Footer/Footer.tsx

+      ref={ref}
+    >
+      {/* eslint-disable-next-line jsx-a11y/alt-text */}
+      <img className="af-footer__logo" src={logoAxa} aria-hidden />


est-ce que l'img avec role="presentation" n'est pas mieux qu'en aria-hidden ?

justement d'après le RGAA https://accessibilite.numerique.gouv.fr/methode/criteres-et-tests/#1.2
il faut soit un aria-hidden ou un role="presentation", perso je trouve que le aria-hidden est plus parlant

J'utilise plutôt role="presentation" de mon côté.
@JLou @samuel-gomez @johnmeunier qu'en pensez-vous ?

Perso même si dans l'absolu role="presentation" indique clairement que l'image n'a pas un rôle d'image, on ne voit pas de suite les implications induite.
Alors qu'avec un aria-hidden, notre image garde sont role="image" donc on peut facilement la capture lors des tests, mais surtout l'attribut aria fait directement référence à l'accessibilité et donc ici masque l'image pour les lecteurs d'écran.

Mais dans l'absolu les 2 solutions sont valide RGAA donc je me rangerai à l'avis majoritaire.

Franchement pas d'avis pour le coup, mais un bon point à remonter dans les guidelines ! J'aurais presque envie de dire de mettre les deux pour être explicite.

Par contre je vois pas dans quel cas on aurait besoin de tester une image qui serait en hidden ? Un test sur quelque chose que tout le monde n'aurait pas accès ? Je vois pas d'exemple

Si c'est juste pour mettre en décorative l'image, un simple alt vide devrait suffire pour les lecteurs d'écran non ?
https://www.w3.org/WAI/tutorials/images/decorative/

c'est une des 3 méthodes que le RGAA recommande https://accessibilite.numerique.gouv.fr/methode/criteres-et-tests/#1.2.1

Il ne faut pas oublié que nous devons respecté en France le RGAA qui est une extension du WCAG

D'accord
Apparemment, selon W3C, le alt vide est plus supporté par les lecteur d'écran que le role="presentation".
Et après pour aria-hidden j'imagine que c'est bien supporté. 😅

yes après je pense entre aria-hidden ou role="presentation" c'est plus une histoire de gout.

slash/css/src/Layout/Footer/Footer.stories.css

slash/react/src/Layout/Footer/Footer.stories.css

slash/react/src/Layout/Footer/Footer.stories.tsx

slash/react/src/Layout/Footer/Footer.tsx

GuillaumeKESTEMAN · 2025-02-14T08:28:54Z

Je pense que cette PR mélange énormément de sujet très structurant, pour la faire avancer le plus simple serait de séparer les sujets. Par exemple pour l'ajustement visuel du footer, ca pourrait partir dans une v1 si seulement il y avait que ça. La grid ou les autres sujets pourraient être tirer à part, quand ils auront été validés en équipe

Je suis d'accord que le sujet de grid devrait être dans une PR à part car elle n'a aucun rapport avec le Footer.
Ensuite côté style + refacto si c'est possible de séparer pourquoi pas 👍

pplancq · 2025-02-14T09:06:29Z

Je pense que cette PR mélange énormément de sujet très structurant, pour la faire avancer le plus simple serait de séparer les sujets. Par exemple pour l'ajustement visuel du footer, ca pourrait partir dans une v1 si seulement il y avait que ça. La grid ou les autres sujets pourraient être tirer à part, quand ils auront été validés en équipe

Je suis d'accord que le sujet de grid devrait être dans une PR à part car elle n'a aucun rapport avec le Footer. Ensuite côté style + refacto si c'est possible de séparer pourquoi pas 👍

Pour moi je peux séparer la grid dans une PR mais dans tous les cas j'en aurais besoin pour le footer, par contre le footer étant tellement différent d'un point de vue des règles DS que je ne peux pas le modifier sans break donc pour la v2

GuillaumeKESTEMAN · 2025-02-14T09:16:13Z

Je pense que cette PR mélange énormément de sujet très structurant, pour la faire avancer le plus simple serait de séparer les sujets. Par exemple pour l'ajustement visuel du footer, ca pourrait partir dans une v1 si seulement il y avait que ça. La grid ou les autres sujets pourraient être tirer à part, quand ils auront été validés en équipe

Je suis d'accord que le sujet de grid devrait être dans une PR à part car elle n'a aucun rapport avec le Footer. Ensuite côté style + refacto si c'est possible de séparer pourquoi pas 👍

Pour moi je peux séparer la grid dans une PR mais dans tous les cas j'en aurais besoin pour le footer, par contre le footer étant tellement différent d'un point de vue des règles DS que je ne peux pas le modifier sans break donc pour la v2

Oui bien sûr, on peut faire comme ça du coup 👍

MartinWeb · 2025-02-14T09:35:28Z

Je pense que cette PR mélange énormément de sujet très structurant, pour la faire avancer le plus simple serait de séparer les sujets. Par exemple pour l'ajustement visuel du footer, ca pourrait partir dans une v1 si seulement il y avait que ça. La grid ou les autres sujets pourraient être tirer à part, quand ils auront été validés en équipe

Je suis d'accord que le sujet de grid devrait être dans une PR à part car elle n'a aucun rapport avec le Footer. Ensuite côté style + refacto si c'est possible de séparer pourquoi pas 👍

Pour moi je peux séparer la grid dans une PR mais dans tous les cas j'en aurais besoin pour le footer, par contre le footer étant tellement différent d'un point de vue des règles DS que je ne peux pas le modifier sans break donc pour la v2

Qu'est-ce qui diffère exactement sur le footer qui force à break ?
En dehors de l'ajout de la props version je ne vois pas trop.

pplancq · 2025-02-14T09:54:59Z

Je pense que cette PR mélange énormément de sujet très structurant, pour la faire avancer le plus simple serait de séparer les sujets. Par exemple pour l'ajustement visuel du footer, ca pourrait partir dans une v1 si seulement il y avait que ça. La grid ou les autres sujets pourraient être tirer à part, quand ils auront été validés en équipe

Je suis d'accord que le sujet de grid devrait être dans une PR à part car elle n'a aucun rapport avec le Footer. Ensuite côté style + refacto si c'est possible de séparer pourquoi pas 👍

Pour moi je peux séparer la grid dans une PR mais dans tous les cas j'en aurais besoin pour le footer, par contre le footer étant tellement différent d'un point de vue des règles DS que je ne peux pas le modifier sans break donc pour la v2

Qu'est-ce qui diffère exactement sur le footer qui force à break ? En dehors de l'ajout de la props version je ne vois pas trop.

le footer n'a plus la même structure html et donc les même class css ce qui implique que les consommateurs aurons du travaille s'il cible les class css.
le composant footer n'a plus la même signature, plus de children, plus les props logo, href etc ...

donc tous ca fait que ca break.

johnmeunier · 2025-02-14T13:27:19Z

Je pense que cette PR mélange énormément de sujet très structurant, pour la faire avancer le plus simple serait de séparer les sujets. Par exemple pour l'ajustement visuel du footer, ca pourrait partir dans une v1 si seulement il y avait que ça. La grid ou les autres sujets pourraient être tirer à part, quand ils auront été validés en équipe

Je suis d'accord que le sujet de grid devrait être dans une PR à part car elle n'a aucun rapport avec le Footer. Ensuite côté style + refacto si c'est possible de séparer pourquoi pas 👍

Pour moi je peux séparer la grid dans une PR mais dans tous les cas j'en aurais besoin pour le footer, par contre le footer étant tellement différent d'un point de vue des règles DS que je ne peux pas le modifier sans break donc pour la v2

Qu'est-ce qui diffère exactement sur le footer qui force à break ? En dehors de l'ajout de la props version je ne vois pas trop.

le footer n'a plus la même structure html et donc les même class css ce qui implique que les consommateurs aurons du travaille s'il cible les class css. le composant footer n'a plus la même signature, plus de children, plus les props logo, href etc ...

donc tous ca fait que ca break.

Là on parle de contrainte technique en préparant le futur.

Mais fonctionnellement on parle que de l'ajout de la version en prop et des tailles / marges, donc on pourrait juste faire ces modifs avec le composant actuel sans break et l'envoyer dans la v1 nan ?

…cumentation

pplancq · 2025-02-18T08:04:58Z

Conformément à nos discussions j'ai séparer la grid dans une PR dédier ici #892

cette PR seras en attente le temps que l'autre PR sois merge et rebase sur la v2.

BREAKING CHANGE: **footer**, props `className` don't remove default class BREAKING CHANGE: **footer**, new props `version` for set the version of application BREAKING CHANGE: **footer**, new structure for footer based on display grid

pplancq added agent-slash Component for the agent theme component component needs to be worked on breaking-change labels Feb 5, 2025

pplancq added this to the Slash 2.0.0 - Remplacer les classmodifiers par des variants milestone Feb 5, 2025

pplancq self-assigned this Feb 6, 2025

pplancq force-pushed the feature/footer branch from 499282d to 1af2ca7 Compare February 6, 2025 14:52

chore(design-system,slash): add custom viewports for Storybook

99b4e50

pplancq force-pushed the feature/footer branch from d7a29d9 to 0394b6a Compare February 12, 2025 13:29

MartinWeb reviewed Feb 14, 2025

View reviewed changes

GuillaumeKESTEMAN reviewed Feb 14, 2025

View reviewed changes

pplancq force-pushed the feature/footer branch 2 times, most recently from a0fad3d to ba7d205 Compare February 18, 2025 07:48

pplancq added 3 commits February 18, 2025 09:02

feat(slash): add Grid component and breakpoint utility

9790a52

test(slash): add tests for Grid components

1fa82f0

chore(slash): start order top folder with same ordre of zeroheight do…

fc77d6b

…cumentation

pplancq added 2 commits February 18, 2025 09:06

feat(slash)!: restyle footer with new-look Slash DS

06805be

BREAKING CHANGE: **footer**, props `className` don't remove default class BREAKING CHANGE: **footer**, new props `version` for set the version of application BREAKING CHANGE: **footer**, new structure for footer based on display grid

test(slash): add tests for Footer components

e32a641

pplancq force-pushed the feature/footer branch from ba7d205 to e32a641 Compare February 18, 2025 08:37

		@@ -0,0 +1,51 @@
		/** @type { import('@storybook/addon-viewport').ViewportMap } */

Refactor Footer Component and restyle with the new-look Slash DS #838

Are you sure you want to change the base?

Refactor Footer Component and restyle with the new-look Slash DS #838

Conversation

pplancq commented Feb 5, 2025 • edited by johnmeunier Loading

Description:

add change

Breaking Change

Screenshot:

johnmeunier commented Feb 14, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GuillaumeKESTEMAN Feb 14, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

GuillaumeKESTEMAN commented Feb 14, 2025

pplancq commented Feb 14, 2025

GuillaumeKESTEMAN commented Feb 14, 2025

MartinWeb commented Feb 14, 2025

pplancq commented Feb 14, 2025

johnmeunier commented Feb 14, 2025

pplancq commented Feb 18, 2025

pplancq commented Feb 5, 2025 •

edited by johnmeunier

Loading

GuillaumeKESTEMAN Feb 14, 2025 •

edited

Loading