Get CV
Back to business cases

React

React that hydrated Vue markup

The catalog was Vue SSR. A shared island ran React. Dates disagreed. The page painted twice and shipped the CMS graph.

Public pages used Vue SSR. The editor wanted React tables. One webpack graph mounted a React root on a node Vue had already printed. The server date was UTC. React formatted local time in Berlin. Hydration failed. The catalog flashed and downloaded the admin chunk.

TTI on a phone jumped. The visitor never opened CMS. They paid for it in bytes and in a second paint.

The problem was two frameworks owning one tree. Shoppers got a flash and a CMS bundle they did not need. I needed Vue SSR on public, React on /admin, and one Sanctum cookie, never a token in localStorage.

Vue printed the HTML. React tried to own the same nodes. The trees did not match.
Vue printed the HTML. React tried to own the same nodes. The trees did not match.

Two builds

Public stays Vue SSR. Admin is a second Vite app on /admin. Both use the Sanctum cookie auth_token. No token in localStorage. Shared code is fetch types, not a table component. nginx caches public HTML without the React graph.

Two bundles, one cookie. Public hydrates with Vue. Admin loads React after login.
Two bundles, one cookie. Public hydrates with Vue. Admin loads React after login.

What we measured

The listing script dropped by most of the CMS vendor. Hydration warnings on dates went to zero because React no longer ran on that tree. The Vue hydration date case on this site is the same class of bug without a second framework. Adding React on the same root made it louder, not different.

What I took from this

One root, two frameworks, is a hydration failure with extra bytes. Split the apps at the URL.

Admin vendor does not belong on the catalog. TTI on a phone made that obvious.

auth_token stays in an httpOnly cookie. Sharing a table component was not worth sharing a hydrate tree.

Back to business cases