Refactor Button Component with New Variants and Props

[pplancq]

Description:

This PR introduces significant changes to the button component, including a restyle with the new-look Slash DS and the introduction of variant props instead of classModifier. The following breaking changes are included

closes #751

Breaking Changes:

1. Restyle Button with New-Look Slash DS

   • Removed universes variant; use custom class if needed.
   • Removed hasIconLeft/hasIconRight; CSS now auto-detects use of SVG or glyphicon.
   • Renamed reverse variant to secondary.
   • Renamed success variant to validated.
   • Removed disabled variant; now use button's disabled prop.
   • Removed circle variant.

2. Introduction of Variant Props

   • Prop className no longer removes default style.
   • Removed prop classModifier; use props variant, size, leftIcon, and rightIcon instead.

Additional Information:

For the CSS part, I have introduced the use of CSS variables for colors, fonts, etc., as well as mixins to provide various shortcuts for creating our CSS classes. All these modifications are open to discussion and may lead to the drafting of an ADR on CSS best practices.

Screanshot:

[johnmeunier]

Lorsqu'il y a des breaking change impliqué par une PR, il faudrait que cette PR mette à jour tout de suite le guide de Migration, ca évitera de le faire au dernier moment avant la livraison de la nouvelle version.

Je vois qu'ici il n'y a que le guide de migration depuis le premier toolkit. Le MIGRATION.md peut être initialisé grâce à cette PR.

[pplancq]

Lorsqu'il y a des breaking change impliqué par une PR, il faudrait que cette PR mette à jour tout de suite le guide de Migration, ca évitera de le faire au dernier moment avant la livraison de la nouvelle version.

Je vois qu'ici il n'y a que le guide de migration depuis le premier toolkit. Le MIGRATION.md peut être initialisé grâce à cette PR.

Yes pas faux j'ai complément zapper le guide de migration, je le fais des que possible

[sonarqubecloud]

Quality Gate failed

Failed conditions
48.8% Coverage on New Code (required ≥ 80%)
6.8% Duplication on New Code (required ≤ 3%)
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[JLou]

je ne vois pas l'intéret de cette mixin. Passons nous en !

[pplancq]

le est d'avoir des mixin utilitaire que corresponde au fonts style du DS https://zeroheight.com/4b1e27a45/v/latest/p/9506de-fonts-style
Afin que si cela change on est à le changé qu'a un seul endroit, maintenant vue qu'on c'est dit de minimiser l'utilisation de sass je pense qu'il faudrait transformer la mixin en class css utilitaire.

[pplancq]

@JLou afin de te montrer ma vision des choses et de ne pas surcharger cette PR j'ai séparé cette partie dans une autre PR #890

n'hésite pas à me dire ce que tu en penses.

[JLou]

question: Est ce que c'est utile de mettre "primary" dans les variants ?
Ca peut éviter de mettre une condition sur === "primary"

[pplancq]

Je vois ce que tu veux dire, ou alors on veut faire un truc à la bootstrat a savoir ajouter une classe css af-btn--primary
(d'ailleurs idem pour le size) cela évitera la condition on aurait juste classNames(DEFAULT_CLASS_NAME, ${DEFAULT_CLASS_NAME}--${variant}, ${DEFAULT_CLASS_NAME}--${size}, className)

Parce que perso je ne suis pas fan du fait de ne pas mettre le variant primary. mais c'est juste une pref perso.

[pplancq]

J'ai fais des changements j'ai pris exemple sur le fonctionnement de bootstrap ou il faut mettre les class af-btn et af-btn--primary au minimum.
et j'ai passer la props size en small en mode boolean.

dit moi ce que tu en penses.