Sébastien Rigaux

Veille technologique

← Tous les liens

SSR

Production du HTML sur le serveur et articulation avec les données et interactions côté client.

Carte blanche sur fond bleu pâle affichant « Fixing a Hydration Mismatch Error and UI Flicker in React » et la mention « Blog ».

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.

Giorgi MoniavaRepéré via React Digest

Aperçu GitHub du dépôt shader-effects-inc/shaders, présenté comme une bibliothèque de composants WebGPU pour React, Vue, Svelte, Solid, JavaScript et Framer.

L’expérience de projection React pilotée par l’IA de Tanner Linsley est devenue un projet TanStack utilisé en production. Redact propose un runtime plus léger, compatible avec React et déjà fonctionnel avec Start, Next.js, Vinext et Vite. Côté serveur, React continue de gérer le SSR et les Server Components.

Le compromis se situe dans le rendu : Redact travaille de façon synchrone, sans le time slicing de React. Comme le reconnaît le billet, un rendu lourd peut encore retarder les interactions. Le gain de légèreté s’accompagne donc d’une limite à prendre en compte pour les interfaces exigeantes en réactivité.

Shader Effects, Inc.Repéré via This week in React

Bannière blanche avec le texte noir « Next Themes » et les icônes GitHub et de sponsor.

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.

Visuel de la page de changelog c15t affichant le logo c15t et le numéro de version 3.0.0 sur fond noir.

c15t 3 refond sa gestion du consentement autour d’un moteur commun, décliné pour Next.js, React, Vue, Nuxt, Astro, Svelte, TanStack Start et les sites HTML. Les bannières peuvent être rendues dans le HTML serveur, tandis qu’un manifest de consentement évite d’attendre le backend à chaque requête ; les gains mesurés dépendent toutefois du mode de déploiement et du benchmark présenté par l’éditeur.

La migration conserve les choix enregistrés en v2, mais introduit des breaking changes dans les API, les packages et le backend. Des codemods couvrent une partie du travail ; clients et backend doivent être mis à niveau ensemble. La version ajoute aussi des règles de politique plus strictement validées et un backend auto-hébergé compatible PostgreSQL, MySQL et SQLite.

Inth

Capture d’écran de la page de release vinext 1.1.0 sur GitHub

La version 1.1.0 de vinext, le plugin Vite qui réimplémente l’API Next.js, aligne de nombreux comportements sur Next.js, notamment pour l’App Router (gestion des redirections, métadonnées, erreurs spéciales) et la gestion du cache. Cette release introduit la stratégie stale-while-revalidate pour use cache, permettant de servir des entrées périmées tout en les régénérant en arrière-plan, et corrige plusieurs incohérences de cache et de rendu côté serveur. Un jalon pour ceux qui cherchent une alternative déployable à Next.js.

github-actions

Affiche de la sortie stable de TanStack Start 1.0

TanStack Start 1.0 officialise un framework full-stack stable, déjà éprouvé en production, qui combine le routage SPA, le rendu serveur, le streaming et des fonctions serveur typées pour React et Solid. L’accent est mis sur la sécurité de typage de bout en bout : les paramètres de routes, les loaders et les fonctions serveur sont tous typés, ce qui facilite la maintenance et l’évolution, même pour les agents IA. Le support de React Server Components est optionnel, et le déploiement s’appuie sur Vite, Nitro ou Rsbuild, sans imposer une architecture unique.

Tanner Linsley

Illustration de l’article sur l’API browser() de React sur certificates.dev

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.

Aurora Scharff