React 19 for developers

Read the React 19 additions together and a theme emerges. A great deal of what every application built by hand — pending states, optimistic updates, form submission handling, error boundaries around async work — is being absorbed into the framework.

This matters more than any individual API. It means code you wrote to manage loading flags and race conditions is becoming unnecessary, and the idiomatic way to express those flows is changing. Familiarity with the old patterns is still useful for reading existing code; writing new code the old way will increasingly look dated.

The Actions model gives async operations first-class treatment. Instead of manually tracking whether a submission is in flight, whether it failed and what to show meanwhile, that state is managed for you and exposed through hooks designed for it.

The practical benefit is fewer bugs in the category everyone gets wrong: double submissions, stale responses arriving after newer ones, error states that persist after a successful retry. These were always solvable and almost never solved consistently across a codebase.

• Pending state managed rather than tracked by hand
• Optimistic updates with a defined path back on failure
• Form submission flows that do not need a bespoke wrapper
• Fewer race conditions from concurrent submissions

Reading a promise or context with use changes how data flows into components, because it can be called conditionally — which every previous hook could not. That single relaxation removes a class of awkward restructuring that existed purely to satisfy the rules of hooks.

It works together with Suspense rather than replacing your data layer. The mental model worth building is that the component declares what it needs and the boundary above decides what to show while it is unavailable.

Server Components are the largest conceptual shift, and the one candidates most often describe vaguely in interviews. The distinction is not cosmetic: a server component runs where your data lives, never ships to the browser, and cannot use state or effects.

The skill worth developing is deciding the boundary — which parts of a tree genuinely need interactivity and which are display. Applications that mark everything as a client component get the complexity of the model with none of the benefit, which is a common and expensive mistake.

• Server components for data access and static rendering
• Client components only where interactivity genuinely lives
• Passing serialisable props across the boundary
• Recognising when a shared component forces a client boundary upward

Interviewers are increasingly asking candidates to explain the server-client boundary and to justify where they would place it. Vague answers about "rendering on the server for speed" do not survive follow-up questions.

Be able to say what cannot cross the boundary and why, what happens to bundle size, and how you would debug a component that fails because it uses browser APIs on the server. That last one is the most common real-world error and knowing it signals genuine use.

For most teams on a recent version, the upgrade itself is manageable and the deprecations are well documented. The larger question is whether to adopt the new architectural patterns, which is a much bigger piece of work than the version bump.

A reasonable position is to upgrade for support and incremental improvements, then adopt Actions in new code rather than rewriting working flows. Wholesale migration to Server Components is justified by specific problems — bundle size, data-fetching waterfalls — not by wanting to be current.