Introduction to React 19: Ecosystem Updates (Router, Redux, Next.js, etc.)

Bookmark

React 19’s release had a ripple effect across the React ecosystem. Here are major updates from popular libraries and frameworks to ensure compatibility and to leverage new features:

• React Router: The React Router team has been closely aligned with React’s evolution, especially with the introduction of data APIs and nested routing influenced by Remix. With React 19, React Router v6.14+ (and the upcoming v7) introduced a mode to “bridge the gap from React 18 to React 19” (React Router Home | React Router) (React Router Home | React Router). Practically, this means Router can run in two modes:

  • A “Data Router” mode that fully embraces React 19 features (streaming, use of <Suspense> for lazy-loaded routes, integrating with use for loading data, etc.).
  • A fallback mode to support React 18 behavior.

  They provided “future flags” to gradually adopt React 19 features without breaking an existing app. For example, React Router added support for React’s <Suspense> in routing (for code-splitting) and improved its <Await> component for Suspense boundaries. It also has a <Meta> component in v6.14 which serves a purpose similar to React 19’s <title>/<meta> hoisting, ensuring meta tags can be managed via router config or components (React Router Home | React Router) (React Router Home | React Router). If you use Router’s data APIs, you might find overlap with React 19’s Actions – Router has its own concept of route “actions” (for handling form submissions on specific routes) which is a bit different. In fact, you could theoretically use both: React Router’s <Form> will call your route action, which could in turn use a React server action. However, it’s more likely you’d choose one approach per form to avoid confusion.

  The Router docs acknowledge that React Router is now a “multi-strategy router” – meaning it can act like a framework (with loaders/actions akin to Remix) or just as a client-side router, depending on how you use it (React Router Home | React Router). With React 19 available, Router encourages moving to their data APIs which integrate nicely with Suspense and concurrent features. Router v7 (Remix v2) will likely use React 19’s capabilities by default and drop some backward compatibility. If you’re upgrading to React 19 and using React Router, be sure to update to the latest Router version. There were some minor changes (for instance, Router’s unstable_useBlocker hook usage might have been refined for StrictMode, etc., and type updates for React 19).

• Redux / Redux Toolkit: Redux as a state management library works fine with React 19 – the core concepts are unchanged by React updates. However, the Redux team used the React 19 launch as an opportunity to modernize. Redux Toolkit 2.0 and Redux Core 5.0 were released around the same time (Migrating to RTK 2.0 and Redux 5.0 | Redux Toolkit). These updates were mostly about cleaning up legacy APIs (much like React did):

  • Redux 5.0 removed some deprecated middleware signatures and old APIs like combineReducers default behavior tweaks (nothing drastic for most).
  • React-Redux (the binding library) v9.0+ added support for React 18’s features and v9.1/v9.2 included adjustments for React 19 (like using the new useSyncExternalStore under the hood and ensuring compatibility with new React types) (Releases · reduxjs/react-redux · GitHub) (Releases · reduxjs/react-redux · GitHub). A notable fix was removing an unnecessary React Native peer dependency which became problematic when React 18.3 came out (since React Native was still on 18.2 at that moment) (Releases · reduxjs/react-redux · GitHub) (Releases · reduxjs/react-redux · GitHub). React-Redux v9.2 declares support for React 19 officially (though earlier versions likely work too).
  • Redux Toolkit’s createAsyncThunk etc., continue to function as is. RTK 2.0 dropped support for older JS runtimes (targeting ES2015+), but that’s unrelated to React 19 – just be aware if you maintain older browsers without transpilation.

  Using Redux with React 19’s new features: You might wonder, do Actions and Server Components reduce the need for Redux? It’s a topic of debate. Actions handle a narrow scope (form submissions and mutations), whereas Redux is a general client-side state container. Many apps will continue to use Redux for global state or complex state logic. If anything, the presence of useOptimistic and server actions could simplify some Redux usage (for example, instead of dispatching a half-dozen actions for optimistic updates and tracking loading state, a local component state via useOptimistic might suffice). However, Redux Toolkit also introduced its own fetchBaseQuery and RTK Query for data fetching, which competes somewhat with React’s data fetching strategies. It’s likely developers will choose either a Redux-centric data flow or a React 19-centric flow on a per-feature basis. The good news is they are not mutually exclusive – you can still dispatch Redux actions inside a React server action, for instance, if you wanted to use Redux on the server (though that’s unusual).

  In community discussions, some pointed out that with React 19, you might not need Redux for simple form state at all, since useActionState can manage it. But Redux remains valuable for broader app state (e.g., caching data, user authentication state, etc.). The key update is simply: upgrade your react-redux to latest when moving to React 19, to avoid any type mismatches or warnings. Mark Erikson (Redux maintainer) has indicated they tested with React 19 RC and everything is compatible.

• Next.js: Next.js had one of the biggest alignments with React 19:

  • Next.js 15 was released in October 2024 specifically to add support for React 19 RC and prepare users for React 19 GA (Next.js 15 | Next.js) (Next.js 15 | Next.js). They even shipped Next 15 before React 19 was final, because they were confident in the RC after working closely with React Core. Next 15’s App Router requires React 19 (to use Server Components and Actions), while the older Pages Router can still run on React 18 for now (Next.js 15 | Next.js) (Next.js 15 | Next.js). This meant Next 15 was a transitional release: you could run part of your app on React 18 (pages) and part on React 19 (app), although that’s not recommended (Next.js 15 | Next.js) (Next.js 15 | Next.js).
  • Next.js 15.1 and above made React 19 the default. By Next 15.2 (hypothetical if out), everyone is expected to be on React 19 as it’s stable.
  • Next.js integrated React 19’s Actions into their framework as Server Actions. In the Next 13 App Router, you could already do forms with an action. Next 15 improved the security of these (making the endpoints unguessable and stripping out unused server functions from the client bundle) (Next.js 15 | Next.js) (Next.js 15 | Next.js). So if you’re using Next, upgrading to 15 and React 19 gives you production-ready Server Actions. This allows simpler forms in your Next app – e.g., a basic contact form can be just a React component with an action function, no API route needed.
  • Next 15 also touted “Async Request APIs (Breaking)” which is part of their effort to simplify and unify how fetching and mutations are done (closely tied to RSC). They tweaked caching behavior of fetch and introduced things like next/form (an enhanced form component that uses client-side navigation after submission, to combine SPA feel with server actions) (Next.js 15 | Next.js) (Next.js 15 | Next.js).
  • There were also improvements to the development server and error overlay: “improved error debugging”, static route indicators (to show what’s purely static vs server-rendered), and support for React 19’s hydration error messages.
  • Turbopack (the new bundler) reached stable for dev in Next 15, which may indirectly benefit from React 19’s ESM emphasis (no UMDs to worry about).

  Next.js Conf 2024 even had sessions on how React 19 and Next 15 work together. If you’re a Next.js developer, the key is to read the Next 15 migration guide. It addresses things like: ensure you don’t mix React versions, update any usage of next’s experimental features to their new counterparts, etc. For most, the biggest changes were adopting the new forms and ensuring all dependencies are compatible. Next’s codemod CLI can automatically handle a lot of renames and package updates (Next.js 15 | Next.js).

  One example of Next 15 + React 19 synergy: With React 19’s <title> and <meta> support, Next 15’s <Head> component could be simplified. In fact, you might not even need <Head> for basic cases – you can directly put <title> in your page component and it will end up in the document head (React v19 – React). Next 13 had added a Metadata API for pages, but React 19 maybe offers a more straightforward approach for those who want it.

• Other Frameworks:

  • Gatsby: Gatsby v5 (released late 2022) was on React 18. Gatsby’s architecture (being an SSG) doesn’t leverage RSC or Actions at the moment. However, they likely updated their internal utils to remove deprecated usage. Gatsby announced experimental React 19 support in early 2025, mostly ensuring their link prefetching continues to work with React’s new preloading APIs (maybe they can remove some code because React handles more natively). Gatsby users should update gatsby and related plugins to the latest if moving to React 19.
  • Remix: Remix v2, which essentially merged with React Router v7, is all about compatibility with React 18/19. If you run a Remix app, upgrading to React 19 should be straightforward – just bump the React version. Remix’s own features (like actions and loaders) continue to work; eventually, they might allow using React’s native actions instead of their implementation, but as of React 19, Remix is likely still using its own.
  • React Native: While React Native is a separate ecosystem, it uses React core. React Native has to officially add support for React 19 (usually via a minor version bump of React Native that includes the new renderer changes). As of early 2025, React Native 0.72+ was on React 18. Upgrading RN to use React 19 might come in RN 0.75 or so. This doesn’t impact web devs directly, but if you do cross-platform, be mindful that React 19’s new APIs like useOptimistic etc. should work in RN as soon as the RN version supports React 19. The React team coordinating with RN was evident in that React-Redux peer dep issue we saw – RN 0.74 sticking to React 18.2 while React 18.3 was out caused some version juggling (Releases · reduxjs/react-redux · GitHub). Expect RN to catch up once they ensure nothing in the native renderer (Fabric) is broken by the React 19 changes (especially the removal of some internals).
  • React Query / TanStack Query: Libraries like React Query typically just work, but they may have minor updates. React Query doesn’t use any React internals, so it likely worked day one. However, with React 19’s use and useActionState, some of the data fetching and mutation patterns can be done without an external library. Still, React Query provides caching and deduping that React’s built-ins don’t cover end-to-end. The ecosystem will adjust – perhaps we’ll see React Query integrate with the new prefetch APIs (e.g., call preload() for certain queries automatically).

• Community Libraries: It’s always wise to check your dependencies for React 19 compatibility:

  • Component libraries (MUI, Ant Design, Chakra UI, etc.) – most of these were compatible; they might issue a minor release to drop PropTypes or update peer dep ranges to include 19. E.g., MUI v5 works fine, you might see a console warning about PropTypes if not removed, but it won't break.
  • State libraries (MobX, Zustand, Recoil) – generally fine. MobX might warn if using legacy stuff but new versions are good. Zustand and others use modern APIs (like useSyncExternalStore) which are unchanged in 19.
  • Form libraries (Formik, React Hook Form) – ironically, React 19’s new form features overlap with these. They all still function, though you might not need them for simple cases. React Hook Form’s author even blogged comparing using RHF vs. React 19 actions for forms. It comes down to whether you need client-side validation and complex form logic – RHF is still great for that, whereas React’s Actions shine for simple “send data to server” forms. Technically, no breaking changes should hit these libraries either, aside from them possibly updating peer deps.

Conclusion

In short, the React ecosystem was quick to embrace React 19. Next.js and React Router led the charge to fully support (and require) it to unlock their next-gen features. Redux family caught up with mostly under-the-hood changes. Most other libraries only needed minor tweaks, if any. The key advice is: update your libs when you update React. Many issued releases marked “compat with React 19” around late 2024. If a library you use hasn’t been updated in a long time (and was using React internals), you might need to find a maintained fork or alternative.

One notable mention: community tools like ESLint and TypeScript – ensure you update eslint-plugin-react if needed (it might have new rules for React 19, e.g., no string refs, etc.), and update @types/react. The new types will help catch any straggling usage of removed APIs at compile time.

---