DEV Community: Abrar Galib

How React Props and Redux Actually Work, Step by Step

Abrar Galib — Fri, 09 Oct 2026 01:43:10 +0000

A simple look at what happens when I click a button in React, how props move from parent to child, and what changes when Redux joins in. Every step is shown file by file.

tags: react, redux, javascript, webdev

A simple look at what happens when you click a button in React, how data moves from parent to child, and what changes when you add Redux.

The words used in this guide

Here are the main terms in one place. Each one is explained again in its own step below.

TERM        WHAT IT MEANS
props       data a parent sends down to a child
state       data a component owns and can change
event       something the user does, like a click
component   a function that returns a piece of the screen
action      a plain object that says what happened
dispatch    the function that sends an action to the store
reducer     the only code that works out the new state
store       the one place that holds the state of the whole app
Provider    wraps the app so any component can reach the store
middleware  optional code between dispatch and reducer, for API calls
view layer  the components that show state on screen

It looks simple

You write onClick={() => setCount(count + 1)}. You click the button. The number on the screen changes. It feels fast and simple. But under the hood, React follows the same steps every time. Once you know these steps, React makes a lot more sense.

Here is the example we will look at:

function Parent() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Increment</button>
      <Display count={count} />
    </div>
  );
}

function Display({ count }) {
  console.log("Display rendered");
  return <p>Count: {count}</p>;
}

Step 1: the click event

When you click the button, the browser creates a click event. But React does not listen on the button itself. React listens near the top of your app instead. It catches the click there and wraps it in its own event object. This helps React work the same way in every browser.

Step 2: setCount does not update right away

Calling setCount(count + 1) does not change count right away. It just tells React: "use this new value next time you render." React saves this request for later. That is why, right after calling setCount, count still shows the old value. The change has not happened yet. Only a request has been saved.

Step 3: React waits, then re-renders once

If you call setCount many times inside one click handler, React does not re-render many times. React waits, then re-renders only once, using the final value. This saves work and makes your app faster.

After the click handler finishes, React runs the Parent function again. This time, count holds the new value.

Step 4: props move down to the child

When Parent runs again, it creates a new <Display count={count} /> with the new value. React compares this new version to the old one. React sees that Display got a new prop. So Display runs again too. It prints "Display rendered" and shows the new count.

If another component did not get new props, and its own state did not change, React skips it. React does not re-render it. A new prop value is one of the main reasons a child component re-renders.

Step 5: only the changed part updates

React does not rebuild the whole page. It compares the new tree to the old tree. Then it changes only the small part that is different. Here, just the text showing the count. Everything else on the page stays the same.

The full sequence

Click
  -> Synthetic event fires, onClick handler runs
  -> setCount(count + 1) queues a state update
  -> React batches updates and schedules a re-render
  -> Parent function re-runs with the new count
  -> New props passed down to Display
  -> React diffs old tree vs new tree
  -> Only the changed DOM node is updated on screen

            Person clicks the button
                        │
                        ▼
┌──────────────────────────────────────────────┐
│ 1. Button clicked                            │
│    The browser makes a click event           │
└───────────────────────┬──────────────────────┘
                        ▼
┌──────────────────────────────────────────────┐
│ 2. Synthetic event fires                     │
│    React wraps it and runs onClick           │
└───────────────────────┬──────────────────────┘
                        ▼
┌──────────────────────────────────────────────┐
│ 3. setCount() queues update                  │
│    Only a request is saved, count stays old  │
└───────────────────────┬──────────────────────┘
                        ▼
┌──────────────────────────────────────────────┐
│ 4. Batched re-render scheduled               │
│    React waits, then renders once            │
└───────────────────────┬──────────────────────┘
                        ▼
┌──────────────────────────────────────────────┐
│ 5. Parent re-runs                            │
│    Parent runs again with the new count      │
└───────────────────────┬──────────────────────┘
                        ▼
┌──────────────────────────────────────────────┐
│ 6. New props passed to Display               │
│    Display gets the new count as a prop      │
└───────────────────────┬──────────────────────┘
                        ▼
┌──────────────────────────────────────────────┐
│ 7. DOM diff + update                         │
│    Only the changed text node updates        │
└──────────────────────────────────────────────┘

Each step finishes before the next one starts. This is why state never changes in the middle of a click handler. And it is why props only reach the child after the whole re-render is done.

Parent to child: the shape of the tree

The Display example above is just one step. The same rule repeats at every level of a bigger tree:

Data flows DOWN with props, events flow UP

src/
└── App.jsx                 owns state, sends user and posts
    ├── Sidebar.jsx         gets user, owns its own state
    │   ├── NavLink.jsx     gets links
    │   └── NavLink.jsx     gets active
    └── Main.jsx            gets posts
        ├── Card.jsx        gets post
        └── Card.jsx        gets post

DATA goes down            EVENTS go up
App.jsx                   App.jsx
  ▼  props                  ▲  function prop
Sidebar.jsx               Sidebar.jsx
  ▼  props                  ▲  function prop
NavLink.jsx               NavLink.jsx

Here is the same idea as a project. Each file is one component, and each component can have its own state.

src/
├── main.jsx              mounts the app, the root
├── App.jsx               renders Parent
└── components/
    ├── Parent.jsx        owns the state
    ├── Button.jsx        event goes up, calls setCount
    ├── Display.jsx       receives the count as a prop
    └── Footer.jsx        wrapped in memo, same props, skipped

Here is the component tree for these files. Props go down to the children, and the click event goes back up to Parent.

Parent.jsx                     state  count
├─ props ─▶ Display.jsx        state  none
├─ props ─▶ Footer.jsx         state  none
└─ props ─▶ Button.jsx         state  none
            ▲
            └─ event, onClick calls setCount in Parent.jsx

Each component only gets data from its own parent. Each component only sends data to its own children. A grandchild cannot reach up two levels by itself. The data must pass through every component in between.

Why this matters

Once you see this as a set of steps, not magic, a few confusing things make sense. State does not change right away inside the same function. Many state updates in one handler cause just one re-render. And sending the same prop value again does not make the child do extra work. Props are not shared and changed in place. React makes a fresh value every time it renders, and sends it down again.

Redux: a different setup

Everything above happens inside plain React. State lives inside one component. Props carry it down to the children. Redux changes this. Redux moves state to a new place, and lets it reach much further. Redux uses four main parts: a Slice, a Store, a Provider, and any Component that wants to use it.

Piece 1: the Slice

A slice is simple. It says what the state looks like at the start (initialState). It also says the only ways this state is allowed to change (reducers).

import { createSlice } from '@reduxjs/toolkit';

const counterSlice = createSlice({
  name: 'counter',
  initialState: { value: 0 },
  reducers: {
    increment: (state) => { state.value += 1; },
    decrement: (state) => { state.value -= 1; },
  },
});

export const { increment, decrement } = counterSlice.actions;
export default counterSlice.reducer;

createSlice quietly builds two things for you. First, action creators (small functions that describe what just happened). Second, a reducer, the only piece of code allowed to work out the new state.

Piece 2: the Store

import { configureStore } from '@reduxjs/toolkit';
import counterReducer from './counterSlice';

export const store = configureStore({
  reducer: { counter: counterReducer },
});

Every slice's reducer is added here. Your app has only one store. Think of the store as one big building. Each department (slice) has its own room inside it.

Piece 3: the Provider

import { Provider } from 'react-redux';
import { store } from './store';

ReactDOM.createRoot(document.getElementById('root')).render(
  <Provider store={store}><App /></Provider>
);

Provider wraps your whole app. It uses React Context to do this. Because of Provider, any component can reach the store. It does not matter how deep the component is. You do not need to pass it down through props by hand. This is the only place Redux still uses the parent-to-child tree from before. After this point, nothing needs that tree anymore.

So main.jsx wraps the whole app inside Provider. Every component below it can reach the store.

main.jsx
└── <Provider store={store}>        wraps the whole app
    └── <App />
        ├── <Sidebar />
        └── <Main />
            └── <Counter />         can use useSelector and useDispatch

Piece 4: the Component

import { useSelector, useDispatch } from 'react-redux';
import { increment, decrement } from './counterSlice';

function Counter() {
  const count = useSelector((state) => state.counter.value);
  const dispatch = useDispatch();

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => dispatch(increment())}>+</button>
      <button onClick={() => dispatch(decrement())}>-</button>
    </div>
  );
}

useSelector reads a value straight from the store. This component re-renders any time that value changes. useDispatch sends an action to the store. The component never changes the state by itself.

Here is how the pieces connect across real files. The first block is the project structure. The second block runs once when the app starts. The third block runs every time the user clicks the + button.

src/
├── main.jsx                 Provider wraps the whole app
├── app/
│   └── store.js             the Store, reducers inside
├── features/counter/
│   ├── counterSlice.js      Action and Reducer
│   ├── counterSaga.js       middleware, optional
│   └── Counter.jsx          View layer, sends Event and Dispatch
├── api/
│   └── counterApi.js        APIs, request and response, optional
└── components/
    └── Badge.jsx            View layer, reads the store

SETUP, runs once when the app starts

counterSlice.js ──exports reducer──► store.js ──imported by──► main.jsx
                                                                  │  Provider wraps the whole app
                                                                  ▼
                                                               Counter.jsx

RUNTIME, every click on the + button

                 dispatch(increment())
Counter.jsx ──────────────────────────────► counterSlice.js
     ▲                                          │
     │ useSelector                              │ new state
     │                                          ▼
main.jsx (Provider) ◄────────────────────── store.js

The two files marked optional are only needed when the app talks to an API. Here is every Redux word again, matched to the file where it lives.

TERM           FILE AND MEANING
Event          onClick in Counter.jsx
Action         increment() in counterSlice.js
Dispatch       useDispatch in Counter.jsx
Middleware     counterSaga.js, optional
APIs           counterApi.js, request and response
Effect(s)      run by the saga, then the action goes on
Reducers       counterSlice.js
Store          store.js
Updated state  the value that useSelector reads
View layer     Counter.jsx and Badge.jsx

One more word that appears in bigger apps is middleware. It is optional code that sits between dispatch and the reducer. It handles work like API requests and responses, with tools such as Redux Thunk or Redux Saga. This counter does not need it.

No props travel between the button and the other component reading count. Both of them just talk to the same store on their own. This is the real difference from everything in the sections above.

An easy way to remember it

Here is an easy way to remember it. Slice is the menu and the recipe book. Store is the kitchen. Provider is the waiter, carrying food from the kitchen to every table. Component is you. You order food, and you watch your plate arrive.

When this is worth it

This setup is worth it when many, unrelated components need to read or change the same data. It also helps when it gets hard to track "why did this change?" by hand. For a small app, plain props and useState are usually enough. Everything from the earlier sections works just fine on its own.

Welcome Back, React Hooks Made Simple: The Complete Guide, Part-2

Abrar Galib — Thu, 24 Sep 2026 21:12:27 +0000

In [Part 1] https://dev.to/abrar_galib_5c0cf41ad3a3e/react-hooks-made-simple-the-complete-guide-part-1-2jln we covered the core Hooks (useState, useEffect, useContext), the additional Hooks (useRef, useMemo, useCallback, useReducer) and the advanced ones (useLayoutEffect, useImperativeHandle, useId). If you haven't read it yet, start there, because everything in this part builds on it.

In Part 2:

Two Hooks that keep your app smooth when an update is heavy
A few more advanced Hooks for outside data and library authors
The new Hooks that came with React 19 and later
The Hooks that belong to Next.js
Custom Hooks, common mistakes, and a cheatsheet you can keep open while you code

Everything below works on React 19. A few things need a newer minor version, and I point them out as we go: useEffectEvent needs React 19.2, and ViewTransition, Fragment Refs and use(browser()) need React 19.3, which is the current stable release.

Performance Hooks
- useTransition
- useDeferredValue
More Advanced Hooks
- useSyncExternalStore
- useInsertionEffect
- useDebugValue
New Hooks in React 19 and Later
- useActionState
- useFormStatus
- useOptimistic
- use
- useEffectEvent
- Bonus: ViewTransition and Fragment Refs
Next.js Hooks
- useRouter
- usePathname
- useSearchParams
- useParams
- useLinkStatus
- useServerInsertedHTML
Custom Hooks
Common Mistakes to Avoid
Cheatsheet
Conclusion

Performance Hooks

Sometimes an update is heavy: a huge list, a slow tab, a big search result. If React does all the work at once, the page freezes. Typing feels laggy and buttons stop responding.

These two Hooks let you tell React: "this update is not urgent, so do the important things first."

What is an urgent update?
Anything the user expects to see instantly, like typing in a box or clicking a button. Showing the search results or opening a heavy tab can wait a moment. React can handle the urgent update first and finish the slow one in the background.

useTransition

useTransition lets you mark a state update as low priority. It gives you two things: isPending, which is true while the slow update is happening, and startTransition, a function you wrap around the state update.

'use client';

import { useState, useTransition } from 'react';

function About() {
  return <p>Hi, I write about React.</p>;
}

function SlowPosts() {
  // Pretend this tab is heavy: 300 rows, and each row takes a little time
  const rows = [];
  for (let i = 0; i < 300; i++) {
    rows.push(<SlowRow key={i} number={i + 1} />);
  }
  return <ul>{rows}</ul>;
}

function SlowRow({ number }) {
  const start = performance.now();
  while (performance.now() - start < 2) {
    // do nothing for 2 ms on purpose
  }
  return <li>Post #{number}</li>;
}

export default function TabContainer() {
  const [tab, setTab] = useState('about');
  const [isPending, startTransition] = useTransition();

  function selectTab(nextTab) {
    // This update can wait, so the page stays clickable
    startTransition(() => {
      setTab(nextTab);
    });
  }

  return (
    <>
      <button onClick={() => selectTab('about')}>About</button>
      <button onClick={() => selectTab('posts')}>Posts</button>
      {isPending && <p>Loading...</p>}
      {tab === 'about' ? <About /> : <SlowPosts />}
    </>
  );
}

Click "Posts" and the old tab stays on screen while React prepares the new one in the background. You can click "About" again at any time and React will drop the slow work and switch back. Without startTransition, the whole page would freeze for a moment.

Note: In React 19 you can even pass an async function to startTransition, and isPending stays true until it finishes. This is the base for the form Hooks later in this guide.

useDeferredValue

useDeferredValue gives you a copy of a value that intentionally "lags behind". While the user keeps typing, your input stays fast, and the heavy part of the screen catches up a moment later.

Use it when you can't wrap the state setter yourself, for example when the value arrives as a prop.

'use client';

import { memo, useDeferredValue, useState } from 'react';

const Results = memo(function Results({ items, query }) {
  const matches = items.filter((item) =>
    item.toLowerCase().includes(query.toLowerCase())
  );

  return (
    <ul>
      {matches.map((item) => (
        <li key={item}>{item}</li>
      ))}
    </ul>
  );
});

export default function Search({ items }) {
  const [query, setQuery] = useState('');
  const deferredQuery = useDeferredValue(query);
  const isStale = query !== deferredQuery;

  return (
    <>
      <input
        value={query}
        onChange={(e) => setQuery(e.target.value)}
        placeholder="Search..."
      />
      <div style={{ opacity: isStale ? 0.5 : 1 }}>
        <Results items={items} query={deferredQuery} />
      </div>
    </>
  );
}

Two things to remember:

You must wrap the slow component in memo. If you don't, it re-renders on every keystroke anyway and you save nothing.
query !== deferredQuery tells you the list is still catching up. Here we use it to dim the old results.

React 19 also lets you pass a starting value as the second argument, like useDeferredValue(query, '').

useTransition or useDeferredValue?

	useTransition	useDeferredValue
What it wraps	The code that sets state	The value itself
Use it when	You own the state setter	The value comes from a prop or a Hook
You get	`isPending` flag	A lagging copy of the value

Note: Don't wrap the setState of a text input in startTransition. The text in the box must update instantly, so the input state has to stay urgent. Defer the slow part instead, like we did above.

More Advanced Hooks

You will use these three much less often than the ones above. Still, you should know what they are, because you'll see them in libraries and in other people's code.

useSyncExternalStore

useSyncExternalStore connects React to data that lives outside of React and changes on its own, like the browser's online status, the window size, or a global store.

What is an external store?
It's any data source that React doesn't own. React can't know when it changes, so you have to tell React how to listen to it. Libraries like Redux and Zustand use this Hook under the hood.

It takes three functions:

subscribe: starts listening for changes and returns a cleanup function
getSnapshot: reads the current value
getServerSnapshot: gives a starting value for server rendering, so the server HTML matches the browser HTML during hydration

'use client';

import { useSyncExternalStore } from 'react';

function subscribe(callback) {
  window.addEventListener('online', callback);
  window.addEventListener('offline', callback);

  return () => {
    window.removeEventListener('online', callback);
    window.removeEventListener('offline', callback);
  };
}

function useOnlineStatus() {
  return useSyncExternalStore(
    subscribe,
    () => navigator.onLine, // getSnapshot: read the browser value
    () => true              // getServerSnapshot: what the server should assume
  );
}

export default function StatusBar() {
  const isOnline = useOnlineStatus();
  return <p>{isOnline ? 'Online' : 'Offline'}</p>;
}

Why not just use useEffect and useState? Because this Hook also prevents a bug called tearing, where two parts of the screen show different values of the same data during a render.

Two rules to remember:

Define subscribe outside your component. If it's created inside, React will unsubscribe and subscribe again on every render.
getSnapshot must return the same value when nothing changed. If it returns a brand-new object every time, you will get an infinite loop.

In Next.js, getServerSnapshot is required if the component renders on the server.

useInsertionEffect

This one is built for people who write CSS-in-JS libraries. It runs before React changes the DOM, so a library can safely inject <style> tags at the right moment. If you build normal apps, you will probably never need it.

Here is the order in which the three effect Hooks run:

useInsertionEffect runs before React updates the DOM
useLayoutEffect runs after the DOM updates, before the browser paints
useEffect runs after the browser paints

'use client';

import { useInsertionEffect } from 'react';

export default function Highlight({ children }) {
  useInsertionEffect(() => {
    const style = document.createElement('style');
    style.textContent = '.highlight { background: yellow; }';
    document.head.appendChild(style);

    return () => document.head.removeChild(style);
  }, []);

  return <mark className="highlight">{children}</mark>;
}

Libraries like styled-components and Emotion already do this for you, so just use them.

useDebugValue

A tiny Hook that adds a label next to your custom Hook inside React DevTools. It only helps with debugging, and it only works inside custom Hooks.

import { useDebugValue, useSyncExternalStore } from 'react';

// "subscribe" is the same function from the previous example
function useOnlineStatus() {
  const isOnline = useSyncExternalStore(
    subscribe,
    () => navigator.onLine,
    () => true
  );

  useDebugValue(isOnline ? 'Online' : 'Offline');
  return isOnline;
}

Open DevTools, find the component that uses useOnlineStatus, and you will see the Online or Offline label right next to it.

New Hooks in React 19 and Later

React 19 was built around one idea: Actions. A few new Hooks make Actions easy to use, especially with forms. Then React 19.2 and 19.3 added a few more useful things on top.

What is an Action?
An Action is a function that changes something, usually by talking to a server. Submitting a form is the classic example. React runs it inside a transition, so it can track a pending state for you, and it updates the screen when the work is done.

useActionState

useActionState runs a function when a form is submitted and keeps track of the result. You get the latest result, a function to put on your form, and a isPending flag.

'use client';

import { useActionState } from 'react';

async function subscribe(previousState, formData) {
  const email = formData.get('email');

  // Pretend we are talking to a server
  await new Promise((resolve) => setTimeout(resolve, 1000));

  if (!email.includes('@')) {
    return { message: 'Please enter a valid email.' };
  }
  return { message: `Thanks! We will write to ${email}.` };
}

export default function NewsletterForm() {
  const [state, formAction, isPending] = useActionState(subscribe, {
    message: '',
  });

  return (
    <form action={formAction}>
      <input name="email" type="text" placeholder="you@example.com" />
      <button type="submit" disabled={isPending}>
        {isPending ? 'Sending...' : 'Subscribe'}
      </button>
      {state.message && <p>{state.message}</p>}
    </form>
  );
}

How it works:

You pass in your function and a starting state.
You put formAction on the form's action prop.
When the form is submitted, React calls your function with the previous state and the form data.
Whatever your function returns becomes the new state.

Notice that we don't need onSubmit, preventDefault or a useState for every input. React reads the form data for us.

Note: After the action finishes, React resets the form's fields. That's normal behavior in React 19.

In Next.js you can pass a Server Action instead. Put it in its own file with 'use server' at the top, then import it:

// app/actions.js
'use server';

export async function subscribe(previousState, formData) {
  // save to your database here
  return { message: 'Thanks for subscribing!' };
}

You might see the old name useFormState in older tutorials. It was renamed to useActionState.

useFormStatus

useFormStatus tells a component whether the form it sits inside is currently submitting. It's perfect for a submit button. You import it from react-dom, not from react.

'use client';

import { useFormStatus } from 'react-dom';

function SubmitButton() {
  const { pending } = useFormStatus();

  return (
    <button type="submit" disabled={pending}>
      {pending ? 'Saving...' : 'Save'}
    </button>
  );
}

async function saveProfile(formData) {
  await new Promise((resolve) => setTimeout(resolve, 1000));
  console.log('Saved:', formData.get('name'));
}

export default function ProfileForm() {
  return (
    <form action={saveProfile}>
      <input name="name" placeholder="Your name" />
      <SubmitButton />
    </form>
  );
}

Note: useFormStatus only works in a component that is rendered inside a <form>. If you call it in the same component that renders the <form>, pending will always be false. That's why the button is its own component here. The nice part is that you can reuse SubmitButton in every form in your app.

useOptimistic

What is Optimistic UI?
When you like a post on a social app, the heart turns red right away. It doesn't wait for the server. The app is being optimistic: it assumes the server will say yes, shows the result immediately, and fixes things later if something goes wrong.

useOptimistic gives you a temporary value that lasts only while an Action is running. When the Action finishes, React switches back to the real state.

'use client';

import { useOptimistic, useState, useTransition } from 'react';

async function saveLike() {
  // Pretend this is a slow server call
  await new Promise((resolve) => setTimeout(resolve, 1500));
}

export default function LikeButton() {
  const [likes, setLikes] = useState(0);
  const [, startTransition] = useTransition();

  const [optimisticLikes, addOptimisticLike] = useOptimistic(
    likes,
    (currentLikes, amount) => currentLikes + amount
  );

  function handleClick() {
    startTransition(async () => {
      addOptimisticLike(1);                // the screen updates instantly
      await saveLike();                    // the real work takes 1.5 seconds
      setLikes((current) => current + 1);  // now update the real state
    });
  }

  return <button onClick={handleClick}>Likes: {optimisticLikes}</button>;
}

Click the button and the number goes up right away, even though the "server" takes 1.5 seconds. Once the Action is done, React drops the temporary value and shows the real one, which is the same number, so nothing jumps. If the save fails, the temporary value disappears and the real number is shown again.

The setter (addOptimisticLike) must be called inside an Action, like inside startTransition or a form action. If you call it anywhere else, React will show you a warning.

Note: useOptimistic is a React Hook. It's not specific to Next.js, even though it works great with Server Actions.

use

use lets you read a resource while rendering. It works with two things: a promise and a context.

It looks like a Hook, but it has a special power: you can call it inside if statements and loops, and after an early return. Normal Hooks can't do that. The one place you can't use it is inside try / catch.

Reading a promise

The best pattern is to create the promise in a Server Component, pass it down, and wrap the client component in Suspense.

// app/page.js (a Server Component)
import { Suspense } from 'react';
import Comments from './comments';

export default function Page() {
  const commentsPromise = fetch(
    'https://jsonplaceholder.typicode.com/comments?_limit=5'
  ).then((res) => res.json());

  return (
    <Suspense fallback={<p>Loading comments...</p>}>
      <Comments commentsPromise={commentsPromise} />
    </Suspense>
  );
}

// app/comments.js
'use client';

import { use } from 'react';

export default function Comments({ commentsPromise }) {
  const comments = use(commentsPromise); // waits here until the data arrives

  return (
    <ul>
      {comments.map((comment) => (
        <li key={comment.id}>{comment.name}</li>
      ))}
    </ul>
  );
}

While the promise is loading, React shows the Suspense fallback. When it's ready, the component renders with the data. There is no useEffect, no loading state and no isLoading flag.

Note: Don't create a new promise inside a Client Component while rendering, and then pass it to use. It would create a fresh promise on every render. Create it in a Server Component, or use a library that caches it.

Reading context, even after an if

import { use } from 'react';
import { ThemeContext } from './theme-context';

function Heading({ children }) {
  if (children == null) {
    return null;
  }

  // useContext can't be called here, but use can
  const theme = use(ThemeContext);
  return <h1 className={theme}>{children}</h1>;
}

New in React 19.3: use(browser())

Some components can't make sensible HTML on the server, for example because they read the visitor's time zone. Calling use(browser()) tells React to skip this component during server rendering and show the nearest Suspense fallback instead. Once the page loads in the browser, it renders normally.

import { Suspense, use } from 'react';
import { browser } from 'react-dom';

function TimeZone() {
  use(browser());
  const timeZone = new Intl.DateTimeFormat().resolvedOptions().timeZone;

  return <p>{timeZone}</p>;
}

export default function App() {
  return (
    <Suspense fallback="Loading...">
      <TimeZone />
    </Suspense>
  );
}

Before 19.3, people did this with a mounted state and a useEffect. Now there is a proper way.

Note: In recent Next.js versions, the params prop of a page is a promise. In a Client Component page you read it with use:

'use client';

import { use } from 'react';

export default function Page({ params }) {
  const { slug } = use(params);
  return <h1>{slug}</h1>;
}

useEffectEvent

Needs React 19.2 or newer.

Here is a problem you will meet sooner or later. Your effect needs to read a value, but you don't want the effect to re-run when that value changes.

Imagine we log a page visit, and we also want to log how many items are in the cart:

'use client';

import { useEffect, useEffectEvent } from 'react';

function logVisit(url, numberOfItems) {
  console.log(`Visited ${url} with ${numberOfItems} items in the cart`);
}

export default function Page({ url, numberOfItems }) {
  // This function always sees the latest numberOfItems
  const onVisit = useEffectEvent((visitedUrl) => {
    logVisit(visitedUrl, numberOfItems);
  });

  useEffect(() => {
    onVisit(url);
  }, [url]); // only url here. No numberOfItems, no onVisit.

  return <h1>Page: {url}</h1>;
}

If we had put numberOfItems in the dependency array, the visit would be logged again every time the cart changes, which is wrong. If we left it out without useEffectEvent, the effect would read an old value. useEffectEvent solves both problems.

Rules to remember:

Only call an Effect Event from inside an effect.
Don't pass it to other components or Hooks.
Never put it in the dependency array.

Note: You might see useEvent in older blog posts. That was the early experimental name, and it never shipped in stable React. The real name is useEffectEvent.

Bonus: ViewTransition and Fragment Refs

React 19.3 made two more features stable. Neither of them is a Hook, but you will start seeing them in newer codebases, so here is a quick look.

ViewTransition

<ViewTransition> animates elements when they enter, exit or change, using the browser's View Transition API. By default you get a smooth cross-fade.

'use client';

import { ViewTransition, useState, startTransition } from 'react';

export default function Toggle() {
  const [show, setShow] = useState(false);

  return (
    <>
      <button
        onClick={() => {
          startTransition(() => {
            setShow((prev) => !prev);
          });
        }}
      >
        {show ? 'Hide' : 'Show'} card
      </button>

      {show && (
        <ViewTransition>
          <div className="card">Hello! I fade in and out.</div>
        </ViewTransition>
      )}
    </>
  );
}

React picks the animation based on what happened: enter (added), exit (removed), update (children changed) or share (a named one moved from one place to another).

The important rule: only updates marked as a Transition animate. That means state updates inside startTransition, a Suspense reveal, or an update from useDeferredValue. That's why we learned useTransition first. It currently works in the DOM only, not in React Native.

Fragment Refs

Before, you needed a wrapper <div> just to attach a ref to a group of elements. Now you can pass a ref straight to a <Fragment> and work with its DOM children as a group.

'use client';

import { Fragment, useRef } from 'react';

export default function Links() {
  const fragmentRef = useRef(null);

  return (
    <>
      <button onClick={() => fragmentRef.current.focus()}>
        Focus the first link
      </button>

      <Fragment ref={fragmentRef}>
        <a href="#one">One</a>
        <a href="#two">Two</a>
      </Fragment>
    </>
  );
}

The ref gives you a FragmentInstance with methods for events (addEventListener), focus (focus, focusLast, blur), observers (observeUsing) and scrolling (scrollIntoView). You must write <Fragment> in full. The short <> syntax can't take a ref.

Next.js Hooks

These Hooks don't come from React. They come from Next.js, and they work in the App Router (the app folder). Because they read browser and route information, they only work in Client Components, so put 'use client' at the top of the file.

Note: If you see import { useRouter } from 'next/router', that's the old Pages Router. In the App Router, always import from next/navigation.

useRouter

useRouter lets you change pages from your code, for example after a login. For normal links, use the <Link> component instead.

'use client';

import { useRouter } from 'next/navigation';

export default function LoginButton() {
  const router = useRouter();

  async function handleLogin() {
    // ...log the user in...
    router.push('/dashboard');
  }

  return <button onClick={handleLogin}>Log in</button>;
}

The router object has these methods:

router.push('/path') goes to a new page and adds it to the history
router.replace('/path') goes to a new page without adding to the history
router.back() and router.forward() move through the history
router.refresh() reloads the current route's data
router.prefetch('/path') loads a page in the background before the user clicks

usePathname

usePathname returns the current URL path, like /blog/my-post. A very common use is highlighting the active link in a navbar.

'use client';

import Link from 'next/link';
import { usePathname } from 'next/navigation';

const links = [
  { href: '/', label: 'Home' },
  { href: '/blog', label: 'Blog' },
];

export default function NavBar() {
  const pathname = usePathname();

  return (
    <nav>
      {links.map((link) => (
        <Link
          key={link.href}
          href={link.href}
          style={{ fontWeight: pathname === link.href ? 'bold' : 'normal' }}
        >
          {link.label}
        </Link>
      ))}
    </nav>
  );
}

useSearchParams

useSearchParams reads the query string, the part of the URL after the ?, like /products?sort=asc. It's read-only. To change it, build a new query string and navigate to it.

'use client';

import { usePathname, useRouter, useSearchParams } from 'next/navigation';

export default function SortButtons() {
  const searchParams = useSearchParams();
  const router = useRouter();
  const pathname = usePathname();

  const sort = searchParams.get('sort') ?? 'asc';

  function changeSort(value) {
    const params = new URLSearchParams(searchParams.toString());
    params.set('sort', value);
    router.push(`${pathname}?${params.toString()}`);
  }

  return (
    <>
      <p>Sorted by: {sort}</p>
      <button onClick={() => changeSort('asc')}>Ascending</button>
      <button onClick={() => changeSort('desc')}>Descending</button>
    </>
  );
}

Wrap the component that uses useSearchParams in a Suspense boundary. On a statically rendered page, the query string isn't known while building, so Next.js needs somewhere to show a fallback:

// app/products/page.js
import { Suspense } from 'react';
import SortButtons from './sort-buttons';

export default function Page() {
  return (
    <Suspense fallback={<p>Loading...</p>}>
      <SortButtons />
    </Suspense>
  );
}

Keeping filters and sorting in the URL is a great habit. Users can refresh the page or share the link and see the same result.

useParams

useParams reads the dynamic parts of the URL. If your file is app/blog/[slug]/page.js and the user visits /blog/react-hooks, then slug is react-hooks.

'use client';

import { useParams } from 'next/navigation';

export default function PostTitle() {
  const { slug } = useParams();
  return <h1>Reading: {slug}</h1>;
}

There is also useSelectedLayoutSegment, which tells a layout which child route is currently active. It's handy for tabs and sidebars.

useLinkStatus

useLinkStatus tells you if a <Link> is still loading its page. It's great for showing a small spinner right inside the link, so the user knows the click worked. You import it from next/link.

It must be used in a component that is rendered inside the <Link>, just like useFormStatus must be inside a <form>.

'use client';

import Link, { useLinkStatus } from 'next/link';

function Spinner() {
  const { pending } = useLinkStatus();
  return pending ? <span> ⏳</span> : null;
}

export default function NavLink({ href, children }) {
  return (
    <Link href={href}>
      {children}
      <Spinner />
    </Link>
  );
}

useServerInsertedHTML

Like useInsertionEffect, this one is for library authors, mainly CSS-in-JS libraries. It lets you insert HTML, like a <style> tag, into the page while it is being rendered on the server. You import it from next/navigation.

'use client';

import { useServerInsertedHTML } from 'next/navigation';

export default function FontStyles() {
  useServerInsertedHTML(() => (
    <style>{`body { font-family: Arial, sans-serif; }`}</style>
  ));

  return null;
}

If you build normal apps, you will almost never write this yourself.

Custom Hooks

A custom Hook is just a function whose name starts with use and that calls other Hooks inside it. That's the whole trick. You take logic that you copied into two components, move it into one function, and use it in both places.

Note: Each component that calls a custom Hook gets its own separate state. Two components using useToggle don't share the same value. They only share the code.

useToggle

The simplest example. It's a true/false switch with a function to flip it.

import { useCallback, useState } from 'react';

export function useToggle(initial = false) {
  const [on, setOn] = useState(initial);
  const toggle = useCallback(() => setOn((current) => !current), []);

  return [on, toggle];
}

'use client';

import { useToggle } from './use-toggle';

export default function Menu() {
  const [open, toggleOpen] = useToggle();

  return (
    <>
      <button onClick={toggleOpen}>Menu</button>
      {open && <nav>Home | Blog | Contact</nav>}
    </>
  );
}

useDebounce

It waits until the user stops typing before it gives you the new value. It's very useful before sending a search request.

import { useEffect, useState } from 'react';

export function useDebounce(value, delay = 400) {
  const [debounced, setDebounced] = useState(value);

  useEffect(() => {
    const timerId = setTimeout(() => setDebounced(value), delay);
    return () => clearTimeout(timerId); // cancel the old timer on every change
  }, [value, delay]);

  return debounced;
}

'use client';

import { useState } from 'react';
import { useDebounce } from './use-debounce';

export default function SearchBox() {
  const [query, setQuery] = useState('');
  const debouncedQuery = useDebounce(query, 500);

  // Use debouncedQuery in your fetch or effect. It changes only after
  // the user stops typing for half a second.
  return (
    <>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <p>Searching for: {debouncedQuery}</p>
    </>
  );
}

useDebounce waits for a fixed amount of time. useDeferredValue doesn't use a timer. It lets React decide based on how busy the screen is. Use debounce to slow down network requests, and useDeferredValue to keep heavy rendering smooth.

useFetch

Here is a fetch Hook with loading and error states, and a cleanup so an old request can't overwrite a newer one.

import { useEffect, useState } from 'react';

export function useFetch(url) {
  const [data, setData] = useState(null);
  const [error, setError] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    let ignore = false; // becomes true if the url changes or the component leaves

    setLoading(true);
    setError(null);

    fetch(url)
      .then((res) => {
        if (!res.ok) throw new Error('Request failed');
        return res.json();
      })
      .then((json) => {
        if (!ignore) setData(json);
      })
      .catch((err) => {
        if (!ignore) setError(err);
      })
      .finally(() => {
        if (!ignore) setLoading(false);
      });

    return () => {
      ignore = true;
    };
  }, [url]);

  return { data, error, loading };
}

'use client';

import { useFetch } from './use-fetch';

export default function Posts() {
  const { data, error, loading } = useFetch(
    'https://jsonplaceholder.typicode.com/posts?_limit=5'
  );

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Something went wrong.</p>;

  return (
    <ul>
      {data.map((post) => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  );
}

This is great for learning how Hooks fit together. In a real project, fetch in a Server Component, or use a library like TanStack Query or SWR. They handle caching, retries and much more.

The rules for custom Hooks are the same as for all Hooks:

The name must start with use, so React and your linter can recognize it.
Call Hooks only at the top level, never inside if, loops or nested functions.
Call Hooks only inside components or other custom Hooks.

Common Mistakes to Avoid

1. Calling a Hook after an early return or inside an if

React remembers your Hooks by the order they are called. If the order changes between renders, everything breaks.

// ❌ Wrong
function Profile({ user }) {
  if (!user) return null;
  const [name, setName] = useState(user.name); // Hook after an early return
}

// ✅ Right
function Profile({ user }) {
  const [name, setName] = useState(user?.name ?? '');
  if (!user) return null;
}

The one exception is use, which can be called conditionally.

2. Forgetting 'use client' in Next.js

If you use useState, useEffect or any browser-only Hook in a Server Component, you will see an error saying the Hook only works in a Client Component. Add 'use client' at the top of that file. Keep those files small, and only mark the interactive parts as client code, so the rest of your page stays on the server.

3. Using an effect to calculate something

If you can work it out during rendering, don't use state and an effect for it.

// ❌ Wrong: extra state, extra render
const [fullName, setFullName] = useState('');
useEffect(() => {
  setFullName(firstName + ' ' + lastName);
}, [firstName, lastName]);

// ✅ Right
const fullName = firstName + ' ' + lastName;

4. Infinite loops in effects

// ❌ Wrong: no dependency array, so this runs after every render
// and setCount triggers another render, forever
useEffect(() => {
  setCount(count + 1);
});

Another sneaky one: an object or array created during render is a new value every time, so an effect that depends on it re-runs on every render. Move it outside the component, or wrap it in useMemo.

5. Wrapping an input's setState in startTransition

Text inputs must update instantly. If you mark that update as low priority, the typing will lag or jump. Keep the input state urgent and use useDeferredValue for the slow part.

6. Calling useFormStatus in the same component as the form

It reads the status of a parent form. Put it in a child component, like the SubmitButton from earlier.

7. Creating a promise while rendering and passing it to use

A new promise is created on every render, so React starts over each time. Create the promise in a Server Component, or use a library that caches it.

8. Using useSearchParams without Suspense

It can cause a build error or turn your whole page into client-rendered content. Wrap the component that uses it in <Suspense>.

Cheatsheet

Keep this open while you code. It has every Hook from both parts.

Hook	What it does	Basic syntax
useState	Remembers a value	`const [state, setState] = useState(initial)`
useEffect	Runs side effects	`useEffect(() => {}, [deps])`
useContext	Reads shared data	`const value = useContext(MyContext)`
useRef	Holds a DOM element or a value that doesn't re-render	`const ref = useRef(null)`
useMemo	Remembers a calculated value	`const value = useMemo(() => compute(), [deps])`
useCallback	Remembers a function	`const fn = useCallback(() => {}, [deps])`
useReducer	Handles complex state logic	`const [state, dispatch] = useReducer(reducer, initial)`
useLayoutEffect	Measures the DOM before paint	`useLayoutEffect(() => {}, [deps])`
useImperativeHandle	Exposes methods to a parent	`useImperativeHandle(ref, () => ({ focus() {} }))`
useId	Creates a stable unique ID	`const id = useId()`
useTransition	Marks an update as low priority	`const [isPending, startTransition] = useTransition()`
useDeferredValue	Gives a lagging copy of a value	`const deferred = useDeferredValue(value)`
useSyncExternalStore	Reads data from outside React	`useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot)`
useInsertionEffect	Injects CSS (for library authors)	`useInsertionEffect(() => {}, [deps])`
useDebugValue	Adds a label in DevTools	`useDebugValue(value)`
useActionState	Tracks the result of a form action	`const [state, formAction, isPending] = useActionState(action, initial)`
useFormStatus	Reads the status of the parent form	`const { pending } = useFormStatus()`
useOptimistic	Shows a temporary value during an Action	`const [optimistic, setOptimistic] = useOptimistic(state, reducer)`
use	Reads a promise or a context	`const data = use(promise)`
useEffectEvent	Reads the latest values inside an effect (19.2+)	`const onEvent = useEffectEvent(() => {})`
useRouter	Navigates from code (Next.js)	`const router = useRouter()`
usePathname	Reads the current path (Next.js)	`const pathname = usePathname()`
useSearchParams	Reads the query string (Next.js)	`const searchParams = useSearchParams()`
useParams	Reads dynamic route params (Next.js)	`const { slug } = useParams()`
useLinkStatus	Knows if a Link is loading (Next.js)	`const { pending } = useLinkStatus()`
useServerInsertedHTML	Inserts HTML on the server (Next.js)	`useServerInsertedHTML(() => html)`

The rules in one place

Call Hooks at the top level of a component or a custom Hook. Never inside if, loops or nested functions.
Custom Hook names start with use.
Hooks with state or effects need 'use client' in Next.js.
If you can calculate it during render, skip the effect.
Always clean up timers and listeners.
Measure before you reach for useMemo and useCallback.

Conclusion

That's the full tour of React Hooks. Here is the short version of what to remember:

useState, useEffect and useContext cover most of what you will write every day.
useTransition and useDeferredValue keep your app smooth when updates get heavy.
useActionState, useFormStatus and useOptimistic make forms and instant feedback much simpler in React 19.
use and useEffectEvent remove a lot of old workarounds.
Next.js Hooks handle routing, and they only work in Client Components.
Custom Hooks let you write logic once and use it everywhere.

You don't need to memorize all of them. Learn the core ones well, and come back to the rest when you need them. That's what the cheatsheet is for.

If this guide helped you, leave a ❤️ or a 🦄, and share it with someone who is learning React. Questions, or a Hook I should explain better? Drop a comment below. Thanks for reading! 🙌

React Hooks Made Simple: The Complete Guide, Part-1

Abrar Galib — Thu, 24 Sep 2026 20:46:57 +0000

A Hook is a function that lets a component use a React feature. useState lets it remember a value. useEffect lets it do something after it shows up on the screen, like starting a timer. useContext lets it read shared data. Every Hook name starts with use, which makes them easy to spot.

Before Hooks, these features only worked inside class components, with constructors, this, and lifecycle methods like componentDidMount. Hooks give you the same abilities in a plain function, and the code comes out shorter and easier to follow.

Why Beginners Should Learn Hooks

Almost everything you'll read or write today uses them. The React docs, Next.js, and most libraries are built around function components, so classes are something you mostly see in old code. Hooks also remove a lot of boilerplate, since there are no classes, no constructors, and no binding methods. They make reuse easy too. If two components need the same behavior, you move it into a custom Hook once and use it in both. And the newest React features, like form Actions and optimistic updates, are built on Hooks, so learning them now means you're ready for those as well.

The Complete Guide

React Hooks changed how we write React apps. Before them, if a component needed state, or had to do something after it appeared on the screen, you had to write a class. Now a plain function can do all of that, and you can share the same logic between components without any tricks.

This guide covers all the stable React Hooks, from the basic ones to the newer ones that arrived with React 19. The examples use plain React and Next.js, and every Hook gets a short explanation plus code you can copy. If you're new, read it from the top. If you already know the basics, skip ahead to the section on new Hooks.

As of right now, the latest stable release is React 19.3, which dropped on September 9, 2026. This version finally makes ViewTransition and Fragment Refs stable. Even though neither of these is actually a Hook, I've covered both near the end of this guide since you'll definitely start seeing them pop up in newer codebases. Everything discussed below works perfectly fine on React 19, but if a specific Hook requires a newer minor version, I'll be sure to point it out.

The plan is simple. First the core Hooks, then the additional ones, then the advanced ones. After that come the Hooks added in React 19 and later, the Hooks that belong to Next.js, custom Hooks, common mistakes, and a cheatsheet you can keep open while you code.

What Are React Hooks?
Why Beginners Should Learn Hooks
Core Hooks
- useState
- useEffect
- useContext
Additional Hooks
- useRef
- useMemo
- useCallback
- useReducer
Advanced Hooks
- useLayoutEffect
- useImperativeHandle
- useId

Core Hooks

useState

useState simply lets your component remember data. When you use it, you get the current value and a function to change it.

What is a Render?

Think of a render as React refreshing or redrawing the screen. It is just React running your component function to see what should change visually.

How it works:

You call the function to update the data.
This tells React: "Hey, the data changed!"
React instantly renders (re-runs) the component to show the new data on your screen.

'use client';

import { useState } from 'react';

export default function LikeButton() {
  const [likes, setLikes] = useState(0);

  return (
    <button onClick={() => setLikes((current) => current + 1)}>
      Likes: {likes}
    </button>
  );
}

Notice how we use setLikes((current) => current + 1). When your new state depends on the old state, always pass a function like this. This ensures React always uses the absolute latest value, even if multiple updates happen at the exact same time.

Here are two important rules that beginners often miss:

Lazy Initialization (For heavy tasks): If setting up your starting value takes a lot of work (like reading from localStorage or filtering a huge list), don't run it directly inside useState. Instead, pass a function like useState(() => getHeavyData()). React will run this function only once on the very first render.
State Immutability (Never edit state directly): Never update an object or an array directly (like user.name = 'Alex'). React only checks if the overall object reference has changed. If you modify it directly, React won't notice the change and your screen won't update. Always make a fresh copy using the spread operator: setUser({ ...user, name: 'Alex' }).

Note: It's a good fit for counters, toggles, form inputs, and any small piece of UI state.

useEffect

useEffect is used for things that happen outside of the normal rendering process—like fetching data, starting timers, listening to the window, or using browser tools. React runs your effect right after the component shows up on the screen.

The list of brackets [] at the end is the dependency array. It simply tells React exactly when to run that code again.

What is Fetching?

Fetching just means asking a server or an external API for data over the internet (like getting a list of users, weather info, or product details) so you can show it on your app.

How it works:

Empty array []: Runs only once when the component first appears.
With values [props.id]: Runs again only when those specific values change.

'use client';

import { useEffect, useState } from 'react';

export default function WindowWidth() {
  const [width, setWidth] = useState(0);

  useEffect(() => {
    function handleResize() {
      setWidth(window.innerWidth);
    }

    handleResize();
    window.addEventListener('resize', handleResize);

    return () => window.removeEventListener('resize', handleResize);
  }, []);

  return <p>Window width: {width}px</p>;
}

Whatever you return inside useEffect is your cleanup function. React calls it right before running the effect again, and also when the component disappears from the screen.

Always clean up things like timers and event listeners. If you don't, they will keep running in the background and slow down your app (this is called a memory leak).

Why does my code run twice?

In development, React uses Strict Mode, which intentionally runs your effect twice. It does this just to test if your cleanup function is working properly. If you see your console.log appearing twice, that is exactly why!

Next.js detail: effects run only in the browser, never on the server. So the first HTML is built with your starting state, which is 0 here, and the effect fixes it once the page loads. A simple rule to follow is that if you can work something out while rendering, do it right there and skip the effect.

useContext

useContext reads shared data from the nearest provider above your component. It saves you from passing the same prop down through many layers, which people call prop drilling. Themes, the logged in user, and the language setting are the classic uses.

'use client';

import { createContext, useContext, useState } from 'react';

const ThemeContext = createContext({ theme: 'light', setTheme: () => {} });

export function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light');

  return (
    <ThemeContext value={{ theme, setTheme }}>
      {children}
    </ThemeContext>
  );
}

export function ThemeToggle() {
  const { theme, setTheme } = useContext(ThemeContext);

  return (
    <button onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>
      Current theme: {theme}
    </button>
  );
}

React 19 lets you use the context itself as the provider, so <ThemeContext value={...}> does the job of <ThemeContext.Provider value={...}>. Also remember that every component reading the context renders again when the value changes, so keep fast changing data out of one big shared context.

In the Next.js App Router, put the provider in a file that starts with 'use client', then wrap children with it inside layout.js. The pages inside can still be Server Components.

Additional Hooks

useRef

Think of useRef as a little storage box. It holds onto a value between renders, but changing that value never triggers a re-render (it won't refresh the screen).

Developers use it for two main things:

Grabbing a DOM element: Like directly focusing an input box or scrolling to a specific part of the page.
Holding background data: Like storing a timer ID or tracking how many times a user clicked a button without needing to change what is shown on the screen.

'use client';

import { useRef } from 'react';

export default function SearchBox() {
  const inputRef = useRef(null);

  return (
    <>
      <input ref={inputRef} placeholder="Search products" />
      <button onClick={() => inputRef.current.focus()}>Focus the box</button>
    </>
  );
}

In React 19 a function component can receive ref as a normal prop, so new code doesn't need forwardRef. Try not to read or write ref.current while rendering. Do it inside event handlers or effects.

useMemo

useMemo simply remembers the result of a heavy calculation so React doesn't have to do the math all over again on every render. It only recalculates when the data it depends on changes.

Think of it like this:

Use it for heavy work: Like filtering through thousands of users or sorting a massive list.
Skip it for small work: If you are just filtering 10 or 20 items, don't use it. The extra code overhead isn't worth it.

'use client';

import { useMemo, useState } from 'react';

export default function ProductSearch({ products }) {
  const [query, setQuery] = useState('');

  const matches = useMemo(() => {
    return products.filter((product) =>
      product.name.toLowerCase().includes(query.toLowerCase())
    );
  }, [products, query]);

  return (
    <>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <p>{matches.length} products found</p>
    </>
  );
}

useCallback

useCallback does the exact same job as useMemo, but for functions instead of calculation results.

Normally, React creates your functions completely fresh on every single render. If you pass that function down to a child component, the child thinks it received a brand-new prop and updates itself, even if nothing actually changed.

useCallback stops this by remembering the function between renders.

Why it matters:

Think of an item list (like a shopping basket) with an Add Button:

Without useCallback, typing a single letter in the search box re-creates the "add" function. This forces the Add Button to re-render needlessly.
With useCallback, the "add" function stays the same in memory. Typing in the input refreshes the basket, but the Add Button stays completely untouched, skipping unnecessary work.

'use client';

import { memo, useCallback, useState } from 'react';

const AddButton = memo(function AddButton({ onAdd }) {
  console.log('AddButton rendered');
  return <button onClick={onAdd}>Add one</button>;
});

export default function Basket() {
  const [count, setCount] = useState(0);
  const [note, setNote] = useState('');

  const handleAdd = useCallback(() => {
    setCount((current) => current + 1);
  }, []);

  return (
    <>
      <input value={note} onChange={(e) => setNote(e.target.value)} />
      <p>Items: {count}</p>
      <AddButton onAdd={handleAdd} />
    </>
  );
}

Don't add these two everywhere. They clutter the code, and measuring first saves you from fixing problems you don't have. Also, React Compiler has reached version 1.0 and is no longer experimental, and when you switch it on it adds this kind of memoization for you at build time. In newer projects you'll write useMemo and useCallback much less than older tutorials suggest.

useReducer

useReducer is great when you have a component with complex state logic, or when multiple pieces of state need to update together at the same time. Instead of having many scattered useState calls, it keeps all your state logic in one single place.

Here is how it works in two simple steps:

The Action: You tell React what happened by sending an action with a clear label, like "added", "deleted", or "cleared".
The Reducer: A special function (the reducer) looks at that label and handles the math to decide exactly what the new state should be.

'use client';

import { useReducer } from 'react';

function cartReducer(state, action) {
  switch (action.type) {
    case 'added':
      return [...state, action.item];
    case 'removed':
      return state.filter((item) => item.id !== action.id);
    case 'cleared':
      return [];
    default:
      throw new Error('Unknown action: ' + action.type);
  }
}

export default function Cart() {
  const [items, dispatch] = useReducer(cartReducer, []);

  return (
    <div>
      <button
        onClick={() =>
          dispatch({ type: 'added', item: { id: Date.now(), name: 'Book' } })
        }
      >
        Add book
      </button>
      <button onClick={() => dispatch({ type: 'cleared' })}>Clear</button>
      <p>{items.length} items in cart</p>
    </div>
  );
}

The reducer has to be a pure function. The same input always gives the same output, and it never fetches data or makes random values. That also makes it easy to test without rendering anything.

Advanced Hooks

useLayoutEffect

It looks exactly like useEffect, but runs earlier: right after React updates the DOM structure, but before the browser draws anything on the screen.

When to use: Use it only when you need to measure an element (like its height or width) and immediately change the UI based on that measurement. Using a normal useEffect here might cause a quick, annoying layout flicker.
Warning: It blocks the browser from drawing, so keep the code inside small. For everything else, stick to useEffect.

'use client';

import { useLayoutEffect, useRef, useState } from 'react';

export default function MeasuredBox({ children }) {
  const boxRef = useRef(null);
  const [height, setHeight] = useState(0);

  useLayoutEffect(() => {
    // Measures the exact height before the screen draws
    setHeight(boxRef.current.getBoundingClientRect().height);
  }, []);

  return (
    <div ref={boxRef}>
      {children}
      <small>Box height: {height}px</small>
    </div>
  );
}

useImperativeHandle

Normally, parents talk to child components via props. But sometimes, a parent needs to trigger a method inside the child directly (like calling .focus() or .clear() on a custom input). useImperativeHandle lets the child component expose specific functions to the parent through a ref.

Note: In React 19, ref is a normal prop, so you don't need forwardRef anymore.

'use client';

import { useImperativeHandle, useRef } from 'react';

function FancyInput({ ref }) {
  const inputRef = useRef(null);

  // Decide exactly what methods the parent can call
  useImperativeHandle(ref, () => ({
    focus() { inputRef.current.focus(); },
    clear() { inputRef.current.value = ''; }
  }));

  return <input ref={inputRef} />;
}

export default function Form() {
  const fancyRef = useRef(null);

  return (
    <>
      <FancyInput ref={fancyRef} />
      <button onClick={() => fancyRef.current.focus()}>Focus</button>
      <button onClick={() => fancyRef.current.clear()}>Clear</button>
    </>
  );
}

useId

This hook generates a unique, stable ID. It is essential for linking form fields with labels (htmlFor={id}).

Why use it? If you generate IDs with Math.random(), the server-rendered HTML and browser-rendered HTML won't match, causing Next.js to crash with a hydration mismatch error (Hydration is when React attaches itself to the server's HTML). useId keeps the ID identical on both sides.
Rule: Never use it to generate keys for item lists.

'use client';

import { useId } from 'react';

export default function EmailField() {
  const id = useId();

  return (
    <>
      <label htmlFor={id}>Email</label>
      <input id={id} type="email" />
    </>
  );
}