React browser() : où accepter un rendu réservé au navigateur ?

Une équipe prépare une nouvelle vue dans une application React. Une partie de l’écran présente des informations utiles dès l’ouverture ; un composant complémentaire dépend, lui, de données ou de capacités disponibles dans le navigateur. Faut-il réserver toute la page au rendu côté navigateur, isoler seulement ce composant, ou conserver le rendu côté serveur et revoir la dépendance ? La réponse se décide d’abord à partir de l’usage, pas du nom d’une API.

Le contexte technique à vérifier est précis : l’article d’InfoQ intitulé « React 19.3: Adds a browser() API, Giving Client-Only Rendering a First-Class Name » présente browser() comme une API de react-dom permettant d’exclure des composants du rendu côté serveur.

L’article évoque notamment des composants dépendants du navigateur et des écarts d’hydratation. Ces éléments résument la source disponible ; ils ne remplacent pas la vérification de la documentation React correspondant à la version et à l’architecture de votre projet.

Un cas fictif : une vue métier avec une dépendance locale

Imaginons une PME qui fait évoluer un portail interne. Les utilisateurs doivent consulter une fiche de dossier, puis ouvrir un outil interactif complémentaire qui dépend d’une donnée obtenue dans leur navigateur. Ce scénario est hypothétique : il ne décrit ni un client réel ni un résultat mesuré. Il sert à clarifier la décision avant de modifier le rendu.

La première question est fonctionnelle : que doit pouvoir faire la personne dès l’arrivée sur la page ? Si elle doit lire une synthèse, retrouver un dossier ou comprendre son état sans attendre l’exécution dans le navigateur, rendre toute la vue dépendante de celui-ci peut retarder l’accès à l’information ou compliquer le parcours. Si l’essentiel de la page est lui-même indissociable de capacités du navigateur, cette contrainte peut être acceptable, à condition de la traiter explicitement dans la conception.

Il faut ensuite isoler la dépendance. « Le composant utilise le navigateur » n’est pas encore une justification suffisante : l’équipe doit nommer la donnée ou la capacité concernée, son propriétaire, le moment où elle est disponible et le comportement attendu lorsqu’elle manque. Un rendu réservé au navigateur peut éviter d’exécuter côté serveur une partie qui ne peut pas y fonctionner ; il ne résout pas, à lui seul, les questions de contenu initial, de chargement, d’erreur ou de qualité des données.

Comparer les options à partir du parcours attendu

Cette comparaison n’établit pas qu’une option est toujours préférable. La portée du rendu réservé au navigateur doit être la plus petite qui satisfasse le besoin démontré, sauf raison documentée d’élargir le périmètre. Les effets sur le référencement, l’accessibilité et le chargement dépendent de la page et de son implémentation : ils doivent être vérifiés pour le parcours concerné, pas déduits du seul choix d’API.

Une chronologie pour décider sans transformer l’essai en engagement

1. Décrire la tâche métier. Notez ce que la personne vient consulter ou accomplir, ce qui doit être visible immédiatement et ce qui peut attendre. Cette description devient le point de référence de la décision.

2. Cartographier la dépendance. Précisez quelle donnée ou capacité exige le navigateur, qui la fournit, quand elle est disponible et ce que l’application doit faire en cas d’absence ou d’échec. Distinguez cette dépendance du reste de la page.

3. Comparer les trois périmètres. Examinez le maintien du rendu côté serveur, l’isolement du seul composant concerné et le rendu navigateur d’une partie plus large. Pour chaque option, consignez le parcours utilisateur, les impacts prévisibles sur le contenu initial et les responsabilités de mise en œuvre.

4. Essayer sur une vue circonscrite. Avant d’étendre le choix, définissez un scénario de validation représentatif, les personnes qui le vérifient et les conditions qui conduisent à poursuivre, ajuster ou abandonner. Il s’agit d’un essai à réaliser, pas d’un résultat déjà acquis.

5. Faire valider et documenter. Le responsable métier confirme le parcours ; l’équipe technique consigne la limite retenue, les états de repli et les vérifications nécessaires. Une évolution ultérieure doit pouvoir réexaminer cette décision sans dépendre de souvenirs informels.

Les critères à inscrire dans le cadrage

Pour rendre la comparaison exploitable entre métier, équipe de développement et prestataire, demandez des réponses vérifiables plutôt qu’une simple recommandation d’API. Un cadrage de projet informatique peut aussi préciser les exigences et critères d’acceptation dans un cahier des charges informatique utile.

• Quel contenu doit être accessible avant l’exécution du code dans le navigateur, et pourquoi ?

• Quelle dépendance justifie le rendu navigateur-only, et quelle partie de la page en a réellement besoin ?

• Que voit l’utilisateur pendant le chargement, lorsque la donnée manque ou si le composant échoue ?

• Quels scénarios de recette couvrent l’affichage initial, les interactions principales, les erreurs et le retour à un état compréhensible ?

• Qui possède la donnée ou le service utilisé, qui prend en charge les incidents et comment la décision sera-t-elle revue si le parcours évolue ?

• Quelle documentation et quels tests seront remis pour permettre à une autre personne de maintenir le composant ?

Les contrats d’échange et les responsabilités autour des interfaces comptent aussi lorsque la donnée provient d’un service distinct ; les principes d’une API maintenable peuvent aider à cadrer ce volet sans confondre architecture de rendu et contrat d’API.

Le point de décision

Pour le cas fictif, la décision raisonnable n’est pas de choisir browser() par principe : elle consiste à établir si la dépendance est localisée et si le reste de la vue conserve une utilité immédiate. Si oui, l’équipe peut évaluer un périmètre limité et le valider sur des critères définis à l’avance. Si la page entière dépend du navigateur, elle doit expliquer ce choix dans le cadrage et accepter d’en examiner les conséquences sur le parcours, le contenu initial et la maintenance.

La source disponible ne suffit pas à confirmer la disponibilité, la syntaxe exacte ou les conditions d’usage de l’API pour votre version de React. Avant toute mise en œuvre, vérifiez ces points dans la documentation officielle correspondant à votre environnement. La décision finale doit associer une justification métier, une frontière technique explicite et des critères de recette observables.