modul-components
modul-components copied to clipboard
ulaval
MODUL-500 - Améliorer la sémantique du composant Radio
@ulaval/modul-components
PR Checklist
- [x] Provide a small description of the changes introduced by this PR Add tag prop to use custom html element as radio component wrapper
- [ ] Include links to issues https://jira.dti.ulaval.ca/browse/MODUL-500
- [ ] Openshift deployment requested
@Atiomi, je me demandais dans quel contexte on avait besoin d'un autre tag que le li standard, dans quels cas la liste ne convient pas sémantiquement ?
Le li ne convient pas dans les cas ou le composant est utilisé seul. Oui, idéalement ça ne devrait pas arriver souvent avec un radio, mais dans la vrai vie avec la séparation des contenus en composants c'est possible. C'est déjà le cas dans Brio et ça force à avoir une structure bizarre du genre ul>li>ul>li.
Si on préfère que le composant n’apporte pas de sémantique, le root devrait être un span plutôt qu'un div.
Exact, un <span> serait encore mieux . Par contre faudrait voir tout les impacts, a ce que je vois le radio peut être utilisé dans le radio-group ou un button-group et son affichage change selon le parent (par example la méthode isButton()) . Idéalement un composant devrait indépendant de son parent (ie ne jamais faire getParent()) les this.$parent c'est mal! 📣
https://github.com/pablohpsilva/vuejs-component-style-guide#avoid-thisparent
Exact, un
<span>serait encore mieux . Par contre faudrait voir tout les impacts, a ce que je vois le radio peut être utilisé dans le radio-group ou un button-group et son affichage change selon le parent (par example la méthode isButton()) . Idéalement un composant devrait indépendant de son parent (ie ne jamais faire getParent()) les this.$parent c'est mal! 📣https://github.com/pablohpsilva/vuejs-component-style-guide#avoid-thisparent
Après avoir fait le tour de vos commentaires, j'aurais tendance à dire que le <span> me semble la meilleure approche point de vue sémantique et le plus flexibles pour les différents use cases.
Ça fait 4 versions qu'on repousse ce PR, est-ce qu'on a un concensus avec le span ?
J'ai changé la valeur par défaut pour un span et j'ai géré le cas du radio-group. Ensuite, en ce qui concerne le style guide auquel @chuckmah fait référence, ça semble très intéressant, mais il faudrait recommencer à zéro bcp de chose...
@setur52 lorsque le radio est dans un radio-group, le tag est par défaut un li.
@Atiomi, est-ce que tu pourrais nous donner les cas de la vraie vie où ton radio bouton doit être tout seul. Je n'arrive pas à comprendre comment tu peux justifier ça dans une interface. Normalement, on utilise la case à cocher pour les champs de type "J'accepte les modalités" ou "Recevoir les offres promotionnelles". Un bouton radio seul ne se désélectionne pas, alors c'est pas vraiment recommandé de l'utliser sans ses amis... Merci !
Dans certains contextes comme dans les formulaires de Brio, il est impossible d'utiliser le composant m-radio-group. Il faut donc avoir un alternative à la balise racine <li> du composant m-radio.
Je crois comme @setur52 que le PR ne devrait plus être bloqué.
