React 19 added Actions, optimistic state, form status, ref as a prop, document metadata, resource APIs, and Server Component improvements. React 19.2 later stabilized useEffectEvent and introduced <Activity>. These APIs complement existing controlled forms, event handlers, refs, and effect dependencies; they do not erase every older pattern.
This guide contains 30 version-specific interview questions and distinguishes React core from framework features such as Server Functions and routing. It also covers React Compiler 1.0, which is a separate build-time optimizer rather than part of the React runtime.
Table of Contents
- React 19 Overview Questions
- useActionState Questions
- useOptimistic Questions
- Form Actions Questions
- Ref as Prop Questions
- useEffectEvent Questions
- Resource Preloading Questions
- Activity Component Questions
- Integrated Patterns Questions
React 19 Overview Questions
Understanding React 19's philosophy helps you answer any specific question about its features.
What are the major changes in React 19?
React 19.0 introduced Actions, useActionState, useOptimistic, function-valued form actions, ref as a prop for function components, metadata/resource handling, use, and improved hydration diagnostics. React 19.2 added <Activity>, useEffectEvent, Performance Tracks, and partial pre-rendering APIs for framework authors. State the minor version when discussing those later features.
The theme is giving frameworks and applications composable primitives for async transitions and rendering. Existing event handlers and explicit state remain valid when their control is useful.
What is React Compiler 1.0 and does it remove all manual memoization?
React Compiler 1.0 is a stable build-time optimizer released in October 2025. It analyzes data flow and applies granular automatic memoization to components and Hooks that follow the Rules of React. It is compatible with React 17+ (older targets may need react-compiler-runtime) and is adopted through framework or build-tool integration.
It does not make performance measurement, correct effect dependencies, stable API contracts, or all manual memoization irrelevant. Existing memo, useMemo, and useCallback can coexist, and libraries may still require identity stability as part of an API. Adopt incrementally, enable the compiler-backed eslint-plugin-react-hooks rules, pin the compiler when test coverage is weak, and verify behavior/performance with production-like tests.
What is React 19's philosophy on form handling?
Before React 19, form handling required orchestrating multiple pieces of state. You needed a loading state, an error state, form data state, and an event handler that coordinated them all. This pattern appeared in virtually every form, yet developers wrote it from scratch each time.
React 19 recognizes that many data mutations share pending, optimistic, error, and state-update behavior. Actions and related hooks encode parts of this lifecycle, while validation, authorization, concurrency conflicts, cancellation, and domain-specific state remain explicit.
How does React 19 treat refs differently?
The ref change removes an API that always felt like a workaround. forwardRef existed because refs were "special"—they couldn't flow through components like regular props. Now they can. This isn't just syntactic sugar; it reflects React treating refs as first-class values.
React 19 changes the internal implementation so refs can flow through components like any other prop. This has implications for simpler component APIs, better TypeScript inference, and cleaner debugging.
useActionState Questions
This hook has become a litmus test for whether candidates have actually built anything with React 19.
What is useActionState and how does it work?
useActionState lets an Action update state. It takes a reducer Action and initial state, then returns the current state, an action dispatcher, and isPending. When used as a form action, the reducer receives previous state followed by FormData.
The hook supplies transition-aware pending state and queues Action calls so each reducer receives the previous result. The reducer still owns validation and returned error state; a thrown error is handled by the nearest Error Boundary. Directly dispatching an async Action outside an Action context may require startTransition.
Here's the transformation from the old pattern to React 19:
// The old pattern - verbose and error-prone
function UpdateProfile() {
const [name, setName] = useState('');
const [isLoading, setIsLoading] = useState(false);
const [error, setError] = useState(null);
async function handleSubmit(e) {
e.preventDefault();
setIsLoading(true);
setError(null);
try {
await updateProfile({ name });
} catch (err) {
setError(err.message);
} finally {
setIsLoading(false);
}
}
return (
<form onSubmit={handleSubmit}>
<input
value={name}
onChange={e => setName(e.target.value)}
/>
<button disabled={isLoading}>
{isLoading ? 'Saving...' : 'Save'}
</button>
{error && <p className="error">{error}</p>}
</form>
);
}Now here's the same functionality with useActionState:
// React 19 - declarative and concise
function UpdateProfile() {
const [state, submitAction, isPending] = useActionState(
async (previousState, formData) => {
const result = await updateProfile({
name: formData.get('name')
});
if (result.error) {
return { error: result.error, saved: false };
}
return { error: null, saved: true };
},
{ error: null, saved: false }
);
return (
<form action={submitAction}>
<input type="text" name="name" />
<button disabled={isPending}>
{isPending ? 'Saving...' : 'Save'}
</button>
{state.error && <p className="error">{state.error}</p>}
{state.saved && <p>Profile saved.</p>}
</form>
);
}Notice three things. The dispatcher is passed to the form action; React supplies FormData; and the reducer's return value becomes the next state. Catch expected failures when you want inline state, but let unexpected thrown errors reach an Error Boundary.
What does useActionState return?
The hook returns a tuple of three values: [state, submitAction, isPending]. The state contains whatever your action function returns—typically error messages or null for success. The submitAction is a function you pass to the form's action prop. The isPending boolean indicates whether the action is currently executing.
This signature supports a pending/result cycle but does not prescribe the state shape. The optional third permalink argument supports progressive enhancement with Server Functions before hydration.
When would you still use the old form handling pattern?
Good answers mention complex multi-step forms, real-time validation, or when you need fine-grained control over the submission timing. useActionState optimizes for common cases, not every case.
For example, if you need to validate fields as the user types and show errors before submission, you still need controlled inputs with useState. If you need to submit in multiple stages or coordinate multiple API calls, manual state management may be clearer.
useOptimistic Questions
These questions test whether candidates understand the UX implications of async operations.
How does useOptimistic enable better UX?
useOptimistic solves a fundamental UX problem: users perceive interfaces as slow when they have to wait for server confirmation before seeing their actions reflected. The solution is optimistic updates—show the expected result immediately, then reconcile when the server responds.
Before React 19, implementing this required careful state management. You'd track both the "real" state and the "optimistic" state, merge them for display, and handle rollback on errors. It was doable but tedious and error-prone.
useOptimistic makes the projection declarative. You provide source state and get an optimistic value plus a setter. Call the setter inside an Action. When the Action finishes, React returns to the current source state, so successful server data must update that source; otherwise the optimistic change also disappears on success.
import { startTransition, useOptimistic } from 'react';
function TodoList({ todos, onToggle }) {
const [optimisticTodos, toggleOptimistic] = useOptimistic(
todos,
(currentTodos, todoId) =>
currentTodos.map(todo =>
todo.id === todoId
? { ...todo, completed: !todo.completed }
: todo
)
);
function handleToggle(todoId) {
startTransition(async () => {
toggleOptimistic(todoId);
await onToggle(todoId); // Parent must publish confirmed todos.
});
}
return (
<ul>
{optimisticTodos.map(todo => (
<li
key={todo.id}
onClick={() => handleToggle(todo.id)}
style={{
textDecoration: todo.completed ? 'line-through' : 'none',
opacity: todo.sending ? 0.5 : 1 // Visual pending state
}}
>
{todo.text}
</li>
))}
</ul>
);
}What are the arguments to useOptimistic?
The hook takes two arguments: the current "real" state (typically from a server or parent component) and a reducer function that describes how to apply optimistic updates. The reducer receives the current optimistic state and the value passed to the updater, returning the new optimistic state.
This is powerful because it handles complex transformations, not just simple value swaps. You can add items to lists, toggle booleans, update nested objects—any transformation expressible as a pure function.
How can you show a pending indicator with optimistic updates?
A pattern that works well is combining useOptimistic with a "sending" flag to give users subtle feedback that their action is in progress while still showing the expected outcome:
const [optimisticMessages, addOptimisticMessage] = useOptimistic(
messages,
(state, newMessage) => [
...state,
{ text: newMessage, sending: true } // Flag for pending indicator
]
);The optimistic item appears immediately with a visual indicator. When the server confirms, update the source state with canonical server data; React then renders that rather than the temporary projection. Stable client/server IDs help avoid duplicates and flicker.
What happens if the server request fails with useOptimistic?
When the Action ends, React falls back to the current source state, so a failed projection disappears. You still need visible error/retry UX, conflict handling, accessible pending feedback, and safeguards against duplicate submissions. Avoid optimistic success for high-risk operations unless the rollback model is clear.
The hook is about perceived performance, not actual performance. The operation takes the same time, but users feel the interface is faster because they see their action reflected immediately.
Form Actions Questions
Form Actions represent a paradigm shift that many developers miss because they look like a small syntax change.
What are form Actions in React 19?
React DOM lets <form action> and a button's formAction accept functions. React calls the function in a Transition with FormData, tracks submission status, and resets uncontrolled fields after a successful action. A URI action and an onSubmit handler remain valid for other requirements.
The function can be a client Action or a framework-provided Server Function. Progressive enhancement before hydration applies to Server Functions in supporting frameworks, not to an arbitrary client function. Always validate and authorize on the server; React does not supply CSRF protection or a mutation transport by itself.
How does useFormStatus work with form Actions?
Consider how Actions compose with useFormStatus:
// useFormStatus only works inside form Actions
function SubmitButton() {
const { pending } = useFormStatus();
return (
<button type="submit" disabled={pending}>
{pending ? 'Submitting...' : 'Submit'}
</button>
);
}
function ContactForm() {
async function submitForm(formData) {
await sendMessage({
email: formData.get('email'),
message: formData.get('message')
});
}
return (
<form action={submitForm}>
<input type="email" name="email" required />
<textarea name="message" required />
<SubmitButton /> {/* Knows if parent form is pending */}
</form>
);
}useFormStatus returns { pending, data, method, action } for the nearest parent form's last submission. It must run in a descendant component; calling it in the same component that renders the form does not observe that form.
What is the mental model shift with form Actions?
Actions turn forms from "containers of inputs with an event handler" into "descriptions of data mutations." This aligns with React's broader philosophy of declarative UI. You declare what data transformation should happen, not how to orchestrate the DOM events.
Recognition that Actions are more than syntax sugar—they enable new composition patterns like useFormStatus—demonstrates deeper understanding of React 19's design.
Can you use Actions with controlled inputs?
Yes, absolutely. Actions don't require uncontrolled inputs; you can still use useState for real-time validation or complex input logic. Actions just give you another option that's often simpler for basic forms.
If you need to validate on every keystroke, transform input values, or coordinate multiple fields, controlled inputs remain the right choice. Actions shine for straightforward submission flows.
Ref as Prop Questions
These questions reveal whether candidates understand why forwardRef existed in the first place.
Why did React 19 remove the need for forwardRef?
To understand why this matters, you need to know why forwardRef existed. In earlier React, refs were "special"—they weren't part of the regular props object because React needed to handle them differently during reconciliation. forwardRef was an API workaround that let you "forward" this special value through component boundaries.
React 19 changes the internal implementation so refs can flow through components like any other prop. This has several implications.
First, simpler component APIs:
// Before React 19 - forwardRef wrapper required
const Input = forwardRef(function Input({ label, ...props }, ref) {
return (
<label>
{label}
<input ref={ref} {...props} />
</label>
);
});
// React 19 - ref is just another prop
function Input({ label, ref, ...props }) {
return (
<label>
{label}
<input ref={ref} {...props} />
</label>
);
}Second, better TypeScript inference. forwardRef had notorious typing issues because TypeScript struggled with its higher-order function signature. With ref as a prop, types flow naturally.
Third, cleaner debugging. Component names in DevTools and error messages were sometimes awkward with forwardRef. Regular function components don't have this issue.
Is forwardRef deprecated in React 19?
forwardRef still works in React 19. The current API page labels it deprecated while also stating that formal deprecation/removal is for a future release. The practical interview answer is: new function components can accept ref as a prop; existing wrappers do not require an urgent rewrite. Class-component refs remain special because they refer to the instance.
How does the ref as prop change affect existing codebases?
Existing forwardRef usage continues to work. Consumers still write <Input ref={ref}>; the main change is how the function component receives it. Libraries should test React/TypeScript version ranges and only declare a breaking release when their public types or supported React range actually change.
Understanding the "why" behind the change—that refs being special was a limitation, not a feature—demonstrates practical experience with the pain points forwardRef caused.
useEffectEvent Questions
This is a nuanced topic that separates developers who've hit the stale closure problem from those who've only read about hooks.
What problem does useEffectEvent solve?
useEffectEvent solves a fundamental tension in the hooks model. Effects should re-run when their dependencies change—that's the rule. But sometimes effects need to call functions that read current props or state without wanting the effect to re-run when those values change.
A concrete example makes this clear:
// The problem: effect re-runs whenever theme changes
function ChatRoom({ roomId, theme }) {
useEffect(() => {
const connection = createConnection(roomId);
connection.on('connected', () => {
showNotification('Connected!', theme); // Uses theme
});
connection.connect();
return () => connection.disconnect();
}, [roomId, theme]); // theme in deps causes reconnect on theme change!
}This effect should only re-run when roomId changes (reconnect to new room). But the notification handler uses theme, so the linter correctly warns you to add it as a dependency. The result? Changing themes disconnects and reconnects—clearly wrong behavior.
How does useEffectEvent fix the stale closure problem?
Before useEffectEvent, developers either disabled the lint rule (risky) or created convoluted workarounds with refs. useEffectEvent gives you a principled solution:
// The solution: Effect Events read current values without being dependencies
function ChatRoom({ roomId, theme }) {
const onConnected = useEffectEvent(() => {
showNotification('Connected!', theme); // Always reads current theme
});
useEffect(() => {
const connection = createConnection(roomId);
connection.on('connected', () => {
onConnected(); // Not a dependency
});
connection.connect();
return () => connection.disconnect();
}, [roomId]); // Only roomId - correct!
}The Effect Event reads the latest committed values when called. Its function identity intentionally changes on every render. Do not put it in dependency arrays, call it during render, or pass it to other components/Hooks; it belongs to local Effect logic. The current eslint-plugin-react-hooks rules enforce these restrictions.
Is useEffectEvent the same as useCallback with an empty dependency array?
No. useCallback(fn, []) memoizes function identity and captures values from that render. useEffectEvent reads the latest committed values but deliberately does not have stable identity and can only be called from Effects or other local Effect Events.
Use Effect Events only to separate genuinely non-reactive event logic from synchronization. They are not a loophole for omitting dependencies that should re-synchronize an Effect.
Resource Preloading Questions
These questions test awareness of performance-focused features that don't get as much attention as hooks.
What resource preloading APIs were added in React 19?
React 19 added resource APIs to react-dom: prefetchDNS, preconnect, preload, preloadModule, preinit, and preinitModule. They express browser hints or initialize resources from component logic while React handles compatible head placement and deduplication.
The distinction between them matters:
import {
prefetchDNS, preconnect, preload, preloadModule, preinit, preinitModule
} from 'react-dom';
function App() {
// DNS lookup only - when you might request from this host
prefetchDNS('https://api.example.com');
// DNS + TCP + TLS handshake - when you will request but don't know what
preconnect('https://api.example.com');
// Actually fetch the resource - for fonts, stylesheets, images
preload('https://fonts.example.com/font.woff2', { as: 'font' });
// Fetch and initialize a classic script (or stylesheet with as: 'style')
preinit('https://example.com/critical.js', { as: 'script' });
preloadModule('/feature.js');
preinitModule('/bootstrap.js');
// ...
}When would you use each preloading API?
- prefetchDNS: When you might make requests to a host. Minimal cost, resolves domain name early.
- preconnect: When you will definitely request from a host but don't know exactly what. Sets up the full connection.
- preload: When you know a specific resource will be needed. Fetches fonts, stylesheets, images.
- preloadModule: Fetch an ESM module expected soon without evaluating it yet.
- preinit: Fetch and initialize a classic script or stylesheet.
- preinitModule: Fetch and evaluate an ESM module.
These calls consume network resources. Prefer the weakest hint that meets the need and verify impact with browser tooling and real-user performance data.
The practical use case is optimizing initial page loads, especially with code splitting:
function ProductPage({ productId }) {
// Start loading the product API connection while React renders
preconnect('https://api.store.com');
// Preload product images we know we'll need
preload(`https://cdn.store.com/products/${productId}/main.jpg`, {
as: 'image'
});
// Preinit analytics that should run ASAP
preinit('https://analytics.store.com/tracker.js', { as: 'script' });
return <ProductDetails id={productId} />;
}How are React's preloading APIs different from manual link tags?
React can hoist resource tags and deduplicate compatible calls for the same resource. The exact browser scheduling result still depends on attributes (as, crossOrigin, precedence), discovery time, cache state, and browser implementation.
Manual <link>/<script> tags remain valid and may be preferable for resources known in the document shell. The React APIs are useful when resource knowledge lives inside the rendered component tree; they are not automatically faster than a correct early HTML hint.
Activity Component Questions
These are forward-looking questions for candidates tracking React's development.
What is the Activity component in React 19.2?
The stable Activity component arrived in React 19.2 (October 2025). It lets React hide UI with display: none, preserve its React state and usually its DOM, clean up its Effects, and process hidden updates at lower priority.
The primary use case is keeping component state alive during navigation. Think of a tab interface where switching tabs unmounts and remounts components, losing their internal state. With Activity, you can hide inactive tabs without destroying them:
function TabbedInterface({ activeTab }) {
return (
<div>
<Activity mode={activeTab === 'home' ? 'visible' : 'hidden'}>
<HomeTab />
</Activity>
<Activity mode={activeTab === 'search' ? 'visible' : 'hidden'}>
<SearchTab /> {/* Preserves search results when hidden */}
</Activity>
<Activity mode={activeTab === 'profile' ? 'visible' : 'hidden'}>
<ProfileTab />
</Activity>
</div>
);
}What happens to effects when Activity mode is hidden?
When mode is 'hidden', React runs Effect cleanup as if the subtree were unmounted. State is saved and DOM is generally retained but hidden; updates may still render at lower priority. When visible again, React restores the UI and re-creates Effects—they do not resume mid-effect. DOM elements with independent behavior such as video/audio/iframes may still need explicit cleanup.
This can help tabs or navigation where restoring state is valuable, but it is not a blanket promise to preserve every browser/DOM behavior or scroll position. Test accessibility, memory, media, focus, and stale hidden data.
How does Activity relate to Suspense and Transitions?
They're all part of React's concurrent features. Activity extends the model by letting you explicitly manage when components are active vs. preserved-but-hidden. While Suspense handles loading states and Transitions handle priority, Activity handles visibility.
Use Activity when the benefit of state restoration or background prerendering outweighs retained memory and hidden rendering work. Conditional unmounting remains appropriate when state should reset or resources should be released completely.
Integrated Patterns Questions
These questions test how well you can combine React 19 features.
How would you build a comment section using multiple React 19 features?
Here's a complete component that uses multiple React 19 features together:
import { useActionState, useOptimistic, useState } from 'react';
import { preconnect, useFormStatus } from 'react-dom';
function CommentSection({ postId, initialComments }) {
// Preload connection to comment API
preconnect('https://api.example.com');
// Optimistic comments for instant feedback
const [comments, setComments] = useState(initialComments);
const [optimisticComments, addOptimisticComment] = useOptimistic(
comments,
(comments, newComment) => [
...comments,
{ ...newComment, sending: true }
]
);
// Form action with integrated state management
const [error, submitComment, isPending] = useActionState(
async (prevState, formData) => {
const text = formData.get('comment');
if (typeof text !== 'string' || !text.trim()) {
return 'Comment is required';
}
// Show optimistic comment immediately
addOptimisticComment({
id: crypto.randomUUID(),
text,
author: 'You'
});
// Server call
const result = await postComment(postId, text);
if (result.error) {
return result.error;
}
// Make the confirmed server representation the new source state.
setComments(current => [...current, result.comment]);
return null;
},
null
);
return (
<div>
<ul>
{optimisticComments.map(comment => (
<li key={comment.id} style={{
opacity: comment.sending ? 0.6 : 1
}}>
<strong>{comment.author}:</strong> {comment.text}
{comment.sending && <span> (posting...)</span>}
</li>
))}
</ul>
<form action={submitComment}>
<textarea
name="comment"
placeholder="Write a comment..."
required
/>
<SubmitButton />
</form>
{error && <p className="error">{error}</p>}
</div>
);
}
function SubmitButton() {
const { pending } = useFormStatus();
return (
<button type="submit" disabled={pending}>
{pending ? 'Posting...' : 'Post Comment'}
</button>
);
}This component demonstrates useOptimistic for instant feedback, useActionState for form handling, useFormStatus for button state, form Actions for declarative submission, and resource preloading for performance.
How would you make a 2-second form submission feel instant?
You cannot make a two-second mutation instant. Use useOptimistic to show a clearly pending projection, useActionState/useFormStatus for transition state, and update the source with canonical server data on success. On failure, the projection disappears, but you must explain the failure and offer a safe retry.
Also reduce actual latency, prevent duplicate submission, preserve focus, announce pending/error state accessibly, and avoid optimistic claims for destructive or high-conflict operations.
How would you log analytics with current user data without re-running WebSocket effects?
Wrap only the non-reactive analytics callback in useEffectEvent. It reads the latest committed user data when called from the connection Effect, but changing that data need not reconnect the socket. Keep URL/room/auth values that genuinely define the connection as Effect dependencies.
Quick Reference
| Feature | Hook/API | Primary use | Important boundary |
|---|---|---|---|
| Action State | useActionState | State updated by Actions | Validation/errors remain explicit |
| Optimistic Updates | useOptimistic | Temporary pending projection | Source state must confirm success |
| Form Actions | <form action={fn}> | Transition-aware submission | Server concerns need a framework/app |
| Form Status | useFormStatus | Parent-form submission state | Must be called in a descendant |
| Effect Events | useEffectEvent | Non-reactive Effect event logic | Not stable; call only from Effects |
| Ref as Prop | function Comp({ ref }) | Function-component references | Existing forwardRef still works |
| Resource APIs | preload/preinit variants | Head/resource coordination | Too many hints hurt performance |
| Activity | <Activity> | Hide UI while preserving React state | Effects are cleaned up/re-created |
| React Compiler | Build-time optimizer | Automatic granular memoization | Separate tool; Rules of React apply |
Official Sources
- React 19 release
- React 19 upgrade guide
- React 19.2 release
- React Compiler 1.0
useActionStateuseOptimistic- React DOM form Actions
useFormStatususeEffectEventActivity- React DOM resource APIs
Related Articles
- Complete Frontend Developer Interview Guide - Comprehensive preparation guide for frontend interviews
- React Hooks Interview Guide - Master useState, useEffect, and custom hooks
- 9 Advanced React Interview Questions - Deep dive into React patterns, performance, and architecture questions
- TypeScript Type vs Interface - When to use type aliases vs interfaces
- Top 5 React Interview Mistakes - Common hooks and rendering mistakes to avoid
Frequently Asked Questions
What is useActionState in React 19?
useActionState manages state updated by an Action. It returns [state, dispatchAction, isPending]; the reducer Action receives the previous state and an action payload (FormData when used as a form action). Returned values become state, while thrown errors go to an Error Boundary. It does not automatically validate fields, authorize requests, or model every form state.
How does useOptimistic work in React 19?
useOptimistic temporarily projects state while an Action is pending. When the Action finishes, React returns to the source state; success becomes durable only when that source is updated with confirmed server data. On failure, show an error and let the projection disappear or reconcile explicitly. Use optimistic UI only when conflicts and rollback are understandable.
What are form Actions in React 19?
React DOM lets form action/formAction receive a function. React passes FormData, runs the Action in a Transition, exposes submission status through useFormStatus, routes thrown errors to an Error Boundary, and resets uncontrolled fields after a successful action. Server Functions can progressively enhance submission. Validation, authorization, CSRF policy, and error UX remain application or framework responsibilities.
Why was forwardRef deprecated in React 19?
React 19 allows ref to be passed as a regular prop to function components, eliminating the need for forwardRef. This simplifies component APIs and reduces boilerplate. Components can now access ref directly from props alongside other props, making the code more straightforward.
What is useEffectEvent in React 19?
useEffectEvent, stable in React 19.2, separates non-reactive event logic inside an Effect. It reads the latest committed props/state without becoming an Effect dependency. Call Effect Events only from Effects or other local Effect Events; do not pass them around or use them to hide real dependencies. Their function identity intentionally changes on every render.
What resource preloading APIs were added in React 19?
React DOM exposes prefetchDNS, preconnect, preload, preloadModule, preinit, and preinitModule. They express progressively stronger resource hints, from DNS lookup to fetching or initializing classic/ES-module resources. React can hoist and deduplicate compatible calls. Use them only for resources likely to be needed soon; excessive preloads/preconnects compete for bandwidth and sockets.