# Hydration · Tech watch

[Canonical source](<https://sebastien.rigaux.be/en/tech-watch/tags/hydration>)

Activating server-rendered interfaces on the client and maintaining consistency.

## [React hydration and SSR: prevent mismatches without hiding content](<https://sebastien.rigaux.be/en/tech-watch/links/react-hydration-and-ssr-prevent-mismatches-without-hiding-content>)

In Next.js, a `localStorage` value can make server-rendered HTML differ from the first client render. The article compares the trade-offs: waiting until mount avoids the error but leaves the real content out of the SSR HTML; using the same initial value for both renders preserves that content, though a later update can cause flicker.

To synchronize a sidebar without that flash, an inline script applies its saved state to the DOM before hydration and passes it to React, which uses the same classes. The article also distinguishes an isolated theme control from a mobile backdrop handled with CSS.

2026-11-07 · [Markdown](<https://sebastien.rigaux.be/en/tech-watch/links/react-hydration-and-ssr-prevent-mismatches-without-hiding-content.md>) · [Original resource](<https://www.gmoniava.com/blog/hydration-mismatch-errors-and-how-to-fix-them>)

## [React: preserve progressive enhancement with Server Actions](<https://sebastien.rigaux.be/en/tech-watch/links/react-preserve-progressive-enhancement-with-server-actions>)

React combines `<form action>`, `useActionState`, and `useOptimistic` to handle pending feedback and optimistic updates while keeping form submission available before JavaScript runs. The article shows how this continuity can enhance the interface after hydration without giving up the browser’s native form behavior.

The key is to keep the server action directly in `action`: inserting a client function breaks submission without JavaScript. For optimistic updates, `useHydrated()` lets the form choose between the server action and its client-enhanced version.

2026-11-01 · [Markdown](<https://sebastien.rigaux.be/en/tech-watch/links/react-preserve-progressive-enhancement-with-server-actions.md>) · [Original resource](<https://ebey.dev/blog/3myyseusgd22h>)

## [Vinext 1.4 cuts server work and speeds up hydration](<https://sebastien.rigaux.be/en/tech-watch/links/vinext-14-cuts-server-work-and-speeds-up-hydration>)

Vinext 1.4 reduces work across several rendering stages: App Router layouts run once per request, prefetching dynamic routes no longer renders the entire page, and the chunks needed for hydration can compile in the background in recent Chrome. On the Hacker News benchmark, the author reports 31.1 ms of CPU per request, versus 54.4 ms in 1.3 and 33.7 ms for Next.js.

The release also keeps cached HTML and RSC payload generation in sync. Results still depend on the workload: on a content-site prototype, Next.js paints sooner and uses less CPU per request. A TanStack Redact test shows another trade-off: less JavaScript to download, but substantially more expensive hydration on content-heavy pages.

2026-10-30 · [Markdown](<https://sebastien.rigaux.be/en/tech-watch/links/vinext-14-cuts-server-work-and-speeds-up-hydration.md>) · [Original resource](<https://vinext.dev/blog/vinext-1-4>)

## [TanStack Redact trims React’s browser runtime](<https://sebastien.rigaux.be/en/tech-watch/links/tanstack-redact-trims-reacts-browser-runtime>)

TanStack Redact 0.2.0 replaces React and React DOM in the browser without changing application code. Its stable integrations support TanStack Start, Vite, Vinext, and Next.js; with the latter two, React still handles server rendering while Redact takes over hydration and client rendering.

TanStack’s measurements show bundle reductions from 20.4% to 70.5% across its reference apps, but actual savings vary by project. The tradeoff is explicit: Redact renders synchronously, without React’s time slicing or interruptible rendering. A heavy render can therefore delay input, so compatibility and the busiest screens should be checked in each application.

2026-10-29 · [Markdown](<https://sebastien.rigaux.be/en/tech-watch/links/tanstack-redact-trims-reacts-browser-runtime.md>) · [Original resource](<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: handle themes without flashes or hydration pitfalls](<https://sebastien.rigaux.be/en/tech-watch/links/next-themes-handle-themes-without-flashes-or-hydration-pitfalls>)

next-themes applies the theme as the page loads, respects the system preference, and syncs the choice across tabs. Its `ThemeProvider` works with both the App Router and `pages/`, while a hook lets components switch themes or handle multiple variants.

One architectural detail matters: the browser-stored theme is unavailable during server rendering. UI that depends on `useTheme` should wait until the client component mounts to avoid hydration errors. The library also updates the `<html>` attribute—`suppressHydrationWarning` is recommended—and remains independent of the CSS solution in use.

2026-10-29 · [Markdown](<https://sebastien.rigaux.be/en/tech-watch/links/next-themes-handle-themes-without-flashes-or-hydration-pitfalls.md>) · [Original resource](<https://github.com/pacocoursey/next-themes#readme>)

## [React’s browser() API: rendering components only in the browser](<https://sebastien.rigaux.be/en/tech-watch/links/react-browser-api-rendering-components-only-in-the-browser>)

React Canary introduces the `browser()` API to render a component exclusively in the browser, avoiding hydration mismatches and extra mounted-state logic. The article demonstrates how to use `use(browser())` inside a client component, wrapped in Suspense, to defer rendering until browser APIs are available. Several concrete examples show how this approach enables access to `localStorage`, the DOM, or user-specific data, without the usual workarounds like `useEffect` or environment checks.

2026-10-15 · [Markdown](<https://sebastien.rigaux.be/en/tech-watch/links/react-browser-api-rendering-components-only-in-the-browser.md>) · [Original resource](<https://certificates.dev/blog/reacts-new-browser-api-rendering-components-only-in-the-browser>)