Short version for the impatient: React 19.3 shipped on September 9 and the two things I actually care about, View Transitions and Fragment Refs, are no longer behind the experimental flag. If you want to know why I deleted about 200 lines of animation glue from a client dashboard this week, read on.<\/p>\n
I have a confession. I’ve been shipping There’s more in the release than animations, though. A If you’ve done a fade-in on a conditionally rendered element in React 18, you know the dance. You either reach for a library, or you hand-roll something with a mounted flag, a CSS class, and a That’s not terrible. It’s also a bug factory the moment In 19.3 the same thing is a wrapper and a transition:<\/p>\n The important detail, and the one I got wrong on day one, is that the update has to be a Transition. A plain Default animation is a crossfade. You can pass a class per animation type and write the keyframes in CSS, or hook the One limitation worth saying out loud: this is DOM only. The React team says React Native support is in progress, but if you share components across web and native today, you’ll need a wrapper.<\/p>\n Here’s a thing I didn’t know I needed. Two buttons in a carousel both set Now you tag the transition at the call site:<\/p>\n React also forwards each type to the browser as a view transition type, so you can scope CSS with Wrap a Suspense boundary in The fix is in the docs but easy to skim past:<\/p>\n There’s a second, quieter feature here. Images and fonts inside a This one solves a problem I’ve hit in every design system I’ve worked on. A component renders a list of siblings, no single parent, and you need to observe visibility or move focus across the group. Or the component comes from a library and doesn’t forward its ref. The usual answer is a wrapper In 19.3 you can pass a ref to The instance gives you a curated set of DOM operations: I rebuilt an Every SSR codebase I’ve touched has some version of this:<\/p>\n Or the uglier cousin, On the server it suspends, so the nearest Suspense fallback goes into the HTML. On the client it doesn’t, and the component renders normally after hydration. Because Trusted Types: if your CSP enforces Server Components can render a Context imported from a From the changelog, the one I’d flag: Transitions now render independently instead of being entangled, so a slow Transition no longer blocks unrelated ones. That’s a behaviour change, and if you had code accidentally relying on batching across transitions, test it. There’s also a fix for Upgrade a single leaf route, not the whole app. Find one place where you hand-rolled an exit animation with a timeout, replace it with I’m still not sure about one thing: whether View Transitions will age well once every app crossfades everything. The API makes animation cheap, and cheap things get overused. Use it where motion explains a change. Leave the rest alone.<\/p>\n","protected":false},"excerpt":{"rendered":" React 19.3 makes View Transitions and Fragment Refs stable and adds use(browser()). Before-and-after code for each, plus the Suspense mistake I made first.<\/p>\n","protected":false},"author":2,"featured_media":670,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"React 19.3 makes View Transitions and Fragment Refs stable and adds use(browser()). Before-and-after code for each, plus the Suspense mistake I made first.","rank_math_focus_keyword":"react 19 stable release","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[45,354],"tags":[742,44,41,359,389,741],"class_list":["post-671","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-programming","category-react","tag-fragment-refs","tag-javascript","tag-react","tag-react-19-2","tag-server-components-2","tag-view-transitions"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/671","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=671"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/671\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/670"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=671"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=671"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=671"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}<ViewTransition><\/code> from the experimental channel in one project since early this year, which is the kind of thing I tell clients not to do. I justified it because the alternative was Framer Motion for a single page transition, and that felt like buying a truck to move a chair. So when the React 19.3 release post<\/a> landed with both APIs marked stable, my first reaction wasn’t excitement. It was relief that I could stop pinning a canary build and pretending that was fine.<\/p>\nbrowser()<\/code> API that finally gives “don’t render this on the server” a real name, Trusted Types support, and Server Components that can render a Context directly. I’ll go through what changed, show the before and after for each, and be honest about the parts that still feel rough.<\/p>\nView Transitions: the enter\/exit animation I used to fake<\/h2>\n
setTimeout<\/code> that keeps the element in the DOM long enough for the exit animation to finish. Here’s roughly what mine looked like:<\/p>\n\/\/ React 18: keep the node alive long enough to animate out\nfunction Panel({ open, children }) {\n const [render, setRender] = useState(open);\n useEffect(() => {\n if (open) setRender(true);\n else {\n const t = setTimeout(() => setRender(false), 200);\n return () => clearTimeout(t);\n }\n }, [open]);\n if (!render) return null;\n return <div className={open ? 'panel fade-in' : 'panel fade-out'}>{children}<\/div>;\n}\n<\/code><\/pre>\nopen<\/code> flips twice within 200ms, and every one of these I wrote had a slightly different timeout value because I never bothered to centralise it.<\/p>\n\/\/ React 19.3\nimport { ViewTransition, startTransition, useState } from 'react';\n\nfunction Panel({ open, children }) {\n return open && (\n <ViewTransition>\n <div className="panel">{children}<\/div>\n <\/ViewTransition>\n );\n}\n\n\/\/ wherever you toggle it\nstartTransition(() => setOpen(o => !o));\n<\/code><\/pre>\nsetOpen<\/code> outside startTransition<\/code> is treated as urgent and won’t animate. Updates from useDeferredValue<\/code> and Suspense reveals also count. React then figures out which animation applies: enter, exit, update, or share (a named <ViewTransition><\/code> removed in one place and added in another). Under the hood it’s the browser’s View Transition API<\/a>, so you get the same snapshot-and-crossfade behaviour that vanilla JS gets, just driven by React’s commit phase instead of your own DOM diffing.<\/p>\nonEnter<\/code> \/ onExit<\/code> event props and use the Web Animations API directly. I’ve stuck with CSS classes. It’s less code and my designer can edit them without touching JSX.<\/p>\naddTransitionType and the carousel problem<\/h2>\n
currentSlide<\/code>, but “next” should slide right-to-left and “previous” the other way. Same state update, different animation. Before 19.3 I stored a direction<\/code> in state alongside the slide index, which is one of those pieces of state that exists only for presentation and always felt wrong.<\/p>\nfunction next() {\n startTransition(() => {\n addTransitionType('next');\n setSlide(s => s + 1);\n });\n}\n\n<ViewTransition\n enter={{ next: 'from-right', previous: 'from-left' }}\n exit={{ next: 'to-left', previous: 'to-right' }}\n>\n <Slide \/>\n<\/ViewTransition>\n<\/code><\/pre>\n:active-view-transition-type(next)<\/code> if you’d rather keep the mapping in the stylesheet. I haven’t decided which I prefer. The prop version is more discoverable; the CSS version keeps the component ignorant of animation, which is arguably where that knowledge belongs.<\/p>\nThe Suspense integration is the part that bit me<\/h2>\n
<ViewTransition><\/code> and React animates from the fallback to the loaded content. Great in theory. In practice my first attempt made the whole app feel slower, because everything animated, including content that was already cached and should have popped in instantly. Even the fallback faded in, which is exactly what you don’t want from a loading state.<\/p>\n<ViewTransition update="auto" default="none">\n <Suspense fallback={<Skeleton \/>}>\n <Profile \/>\n <\/Suspense>\n<\/ViewTransition>\n<\/code><\/pre>\ndefault=\"none\"<\/code> turns off enter and exit; update=\"auto\"<\/code> keeps only the fallback-to-content morph. The principle the React team lays out is worth memorising: fallbacks appear immediately, the swap to real content animates, and anything that didn’t suspend appears immediately too. I’d add my own rule. If you can’t explain why a specific animation helps the user understand what changed, it’s decoration, and decoration on a loading path is a tax.<\/p>\n<ViewTransition><Suspense><\/code> pair now trigger Suspense while they load. So a profile card that needs data, an avatar, and a webfont can wait for all three and reveal once, instead of the text landing first and the image flickering in half a second later. I’ve wanted a coordinated reveal like this since roughly 2019 and always ended up with a hand-rolled Promise.all<\/code> and an onLoad<\/code> handler.<\/p>\nFragment Refs: attaching behaviour without a wrapper div<\/h2>\n
<div><\/code>, which then breaks the flex layout you spent an hour on.<\/p>\n<Fragment><\/code> and get a FragmentInstance<\/code> back:<\/p>\nfunction Headings({ posts }) {\n const ref = useRef(null);\n useEffect(() => {\n ref.current.focus(); \/\/ moves focus to the first focusable child, depth first\n }, []);\n return (\n <Fragment ref={ref}>\n {posts.map(p => <Heading key={p.id}>{p.title}<\/Heading>)}\n <\/Fragment>\n );\n}\n<\/code><\/pre>\naddEventListener<\/code> and friends for first-level children, focus<\/code> \/ focusLast<\/code> \/ blur<\/code>, observeUsing<\/code> for an IntersectionObserver or ResizeObserver, and measurement helpers like getClientRects<\/code> and scrollIntoView<\/code>. It is deliberately not a full DOM node. You can’t set innerHTML<\/code> on it, and I think that restraint is correct. The <Fragment><\/code> reference<\/a> has the full list.<\/p>\nInView<\/code> component with it in about twenty minutes. Before, it wrapped children in a <div style=\"display: contents\"><\/code>, which works until you need getBoundingClientRect<\/code> and discover that display: contents<\/code> elements have no box. Now it observes the children directly. Same API for consumers, one fewer lie in the DOM.<\/p>\nbrowser(): the mounted flag finally has a name<\/h2>\n
\/\/ React 18\nfunction LocalTime() {\n const [mounted, setMounted] = useState(false);\n useEffect(() => setMounted(true), []);\n if (!mounted) return null;\n return <p>{new Intl.DateTimeFormat().resolvedOptions().timeZone}<\/p>;\n}\n<\/code><\/pre>\ntypeof window !== 'undefined'<\/code>, which causes hydration mismatches the moment you forget that the server and first client render must agree. React 19.3 replaces both with use(browser())<\/code> from react-dom<\/code>:<\/p>\nimport { use } from 'react';\nimport { browser } from 'react-dom';\n\nfunction LocalTime() {\n use(browser());\n return <p>{new Intl.DateTimeFormat().resolvedOptions().timeZone}<\/p>;\n}\n<\/code><\/pre>\nuse<\/code> can sit behind a condition, you can opt out only when you lack a default value, or only when a data hook has no initialData<\/code>. That last pattern, wrapping useQuery<\/code> so it renders on the server when the loader passed data and defers otherwise, is the cleanest solution to the “should this fetch on the server or not” question I’ve seen. I covered a related idea when I wrote about useOptimistic<\/code> and the spinner I finally deleted<\/a>; this is the same spirit of replacing ad hoc state with something React understands.<\/p>\nThe smaller changes I’d actually check before upgrading<\/h2>\n
require-trusted-types-for 'script'<\/code>, React previously coerced everything to a string before handing it to the DOM, which turned your TrustedHTML<\/code> objects back into plain strings the browser rejected. 19.3 passes them through untouched. If you’ve been holding off on that CSP directive because React fought it, that blocker is gone.<\/p>\n'use client'<\/code> module directly, without a Provider<\/code> wrapper component whose only job was to forward a prop. Small, but I have maybe eight of those wrappers in one app and they all get deleted.<\/p>\nuseDeferredValue<\/code> getting stuck on a stale value, which explains a bug I’d blamed on my own code for a month.<\/p>\nWhat I’d do this week<\/h2>\n
<ViewTransition><\/code> inside startTransition<\/code>, and check that it still works when the user double-clicks. Then grep for setMounted(true)<\/code> and try use(browser())<\/code> on one of them. If either feels worse, you’ve lost an hour. If they feel better, you’ve probably got a dozen more to convert, and that’s a job I’ve done for a few clients already; details of that kind of work are on my portfolio<\/a>.<\/p>\n