Le contexte React ne traverse pas la frontière d'un îlot

Un composant à parties — accordéon, popover, onglets — partage son état par un contexte React. Écrit dans un fichier .astro, avec la directive d’hydratation sur la racine, il lève une erreur au build : les parties ne trouvent pas le contexte de leur racine.

1. Voir ce qu’une directive délimite

client:load ne rend pas la page réactive : elle déclare un îlot, dont la racine est le composant qui porte la directive. Les enfants écrits dans le .astro sont rendus par Astro, au build, hors de cet arbre React. Ils ne descendent donc d’aucun fournisseur de contexte — il n’y a pas d’arbre commun où le chercher.

2. Assembler du côté React

L’assemblage se met dans un seul fichier .tsx : la racine et ses parties y sont un arbre React, et c’est ce fichier qui porte la directive. La page ne voit plus qu’un composant.

3. Ne passer que des données sérialisables

Les propriétés d’un îlot traversent la frontière en JSON. Un tableau d’objets {label, value} passe ; une fonction de rendu, non. La contrainte est bienvenue : elle pousse l’assemblage vers le fichier React et les données vers la page.

4. Refuser l’îlot quand un élément natif suffit

La règle inverse compte autant. Un panneau qui s’ouvre et se ferme est un <details> : il n’a besoin d’aucun script, reste dans le HTML livré, et s’imprime déplié. Un popover, lui, se positionne, se ferme au clic extérieur et annonce son état — trois comportements qu’aucun élément natif ne rend. On paie une racine React pour un comportement, jamais pour l’uniformité.