8 React Hooks That Quietly Changed How I Write React in 2026

When I started writing React, component logic was surprisingly predictable. Every file looked more or less the same. State lived in useState, side effects went into useEffect, expensive calculations were wrapped in useMemo, and every callback somehow ended up inside useCallback. If I needed to persist something across renders, there was useRef.

For years, that was enough.

As applications became larger, however, I noticed a pattern. The complexity wasn't coming from React itself—it was coming from all the code I was writing around React. Boilerplate for loading states, optimistic updates, synchronizing external data, reconnecting subscriptions because of dependency arrays, or coordinating half a dozen pieces of related state.

React's newer hooks don't necessarily introduce new capabilities. Instead, they eliminate patterns we've all written dozens of times.

After spending the last few months building production applications with React and Next.js, these are the hooks that have had the biggest impact on the way I structure components.

---

useActionState — Making Forms Feel Native Again

For a long time, every form component I wrote followed the same template. There was a loading flag, an error state, maybe a success message, and a submit handler wrapped in a try...catch...finally block. None of it was particularly difficult, but every form ended up containing the same plumbing.

const [loading, setLoading] = useState(false);
const [error, setError] = useState(null);

async function handleSubmit() {
  setLoading(true);

  try {
    await saveUser();
  } catch (err) {
    setError(err);
  } finally {
    setLoading(false);
  }
}

The logic worked, but it distracted from the actual business problem. Most forms aren't interesting because they manage loading flags—they're interesting because they perform an action.

That's exactly where useActionState fits.

const [state, submit, pending] =
  useActionState(saveUser, initialState);

Instead of manually coordinating multiple pieces of state, the hook models the action itself. The component naturally receives the latest state, whether the action is pending, and a function that performs the submission. It feels much closer to describing what the component is doing rather than how every intermediate state should be managed.

In React 19 applications, especially those built with Next.js Server Actions, this has become my default approach for forms.

---

useOptimistic — Performance Is Often About Perception

One of the biggest lessons I've learned building user-facing applications is that users rarely measure performance the same way developers do.

A request that takes 400 milliseconds can still feel instantaneous if the interface responds immediately. Conversely, even a fast API can feel sluggish if the UI waits for every network round trip before updating.

That's the problem optimistic rendering solves.

const [messages, addOptimistic] =
  useOptimistic(messages, (state, message) => [
    ...state,
    message
  ]);

When a user sends a chat message or clicks a like button, the interface reflects the change immediately.

addOptimistic({
  id: crypto.randomUUID(),
  text
});

await api.send(text);

The server eventually confirms—or rejects—the update, but from the user's perspective the application already responded.

Once you start using optimistic rendering in chat systems, social interactions, comments, or collaborative tools, it's surprisingly difficult to go back. The application simply feels alive.

---

useEffectEvent — Separating Effects From Events

If I had to pick the hook that solves the most subtle React problem, it would probably be useEffectEvent.

For years, many of us wrote effects like this:

useEffect(() => {
  socket.on("message", () => {
    console.log(theme);
  });
}, [theme]);

The dependency array is technically correct, but changing the theme now recreates the entire subscription. In a real application, that might mean reconnecting a WebSocket, restarting an interval, or reinitializing an expensive integration—all because the callback captured a different value.

useEffectEvent separates the event logic from the lifecycle of the effect itself.

const onMessage = useEffectEvent(() => {
  console.log(theme);
});

useEffect(() => {
  socket.on("message", onMessage);
}, []);

The subscription stays stable, while the callback always receives the latest state.

It's one of those APIs that doesn't seem revolutionary until you've spent years fighting stale closures and dependency arrays. Once you understand the mental model, a surprising number of effects become simpler.

---

useTransition — Prioritizing What Actually Matters

Not every update deserves the same priority.

Typing into an input field is urgent. Re-rendering a dashboard with thousands of rows usually isn't.

Without prioritization, React treats both updates equally, which is why search inputs often become sluggish as datasets grow.

const [pending, startTransition] =
  useTransition();

startTransition(() => {
  setSearch(query);
});

What I appreciate most about useTransition is that it forces you to think about user experience rather than rendering performance.

The goal isn't making React faster.

The goal is ensuring that interactions remain responsive while expensive work happens in the background.

Users don't care whether a render took 40 or 80 milliseconds. They absolutely notice when typing starts lagging.

---

useDeferredValue — Let Expensive Work Wait

useDeferredValue solves a similar problem from a different angle.

Imagine filtering several thousand products on every keystroke. The filtering logic itself might be unavoidable, but updating it immediately on every character often creates unnecessary work.

const deferredSearch =
  useDeferredValue(search);

const filteredProducts = useMemo(() => {
  return expensiveFilter(deferredSearch);
}, [deferredSearch]);

The input updates immediately while the expensive computation catches up when React has time.

What I like about this hook is how little code it requires. You don't need debouncing, timers, or additional state management. You're simply telling React that one value is less urgent than another.

---

useReducer — Complexity Deserves Structure

Early in my React career, I associated useReducer with Redux and assumed it was only useful for global state.

That turned out to be completely wrong.

Whenever I notice a component accumulating five or six related useState calls, it's usually a sign that the component isn't managing independent pieces of state anymore. It's managing a workflow.

A checkout flow is a good example. The cart affects discounts. Discounts affect totals. Loading states affect submission. Errors change what the user can do next.

Trying to coordinate all of that through independent setters eventually becomes difficult to reason about.

Reducers change the conversation.

dispatch({
  type: "ADD_ITEM",
  payload: product
});

Instead of asking which state variables need updating, the component describes the event that occurred. The reducer decides how the application transitions from one valid state to another.

For larger components, that single shift in thinking makes the codebase dramatically easier to maintain.

---

useLayoutEffect — Sometimes Timing Matters

Most React developers can go years without needing useLayoutEffect.

When they finally do, nothing else quite solves the problem.

The difference between useEffect and useLayoutEffect isn't about capability—it's about when the code executes.

If you're measuring DOM elements, positioning overlays, synchronizing scroll positions, or preventing layout flicker, waiting until after the browser paints is already too late.

useLayoutEffect(() => {
  const rect =
    ref.current.getBoundingClientRect();

  setPosition(rect);
}, []);

The browser performs the measurement before the frame is painted, so users never see the intermediate incorrect layout.

The trade-off is that layout effects block painting, so they're a tool to use intentionally rather than by default.

---

useSyncExternalStore — Infrastructure More Than Application Code

Most developers probably use this hook every day without realizing it.

Libraries like Redux, Zustand, Jotai, and others rely on it under the hood because it provides React's official mechanism for synchronizing external stores with concurrent rendering.

const state =
  useSyncExternalStore(
    store.subscribe,
    store.getSnapshot
  );

If you're simply consuming a state library, you'll rarely interact with it directly.

If you're building one—or wrapping browser APIs, real-time streams, or custom subscription systems—it becomes indispensable.

It's less of an application hook and more of an infrastructure hook, which is exactly why most developers never reach for it themselves.

---