enguerranws
commented
2 months ago Edit: je vois, les exemples du DSFR ne comportent que des p pour la partie description p. ex. et React DSFR a respecté ça. Je me demande si ça ne vaut pas le coup de légèrement dévier du DSFR pour ce cas car sinon, ça rend le composant Card inutilisable pour des composants relativement complexes.
C'est une bonne question. On y est souvent confronté. Le truc c'est que justement, côté DSFR, je pense que c'est intentionnel de ne pas avoir de contenus trop complexes en description de Carte, cette description doit rester une description, donc un petit texte (et pour le coup, la balise p s'y prête bien).
Le risque s'y on autorise ça, c'est d'avoir des implémentions du DSFR qui s'éloignent de ce pourquoi le composant a été designé, et perdent aussi certains bénéfices (tests d'accessibilité, etc).
Il faudrait voir ce que tu entends par "contenu complexe" : si c'est un cas légitime, on peut se dire que ouais, ça aurait de l'intérêt de le mettre à dispo des utilisateurs de la lib, si c'est un cas très spécifique (qui sort du cadre de l'utilisation du composant tel que le DSFR l'a prévu), ce serait moins évident.
Hello,
Quand on utilise le composant Card avec un contenu complexe, une erreur d'hydratation React apparaît dans Next (j'utilise Next 14). Next passe du coup en client side rendering et on perd le bénéfice des composants serveurs.
Le problème semble provenir du fait que le composant Card wrap le contenu de la prop
descdans un p. Or HTML ne permet pas de mettre des div dans des p. Du coup, il y une désynchro entre ce que Node rend en corrigeant le HTML a sa façon et ce que le browser rend en le corrigeant à la sienne.Est-ce délibéré de wrap dans un p les props
desc,detailetendDetail?Edit: je vois, les exemples du DSFR ne comportent que des p pour la partie description p. ex. et React DSFR a respecté ça. Je me demande si ça ne vaut pas le coup de légèrement dévier du DSFR pour ce cas car sinon, ça rend le composant Card inutilisable pour des composants relativement complexes.