# Hydration · Veille technologique

[Source canonique](<https://sebastien.rigaux.be/veille/tags/hydration>)

Activation côté client d’interfaces rendues sur le serveur et gestion de leur cohérence.

## [Hydratation React et SSR : éviter les écarts sans masquer le contenu](<https://sebastien.rigaux.be/veille/liens/hydratation-react-et-ssr-eviter-les-ecarts-sans-masquer-le-contenu>)

Dans Next.js, une valeur de `localStorage` peut faire diverger le HTML rendu côté serveur du premier rendu client. L’article compare les compromis : attendre le montage évite l’erreur, mais retire le contenu réel du HTML SSR ; initialiser les deux rendus avec la même valeur préserve ce contenu, au prix d’une mise à jour ultérieure pouvant provoquer un flicker.

Pour synchroniser une sidebar sans ce clignotement, un script inline applique son état au DOM avant l’hydratation et le transmet à React, qui reprend les mêmes classes. L’article distingue aussi le cas d’un contrôle de thème isolé et celui d’un backdrop mobile géré par CSS.

2026-11-07 · [Markdown](<https://sebastien.rigaux.be/veille/liens/hydratation-react-et-ssr-eviter-les-ecarts-sans-masquer-le-contenu.md>) · [Ressource originale](<https://www.gmoniava.com/blog/hydration-mismatch-errors-and-how-to-fix-them>)

## [React : préserver le progressive enhancement des Server Actions](<https://sebastien.rigaux.be/veille/liens/react-preserver-le-progressive-enhancement-des-server-actions>)

React combine `<form action>`, `useActionState` et `useOptimistic` pour gérer les retours d’attente et les mises à jour optimistes tout en conservant un envoi de formulaire avant l’exécution de JavaScript. L’article montre comment cette continuité permet d’enrichir l’interface après hydratation sans abandonner le comportement natif du navigateur.

Le point décisif est de garder l’action serveur directement dans `action` : une fonction cliente intermédiaire casse la soumission sans JavaScript. Pour l’optimisme, `useHydrated()` permet de choisir entre l’action serveur et sa version enrichie côté client.

2026-11-01 · [Markdown](<https://sebastien.rigaux.be/veille/liens/react-preserver-le-progressive-enhancement-des-server-actions.md>) · [Ressource originale](<https://ebey.dev/blog/3myyseusgd22h>)

## [Vinext 1.4 : moins de travail serveur et une hydratation plus rapide](<https://sebastien.rigaux.be/veille/liens/vinext-14-moins-de-travail-serveur-et-une-hydratation-plus-rapide>)

Vinext 1.4 réduit le travail à plusieurs étapes du rendu : les layouts App Router s’exécutent une seule fois par requête, le prefetch des routes dynamiques ne génère plus la page entière et les chunks nécessaires à l’hydratation se compilent en arrière-plan dans Chrome récent. Sur le benchmark Hacker News, l’éditeur mesure 31,1 ms de CPU par requête, contre 54,4 ms en 1.3 et 33,7 ms pour Next.js.

La version synchronise aussi la génération du HTML et du payload RSC en cache. Les résultats restent toutefois dépendants du scénario : sur un prototype de site éditorial, Next.js peint plus vite et consomme moins de CPU par requête. Le test de TanStack Redact révèle un autre compromis : moins de JavaScript téléchargé, mais une hydratation nettement plus coûteuse sur les pages chargées.

2026-10-30 · [Markdown](<https://sebastien.rigaux.be/veille/liens/vinext-14-moins-de-travail-serveur-et-une-hydratation-plus-rapide.md>) · [Ressource originale](<https://vinext.dev/blog/vinext-1-4>)

## [TanStack Redact réduit le runtime client de React](<https://sebastien.rigaux.be/veille/liens/tanstack-redact-reduit-le-runtime-client-de-react>)

TanStack Redact 0.2.0 remplace React et React DOM dans le navigateur sans modifier le code de l’application. Ses intégrations stables couvrent TanStack Start, Vite, Vinext et Next.js ; dans ces deux derniers frameworks, React reste chargé du rendu serveur tandis que Redact gère l’hydratation et le rendu client.

Les mesures fournies par TanStack montrent des réductions de bundle allant de 20,4 % à 70,5 % sur leurs applications de référence, mais ces gains varient selon le projet. Le compromis est concret : Redact rend de façon synchrone, sans time slicing ni rendu interruptible de React. Un rendu lourd peut donc retarder les interactions ; la compatibilité et les écrans les plus chargés méritent d’être vérifiés dans chaque application.

2026-10-29 · [Markdown](<https://sebastien.rigaux.be/veille/liens/tanstack-redact-reduit-le-runtime-client-de-react.md>) · [Ressource originale](<https://tanstack.com/blog/introducing-tanstack-redact?ck_subscriber_id=2550494205&utm_source=convertkit&utm_medium=email&utm_campaign=%E2%9A%9B%EF%B8%8F%20This%20Week%20In%20React%20%23303%3A%20TanStack%2C%20Next.js%2C%20Vinext%2C%20Motion%2C%20React%20Hook%20Form%20%7C%20Expo%20Desktop%2C%20Legend%20Spark%2C%20Nitro%2C%20Exact%2C%20Skia%2C%20Screens%2C%20Unistyles%20%7C%20Node.js%2C%20Bun%2C%20SWC%2C%20Content%20Mappers%2C%20pnpm%2C%20Biome%20-%2023928066>)

## [next-themes : gérer les thèmes sans flash ni piège d’hydratation](<https://sebastien.rigaux.be/veille/liens/next-themes-gerer-les-themes-sans-flash-ni-piege-dhydratation>)

next-themes applique le thème dès le chargement, prend en compte la préférence système et synchronise le choix entre les onglets. Son `ThemeProvider` fonctionne avec l’App Router comme avec `pages/`, et expose un hook pour changer de thème ou gérer plusieurs variantes.

Le point à intégrer dans l’architecture : le thème stocké dans le navigateur est inconnu au rendu serveur. L’interface qui dépend de `useTheme` doit donc attendre le montage côté client pour éviter les erreurs d’hydratation. La bibliothèque met aussi à jour l’attribut de `<html>` — avec `suppressHydrationWarning` recommandé — et reste indépendante de la solution CSS utilisée.

2026-10-29 · [Markdown](<https://sebastien.rigaux.be/veille/liens/next-themes-gerer-les-themes-sans-flash-ni-piege-dhydratation.md>) · [Ressource originale](<https://github.com/pacocoursey/next-themes#readme>)

## [React : l’API browser() pour rendre un composant uniquement côté navigateur](<https://sebastien.rigaux.be/veille/liens/react-api-browser-pour-rendre-un-composant-uniquement-cote-navigateur>)

React Canary introduit l’API `browser()` pour rendre un composant exclusivement dans le navigateur, sans risque de mismatch à l’hydratation ni effet de montage supplémentaire. L’article montre comment placer `use(browser())` dans un composant client, entouré d’une Suspense, pour différer son rendu jusqu’à ce que les APIs du navigateur soient disponibles. Plusieurs exemples concrets illustrent l’intérêt de cette approche pour accéder à `localStorage`, au DOM ou à des données spécifiques à l’utilisateur, tout en évitant les contournements habituels avec `useEffect` ou des vérifications de l’environnement.

2026-10-15 · [Markdown](<https://sebastien.rigaux.be/veille/liens/react-api-browser-pour-rendre-un-composant-uniquement-cote-navigateur.md>) · [Ressource originale](<https://certificates.dev/blog/reacts-new-browser-api-rendering-components-only-in-the-browser>)