Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problème d'hydratation React du composant Card #253

Open
pom421 opened this issue Apr 22, 2024 · 1 comment
Open

Problème d'hydratation React du composant Card #253

pom421 opened this issue Apr 22, 2024 · 1 comment

Comments

@pom421
Copy link
Contributor

pom421 commented Apr 22, 2024

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 desc dans 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, detail et endDetail ?

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.

@enguerranws
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants