✨(ats-presentation) add base form components

[ShallowRed]

📝 Description

🎸 Ajouts de composants de formulaire basiques :

• input
• textarea
• checkbox et checkbox group
• radio et radio group
• switch

🏷️ Type de changement

• 🐛 Correction de bug
• 🎢 Nouvelle fonctionnalité (changement non bloquant qui ajoute une fonctionnalité)
• 🥁 Changement breaking (modification ou fonctionnalité qui pourrait casser le fonctionnement existant) nécessitant une mise à jour de la documentation
• 📚 Mise à jour de la documentation
• ♻️ Refactorisation
• 🔧 Changement technique

✅ Liste de contrôle

• 💅 J’ai ajouté ou mis à jour les tests appropriés.
• 📝 J’ai mis à jour ou ajouté la documentation nécessaire.
• 🚀 J’ai pris en compte l’impact sur les performances, la sécurité et l’expérience utilisateur.
• 👀 J’ai demandé une revue à une personne de l’équipe.

[github-actions]

📖 Storybook de prévisualisation : https://betagouv.github.io/csplab/storybook/pr-682/

[smdsgn]

Les stories qui lazy-loadent le chunk _plugin-vue_export-helper-*.js cassent. Ce sont celles avec du style scoped j'imagine. Le problème sembel venir de Jekyll. Il faut sans doute ajouter un fichier .nojekyll dans le dossier Storybook avant le deploy.

[smdsgn]

@AliceGourbat C'est corrigé, tu peux faire la recette si tu veux.

[AliceGourbat]

• Chech box : je ne suis pas sûr de comprendre les cas d'usage de l'état indeterminé
• Input :
  • Disabled : j'ai peur que le contraste ne soit pas accessible
  • password : pourrait-on ajouter un oeil pour afficher le mdp ?
• radio : manque le cas erreur
• Switch : j'ai un doute sur l'emplacement du libellé notamment quand on voit l'impact de l'erreur

[AliceGourbat]

Commentaires ici : https://docs.numerique.gouv.fr/docs/88e596eb-e1cc-4deb-aa33-9bd04528314c/

[ShallowRed]

Chech box : je ne suis pas sûr de comprendre les cas d'usage de l'état indeterminé

C'était dans l'ui kit, je me suis dit que c'était peut-être intéressant (pour des cas de sélection groupée ou de hierarchie), mais pas sur !

---

Disabled : j'ai peur que le contraste ne soit pas accessible

C'est vrai que c'est pas idéal mais ça reproduit ce qui se fait côté dsfr, je pense qu'il y aura peu de cas d'usages avec champ visible + une valeur + disabled.

---

password : pourrait-on ajouter un oeil pour afficher le mdp ?

Ce sera plutôt un composant parent qui composera le champ mdp seul + un bouton avec œil voir autre chose

---

radio : manque le cas erreur

Le radio ne sera jamais utilisé seul (ça crééerait même une erreur dans le code), mais toujours dans un radiogroup qui a un cas d'erreur. Dans les faits c'est pas très intéressant d'avoir mis une story radio seule dédiée, j'aurais pu en faire qu'une sur le radiogroup.

---

Switch : j'ai un doute sur l'emplacement du libellé, notamment quand on voit l'impact de l'erreur

Je suis pas sur d'avoir compris mais celui là reste à pas mal certes à pas mal étoffer pour se rapprocher du dsfr.

[AliceGourbat]

• check box : Ah parfait c'était le cas auquel je pensais mais c'est le nom "indéterminé" qui m'a perdu 👍
• field Disabled : c'était plus dans l'idée de garder le même rendu mais peux-être modifier les teintes de gris pour garder le contraste ok. Mais si c'est trop complexe, no worries on se cale au DSFR
• password : ok 👍
• radio : oui tu as raison 👍
• switch : globalement si on se rapproche de celui du DSFR ça me va. C'était plutôt le fait d'avoir le libellé à droite avec le libellé en rouge en cas d'erreur que je trouvais problématique. Mais si on le gère comme radio & check (comme dans le dsfr) c'est niquel ! 👍