DEV Community: Hamed Farazi

React Mastery Series — Part 11: State Management in React — Context API, Redux Toolkit & Zustand

Hamed Farazi — Wed, 04 Nov 2026 10:20:54 +0000

Welcome to Part 11 and the final article of the React Mastery Series!

As React applications grow, managing state becomes one of the most important challenges developers face.

At first, useState is usually enough. But what happens when multiple components need access to the same data? What if you have authentication, shopping carts, themes, notifications, filters, or complex application workflows?

That's where state management comes in.

In this article, we'll explore the most important state management approaches in React:

React's built-in state management
Lifting state up and prop drilling
Context API
useReducer with Context
Redux Toolkit
Zustand
Best practices and common mistakes
How to choose the right solution

By the end, you'll understand when to use each approach and how to build maintainable state management for real-world applications.

1. Understanding State Management

State represents data that can change over time and affect what your application displays.

For example:

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

When count changes, React updates the components that depend on it.

However, not all state belongs in the same place.

Local State

Local state is used by a single component or a small group of closely related components.

Examples:

Input values
Dropdown visibility
Modal visibility
Selected tabs
Temporary form data

const [isOpen, setIsOpen] = useState(false);

Shared or Global Client State

Shared state is needed by multiple components across different parts of the application.

Examples:

Current theme
Shopping cart
Authentication UI state
User preferences
Global notifications

Server State

Server state represents data that comes from an external source, such as an API.

Examples:

User profiles
Product lists
Orders
Comments
Dashboard statistics

Server state has additional challenges:

Caching
Loading and error states
Refetching
Synchronization
Pagination
Stale data

Libraries such as TanStack Query and SWR are designed to handle these problems.

An important distinction:

Redux Toolkit, Zustand, and Context API can manage client-side application state. TanStack Query and SWR specialize in managing remote server data.

You don't necessarily need one tool to manage every kind of state.

2. React's Built-in State Management

Before installing an external library, understand the tools React already provides.

The most common options are:

useState
useReducer
useContext

useState

Use useState for simple state.

import { useState } from "react";

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

  return (
    <div>
      <h2>Count: {count}</h2>

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

export default Counter;

This is perfect when the state belongs to one component.

But what if several components need the same value?

That's where lifting state up becomes useful.

3. Lifting State Up and Prop Drilling

Imagine two components need access to the same username.

You can move the state to their closest common parent and pass it down through props.

function Parent() {
  const [username, setUsername] = useState("Alex");

  return (
    <>
      <Profile username={username} />
      <Welcome username={username} />
    </>
  );
}

function Profile({ username }: { username: string }) {
  return <h2>Profile: {username}</h2>;
}

function Welcome({ username }: { username: string }) {
  return <h2>Welcome, {username}!</h2>;
}

This technique is called lifting state up.

It works well for small component trees.

What Is Prop Drilling?

Prop drilling happens when you pass data through multiple components that don't actually need it.

function App() {
  const username = "Alex";

  return <Layout username={username} />;
}

function Layout({ username }: { username: string }) {
  return <Sidebar username={username} />;
}

function Sidebar({ username }: { username: string }) {
  return <UserProfile username={username} />;
}

function UserProfile({ username }: { username: string }) {
  return <h2>{username}</h2>;
}

As applications grow, this can become difficult to maintain.

One solution is Context API.

4. Context API

Context API is built into React and allows components to share values without passing props through every intermediate component.

It's useful for:

Themes
Authentication information
Language preferences
Application settings
Other relatively stable shared values

Step 1: Create a Context

import { createContext } from "react";

type ThemeContextValue = {
  theme: "light" | "dark";
  toggleTheme: () => void;
};

export const ThemeContext =
  createContext<ThemeContextValue | undefined>(undefined);

We use undefined as the default value so we can detect when a component is rendered outside its provider.

Step 2: Create a Provider

import {
  createContext,
  useCallback,
  useMemo,
  useState,
  type ReactNode,
} from "react";

type ThemeContextValue = {
  theme: "light" | "dark";
  toggleTheme: () => void;
};

const ThemeContext =
  createContext<ThemeContextValue | undefined>(undefined);

type ThemeProviderProps = {
  children: ReactNode;
};

export function ThemeProvider({
  children,
}: ThemeProviderProps) {
  const [theme, setTheme] = useState<"light" | "dark">("light");

  const toggleTheme = useCallback(() => {
    setTheme((current) =>
      current === "light" ? "dark" : "light"
    );
  }, []);

  const value = useMemo(
    () => ({ theme, toggleTheme }),
    [theme, toggleTheme]
  );

  return (
    <ThemeContext.Provider value={value}>
      {children}
    </ThemeContext.Provider>
  );
}

The useCallback and useMemo calls help keep the provider value stable when its dependencies haven't changed.

They don't prevent consumers from updating when the actual context value changes.

Step 3: Create a Custom Hook

import { useContext } from "react";

export function useTheme() {
  const context = useContext(ThemeContext);

  if (!context) {
    throw new Error(
      "useTheme must be used within ThemeProvider"
    );
  }

  return context;
}

This makes Context easier and safer to use.

Step 4: Use the Context

function ThemeButton() {
  const { theme, toggleTheme } = useTheme();

  return (
    <button onClick={toggleTheme}>
      Current theme: {theme}
    </button>
  );
}

Step 5: Wrap Your Application

import { ThemeProvider } from "./ThemeContext";

function App() {
  return (
    <ThemeProvider>
      <MainLayout />
    </ThemeProvider>
  );
}

Now any component inside ThemeProvider can access the theme.

Context API Limitations

Context is useful, but it isn't automatically a complete state management solution.

One important limitation is that consumers of a context can re-render when its provider value changes.

For larger applications, consider:

Splitting unrelated contexts into separate providers.
Keeping provider values stable when their dependencies haven't changed.
Avoiding putting frequently changing, unrelated data into one large context.
Using a state management library when you need more advanced subscriptions, selectors, or debugging tools.

Rule of thumb: Context is excellent for sharing values. It doesn't automatically provide all the features of a dedicated state management library.

5. useReducer with Context

When state becomes more complex, useReducer can provide a more structured approach than multiple useState calls.

A reducer receives the current state and an action, then returns the next state.

Example: Counter Reducer

import { useReducer } from "react";

type State = {
  count: number;
};

type Action =
  | { type: "increment" }
  | { type: "decrement" }
  | { type: "reset" };

const initialState: State = {
  count: 0,
};

function counterReducer(
  state: State,
  action: Action
): State {
  switch (action.type) {
    case "increment":
      return { count: state.count + 1 };

    case "decrement":
      return { count: state.count - 1 };

    case "reset":
      return initialState;

    default:
      return state;
  }
}

function Counter() {
  const [state, dispatch] = useReducer(
    counterReducer,
    initialState
  );

  return (
    <div>
      <h2>{state.count}</h2>

      <button onClick={() => dispatch({ type: "increment" })}>
        +
      </button>

      <button onClick={() => dispatch({ type: "decrement" })}>
        -
      </button>

      <button onClick={() => dispatch({ type: "reset" })}>
        Reset
      </button>
    </div>
  );
}

Instead of directly describing how to update state in every event handler, you dispatch actions describing what happened.

Combining useReducer with Context

You can expose both the state and dispatch function through Context.

import {
  createContext,
  useContext,
  useReducer,
  type ReactNode,
} from "react";

type State = {
  count: number;
};

type Action =
  | { type: "increment" }
  | { type: "decrement" };

function reducer(state: State, action: Action): State {
  switch (action.type) {
    case "increment":
      return { count: state.count + 1 };

    case "decrement":
      return { count: state.count - 1 };

    default:
      return state;
  }
}

const CounterStateContext = createContext<State | undefined>(
  undefined
);

const CounterDispatchContext =
  createContext<React.Dispatch<Action> | undefined>(undefined);

export function CounterProvider({
  children,
}: {
  children: ReactNode;
}) {
  const [state, dispatch] = useReducer(reducer, {
    count: 0,
  });

  return (
    <CounterStateContext.Provider value={state}>
      <CounterDispatchContext.Provider value={dispatch}>
        {children}
      </CounterDispatchContext.Provider>
    </CounterStateContext.Provider>
  );
}

export function useCounterState() {
  const context = useContext(CounterStateContext);

  if (!context) {
    throw new Error("useCounterState requires CounterProvider");
  }

  return context;
}

export function useCounterDispatch() {
  const context = useContext(CounterDispatchContext);

  if (!context) {
    throw new Error("useCounterDispatch requires CounterProvider");
  }

  return context;
}

Separating state and dispatch contexts can help components that only need to dispatch actions avoid subscribing to the changing state context.

However, components reading the state context still update when that context changes.

When should you use useReducer with Context?

When multiple components share structured state.
When updates involve several related actions.
When you want predictable update logic.
When you don't need the full ecosystem of an external library.

6. Redux Toolkit

Redux is a predictable state management library that centralizes application state in a store.

It is commonly used in large applications where predictable updates, debugging, middleware, and a mature ecosystem are important.

Today, Redux Toolkit (RTK) is the recommended approach for writing Redux logic.

It simplifies Redux and removes much of the repetitive code associated with older Redux patterns.

Install Redux Toolkit

npm install @reduxjs/toolkit react-redux

Redux Toolkit Core Concepts

Concept	Purpose
Store	Holds the application state
Slice	Defines a feature's state and reducers
Action	Describes something that happened
Reducer	Calculates the next state
Dispatch	Sends an action to the store
Selector	Reads data from the store

Step 1: Create a Slice

Imagine we're building a shopping cart.

// features/cart/cartSlice.ts

import {
  createSlice,
  type PayloadAction,
} from "@reduxjs/toolkit";

type CartItem = {
  id: number;
  name: string;
  price: number;
  quantity: number;
};

type CartState = {
  items: CartItem[];
};

const initialState: CartState = {
  items: [],
};

const cartSlice = createSlice({
  name: "cart",
  initialState,
  reducers: {
    addItem: (state, action: PayloadAction<CartItem>) => {
      const existing = state.items.find(
        (item) => item.id === action.payload.id
      );

      if (existing) {
        existing.quantity += action.payload.quantity;
      } else {
        state.items.push(action.payload);
      }
    },

    removeItem: (state, action: PayloadAction<number>) => {
      state.items = state.items.filter(
        (item) => item.id !== action.payload
      );
    },

    clearCart: (state) => {
      state.items = [];
    },
  },
});

export const {
  addItem,
  removeItem,
  clearCart,
} = cartSlice.actions;

export default cartSlice.reducer;

Notice that we're using syntax that looks like direct mutation:

existing.quantity += action.payload.quantity;

Why is this safe?

Redux Toolkit uses Immer internally. Immer tracks these changes and produces the next immutable state.

This behavior is safe inside Redux Toolkit's Immer-managed reducers. It does not mean you should mutate Redux state directly elsewhere.

Step 2: Configure the Store

// app/store.ts

import { configureStore } from "@reduxjs/toolkit";
import cartReducer from "../features/cart/cartSlice";

export const store = configureStore({
  reducer: {
    cart: cartReducer,
  },
});

export type RootState = ReturnType<typeof store.getState>;

export type AppDispatch = typeof store.dispatch;

The store combines your application's reducers and provides a central place for state.

Step 3: Provide the Store to React

// main.tsx

import React from "react";
import ReactDOM from "react-dom/client";
import { Provider } from "react-redux";
import { store } from "./app/store";
import App from "./App";

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

Step 4: Create Typed Redux Hooks

When using TypeScript, typed hooks make Redux much easier to work with.

// app/hooks.ts

import {
  useDispatch,
  useSelector,
  type TypedUseSelectorHook,
} from "react-redux";

import type {
  RootState,
  AppDispatch,
} from "./store";

export const useAppDispatch = () =>
  useDispatch<AppDispatch>();

export const useAppSelector: TypedUseSelectorHook<RootState> =
  useSelector;

Now your components can access the store with proper TypeScript support.

Step 5: Use Redux in Components

import {
  addItem,
  removeItem,
} from "./features/cart/cartSlice";

import {
  useAppDispatch,
  useAppSelector,
} from "./app/hooks";

function Cart() {
  const items = useAppSelector(
    (state) => state.cart.items
  );

  const dispatch = useAppDispatch();

  const total = items.reduce(
    (sum, item) => sum + item.price * item.quantity,
    0
  );

  return (
    <div>
      <h2>Shopping Cart</h2>

      {items.map((item) => (
        <div key={item.id}>
          <span>
            {item.name} x {item.quantity}
          </span>

          <button
            onClick={() => dispatch(removeItem(item.id))}
          >
            Remove
          </button>
        </div>
      ))}

      <h3>Total: ${total.toFixed(2)}</h3>

      <button
        onClick={() =>
          dispatch(
            addItem({
              id: 1,
              name: "Keyboard",
              price: 80,
              quantity: 1,
            })
          )
        }
      >
        Add Keyboard
      </button>
    </div>
  );
}

Handling Asynchronous Operations

Real applications often need to fetch data from APIs.

Redux Toolkit provides createAsyncThunk for managing asynchronous workflows.

import { createAsyncThunk } from "@reduxjs/toolkit";

type User = {
  id: number;
  name: string;
};

export const fetchUser = createAsyncThunk(
  "users/fetchUser",
  async (userId: number) => {
    const response = await fetch(
      `/api/users/${userId}`
    );

    if (!response.ok) {
      throw new Error("Failed to fetch user");
    }

    return (await response.json()) as User;
  }
);

You can handle the pending, fulfilled, and rejected states in the slice's extraReducers.

For applications with extensive API requirements, RTK Query is another excellent option. It is included in Redux Toolkit and provides API fetching, caching, and cache invalidation features.

When should you use Redux Toolkit?

Large applications
Complex shared state
Many independent features
Advanced debugging requirements
Middleware and predictable action flows
Teams that benefit from established conventions

7. Zustand

Zustand is a lightweight state management library for React.

It provides a simple API without requiring providers or a large amount of boilerplate.

It's especially useful when you want shared state with a straightforward developer experience.

Install Zustand

npm install zustand

Step 1: Create a Store

Let's create a simple counter store.

// stores/counterStore.ts

import { create } from "zustand";

type CounterState = {
  count: number;
  increment: () => void;
  decrement: () => void;
  reset: () => void;
};

export const useCounterStore = create<CounterState>(
  (set) => ({
    count: 0,

    increment: () =>
      set((state) => ({
        count: state.count + 1,
      })),

    decrement: () =>
      set((state) => ({
        count: state.count - 1,
      })),

    reset: () => set({ count: 0 }),
  })
);

Step 2: Use the Store

import { useCounterStore } from "./stores/counterStore";

function Counter() {
  const count = useCounterStore(
    (state) => state.count
  );

  const increment = useCounterStore(
    (state) => state.increment
  );

  const decrement = useCounterStore(
    (state) => state.decrement
  );

  return (
    <div>
      <h2>{count}</h2>

      <button onClick={increment}>+</button>
      <button onClick={decrement}>-</button>
    </div>
  );
}

No provider is required.

Why Use Selectors?

Notice this pattern:

const count = useCounterStore(
  (state) => state.count
);

A selector subscribes the component to the selected part of the store.

This can prevent unnecessary updates when unrelated parts of the store change.

Prefer selecting the specific values a component needs instead of subscribing to the entire store.

If you need to select multiple values as an object, consider Zustand's useShallow or an appropriate equality strategy to avoid unnecessary re-renders caused by newly created object references.

Zustand with TypeScript

The store above already uses a TypeScript interface to define its state and actions.

This makes it easier to maintain as the application grows.

You can also organize stores by domain:

src/
  stores/
    authStore.ts
    cartStore.ts
    themeStore.ts

Persisting State

Zustand provides a persist middleware for saving selected state across page reloads.

import { create } from "zustand";
import { persist } from "zustand/middleware";

type PreferencesState = {
  theme: "light" | "dark";
  setTheme: (theme: "light" | "dark") => void;
};

export const usePreferencesStore =
  create<PreferencesState>()(
    persist(
      (set) => ({
        theme: "light",

        setTheme: (theme) => set({ theme }),
      }),
      {
        name: "user-preferences",
      }
    )
  );

By default, this middleware uses browser storage where available.

Security note: Be careful about what you persist. Don't casually store sensitive information, authentication secrets, or access tokens in localStorage. Choose a storage strategy appropriate to your security requirements.

When Should You Use Zustand?

Small and medium-sized applications
Shared state with minimal boilerplate
Projects that don't need Redux's full ecosystem
Developers who prefer a simple store-based API
Applications that benefit from selector-based subscriptions

8. Practical Example: Building a Shopping Cart with Zustand

Let's put everything together.

We'll build a shopping cart with the following features:

Add products
Remove products
Update quantities
Calculate the total price

Step 1: Define the Types

// types.ts

export type Product = {
  id: number;
  name: string;
  price: number;
};

export type CartItem = {
  product: Product;
  quantity: number;
};

Step 2: Create the Cart Store

// stores/cartStore.ts

import { create } from "zustand";
import type { Product, CartItem } from "../types";

type CartState = {
  items: CartItem[];

  addItem: (product: Product) => void;
  removeItem: (id: number) => void;
  setQuantity: (id: number, quantity: number) => void;
  clearCart: () => void;
};

export const useCartStore = create<CartState>(
  (set) => ({
    items: [],

    addItem: (product) =>
      set((state) => {
        const existing = state.items.find(
          (item) => item.product.id === product.id
        );

        if (existing) {
          return {
            items: state.items.map((item) =>
              item.product.id === product.id
                ? {
                    ...item,
                    quantity: item.quantity + 1,
                  }
                : item
            ),
          };
        }

        return {
          items: [
            ...state.items,
            {
              product,
              quantity: 1,
            },
          ],
        };
      }),

    removeItem: (id) =>
      set((state) => ({
        items: state.items.filter(
          (item) => item.product.id !== id
        ),
      })),

    setQuantity: (id, quantity) =>
      set((state) => ({
        items:
          quantity <= 0
            ? state.items.filter(
                (item) => item.product.id !== id
              )
            : state.items.map((item) =>
                item.product.id === id
                  ? { ...item, quantity }
                  : item
              ),
      })),

    clearCart: () => set({ items: [] }),
  })
);

Step 3: Build the Product List

import type { Product } from "./types";
import { useCartStore } from "./stores/cartStore";

const products: Product[] = [
  { id: 1, name: "Keyboard", price: 80 },
  { id: 2, name: "Mouse", price: 40 },
  { id: 3, name: "Monitor", price: 250 },
];

function ProductList() {
  const addItem = useCartStore(
    (state) => state.addItem
  );

  return (
    <section>
      <h2>Products</h2>

      {products.map((product) => (
        <div key={product.id}>
          <span>
            {product.name} — ${product.price}
          </span>

          <button onClick={() => addItem(product)}>
            Add to Cart
          </button>
        </div>
      ))}
    </section>
  );
}

Step 4: Build the Cart Component

import { useCartStore } from "./stores/cartStore";

function ShoppingCart() {
  const items = useCartStore(
    (state) => state.items
  );

  const removeItem = useCartStore(
    (state) => state.removeItem
  );

  const setQuantity = useCartStore(
    (state) => state.setQuantity
  );

  const clearCart = useCartStore(
    (state) => state.clearCart
  );

  const total = items.reduce(
    (sum, item) =>
      sum + item.product.price * item.quantity,
    0
  );

  return (
    <section>
      <h2>Shopping Cart</h2>

      {items.length === 0 ? (
        <p>Your cart is empty.</p>
      ) : (
        items.map((item) => (
          <div key={item.product.id}>
            <h3>{item.product.name}</h3>

            <p>
              ${item.product.price} x {item.quantity}
            </p>

            <button
              onClick={() =>
                setQuantity(
                  item.product.id,
                  item.quantity - 1
                )
              }
            >
              -
            </button>

            <button
              onClick={() =>
                setQuantity(
                  item.product.id,
                  item.quantity + 1
                )
              }
            >
              +
            </button>

            <button
              onClick={() => removeItem(item.product.id)}
            >
              Remove
            </button>
          </div>
        ))
      )}

      <h3>Total: ${total.toFixed(2)}</h3>

      <button onClick={clearCart}>
        Clear Cart
      </button>
    </section>
  );
}

Step 5: Combine the Components

function App() {
  return (
    <main>
      <h1>My Store</h1>

      <ProductList />

      <hr />

      <ShoppingCart />
    </main>
  );
}

export default App;

That's it!

We've built a shared shopping cart without prop drilling or a provider component.

Notice that we calculate total from the cart items instead of storing it separately.

This is intentional.

If we stored both items and total, we would need to keep them synchronized after every change. Derived values are usually better calculated from their source data.

9. Context vs Redux Toolkit vs Zustand

How do these solutions compare?

Feature	Context API	useReducer + Context	Redux Toolkit	Zustand
Built into React	Yes	Yes	No	No
External dependency	No	No	Yes	Yes
Boilerplate	Low	Medium	Medium	Low
Centralized state	Possible	Possible	Yes	Yes
Selector subscriptions	No built-in selector system	No built-in selector system	Yes	Yes
DevTools ecosystem	Limited	Limited	Excellent	Available
Async workflows	Manual	Manual	Middleware / RTK Query	Manual or integrations
Best for	Shared values	Structured shared state	Complex applications	Lightweight shared state

Which One Should You Choose?

Context API

Choose Context when you need to share relatively stable values across a component tree.

useReducer + Context

Choose this when you need more structured update logic without installing another library.

Redux Toolkit

Choose this when your application has complex shared state, multiple feature domains, advanced debugging needs, or benefits from a mature ecosystem.

Zustand

Choose this when you want a lightweight global store with a simple API and selector-based subscriptions.

There is no universally best solution. The right choice depends on your application's complexity and requirements.

10. Server State vs Client State: Don't Mix Them Up

One common mistake is trying to manage API data in the same way as local UI state.

Imagine your application fetches a list of products.

You could store that list in Redux or Zustand, but then you may need to implement:

Loading states
Error handling
Cache expiration
Refetching
Request deduplication
Cache invalidation

These are server-state concerns.

A library such as TanStack Query handles many of them for you.

Example:

import { useQuery } from "@tanstack/react-query";

type Product = {
  id: number;
  name: string;
};

async function fetchProducts(): Promise<Product[]> {
  const response = await fetch("/api/products");

  if (!response.ok) {
    throw new Error("Failed to fetch products");
  }

  return response.json();
}

function Products() {
  const {
    data,
    isPending,
    isError,
  } = useQuery({
    queryKey: ["products"],
    queryFn: fetchProducts,
  });

  if (isPending) return <p>Loading...</p>;

  if (isError) return <p>Something went wrong.</p>;

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

A useful architecture might look like this:

React Application
│
├── Local UI State
│   └── useState
│
├── Complex Local State
│   └── useReducer
│
├── Shared Client State
│   ├── Context API
│   ├── Redux Toolkit
│   └── Zustand
│
└── Server State
    ├── TanStack Query
    ├── SWR
    └── RTK Query

The goal isn't to use as many libraries as possible.

The goal is to use the right tool for each kind of state.

11. State Management Best Practices

Here are some principles that help keep React applications maintainable.

1. Keep Local State Local

Don't put every input value or modal visibility flag into a global store.

If only one component needs the state, keep it there.

2. Avoid Unnecessary Global State

Global state creates shared dependencies.

Only promote state when multiple parts of the application genuinely need it.

3. Separate Server State from Client State

Use tools designed for API caching and synchronization when working with remote data.

4. Avoid Duplicate Sources of Truth

Don't store the same information in multiple places unless you have a clear synchronization strategy.

For example, calculate cart totals from cart items instead of storing both independently.

5. Use Selectors

With Redux Toolkit and Zustand, subscribe to only the data your component needs.

This can reduce unnecessary rendering.

6. Organize State by Feature

For larger projects, keep state logic close to the feature that owns it.

src/
  features/
    auth/
      authSlice.ts
      AuthPage.tsx

    cart/
      cartSlice.ts
      CartPage.tsx

    products/
      ProductsPage.tsx

  app/
    store.ts
    hooks.ts

7. Persist Only What You Need

Not every piece of application state should survive a page refresh.

Consider what actually needs persistence and whether the chosen storage mechanism is appropriate.

8. Don't Over-Engineer

A simple useState solution is often better than introducing a global state library too early.

Choose complexity only when your application needs it.

12. Common State Management Mistakes

Let's review some mistakes worth avoiding.

Mistake 1: Making Everything Global

Not every component needs access to the same state.

Mistake 2: Using Context for High-Frequency Updates Without Considering Performance

Context consumers can re-render when the provider value changes. For frequently changing shared data, consider the update patterns and whether a selector-based store would be more appropriate.

Mistake 3: Mutating State Directly

React state and Zustand updates should follow immutable update patterns. Redux Toolkit's reducers are a special case because Immer manages immutable updates for you.

Mistake 4: Storing Derived State

Avoid storing values that can easily be calculated from existing state.

Mistake 5: Confusing Server State with Client State

API caching and synchronization are different problems from managing a modal or theme preference.

Mistake 6: Choosing a Library Before Understanding the Problem

Don't introduce Redux or Zustand simply because another project uses them.

Understand the requirements first.

13. How to Choose the Right State Management Solution

Here's a practical decision guide:

Your Requirement	Recommended Solution
State used by one component	`useState`
Complex state transitions in one area	`useReducer`
Shared theme or application settings	Context API
Structured shared state without external dependencies	useReducer + Context
Large application with complex shared state	Redux Toolkit
Lightweight global state	Zustand
API data, caching, and synchronization	TanStack Query or SWR
API caching within a Redux application	RTK Query

Remember:

Start simple. Add a state management library when your application's requirements justify it.

14. Practice Challenge: Build a State-Managed Application

Now it's your turn!

Build a small e-commerce application with these features:

Required Features

A product list.
Add products to a shopping cart.
Remove products from the cart.
Increase and decrease product quantities.
Calculate the total price.
Toggle between light and dark themes.
Store theme preferences between page reloads.

Suggested Architecture

src/
  components/
    ProductList.tsx
    ShoppingCart.tsx
    ThemeToggle.tsx

  stores/
    cartStore.ts
    themeStore.ts

  types/
    index.ts

  App.tsx

Extra Challenges

Add product search.
Add category filters.
Fetch products from an API using TanStack Query.
Add authentication UI state.
Add a checkout flow.
Write tests for your store actions.

Try implementing the project with Zustand first.

Then rebuild the same application using Redux Toolkit.

Comparing both approaches is a great way to understand their differences.

15. Final Thoughts

State management is one of the most important skills for building scalable React applications.

Throughout this article, we explored:

React's built-in state tools
Lifting state up and prop drilling
Context API
useReducer with Context
Redux Toolkit
Zustand
Server state management
Practical state management patterns
Best practices and common mistakes

The most important lesson is that there is no single state management solution for every React application.

Start with React's built-in tools. Understand your application's requirements. Introduce external libraries when they solve a real problem.

Good state management isn't about using the most powerful library.

It's about keeping your application predictable, maintainable, and easy to understand.

React Mastery Series — Complete Learning Path

Congratulations! You've reached the final article of the React Mastery Series.

Here is the complete list of all 11 parts:

Part 1 — Introduction to React & Core Concepts
Part 2 — JSX, Components & Props
Part 3 — State & Event Handling in React
Part 4 — React Hooks: useState, useEffect & Custom Hooks
Part 5 — React Architecture & Best Practices
Part 6 — React Performance Optimization
Part 7 — Working with APIs & Data Fetching in React
Part 8 — React Testing: Unit, Integration & End-to-End Testing
Part 9 — React with TypeScript: Building Type-Safe Applications
Part 10 — React Router: Routing, Nested Routes & Navigation
Part 11 — State Management in React: Context API, Redux Toolkit & Zustand

This list represents the complete React Mastery Series learning path. Add links to the individual articles as they are published so readers can navigate through the entire series.

Thank You for Following the React Mastery Series!

If you've made it through all 11 parts, you've covered a substantial part of the React development journey.

Keep practicing, build real projects, read documentation, and experiment with different architectural approaches.

The best way to master React is to keep building.

Happy Coding! 🚀

React #JavaScript #WebDevelopment #Frontend #Redux #Zustand #TypeScript #ReactJS #Programming #Beginners

React Mastery Series — Part 10: React Router — Routing, Nested Routes & Navigation

Hamed Farazi — Wed, 04 Nov 2026 10:16:58 +0000

So far, we've built React applications using components, props, state, Hooks, and TypeScript.

But most real-world applications have more than one page.

Think about an e-commerce application:

/ — Home page
/products — Product listing
/products/42 — Product details
/cart — Shopping cart
/login — Login page
/dashboard — User dashboard

How can we navigate between these pages without reloading the entire application?

The answer is React Router.

React Router is a routing library that allows React applications to display different components based on the current URL.

In this guide, we'll learn how to configure React Router, create dynamic routes, build nested layouts, protect routes, navigate programmatically, and handle common routing scenarios.

Let's get started!

1. What Is React Router?

React Router connects URLs to React components.

For example:

/                 → HomePage
/about            → AboutPage
/products         → ProductsPage
/products/42      → ProductDetailsPage
/contact          → ContactPage

When a user visits a URL, React Router matches it against your route definitions and renders the appropriate component.

Without a routing library, you would need to manually manage URL changes, browser history, and conditional rendering.

React Router handles these responsibilities for you.

Why Use React Router?

Some important benefits include:

Client-side navigation without full-page reloads.
Dynamic route parameters.
Nested routes and shared layouts.
Browser back and forward navigation.
URL-based application state.
Navigation links and redirects.
Route-level loading and error handling.

2. Installing React Router

For a new React application, you can start with Vite:

npm create vite@latest my-react-app -- --template react
cd my-react-app
npm install

Install React Router:

npm install react-router

For current React Router declarative examples, we'll import the APIs from react-router.

If you're maintaining an older project that uses react-router-dom, check its version-specific documentation before mixing APIs. React Router's package organization has evolved across major versions.

3. Creating Your First Routes

Let's create a basic application with three pages:

Home
About
Contact

First, create the page components.

HomePage.jsx

function HomePage() {
  return <h1>Welcome to the Home Page</h1>;
}

export default HomePage;

AboutPage.jsx

function AboutPage() {
  return <h1>About Us</h1>;
}

export default AboutPage;

ContactPage.jsx

function ContactPage() {
  return <h1>Contact Us</h1>;
}

export default ContactPage;

Now configure the router in App.jsx:

import {
  BrowserRouter,
  Routes,
  Route
} from "react-router";

import HomePage from "./pages/HomePage";
import AboutPage from "./pages/AboutPage";
import ContactPage from "./pages/ContactPage";

function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<HomePage />} />
        <Route path="/about" element={<AboutPage />} />
        <Route path="/contact" element={<ContactPage />} />
      </Routes>
    </BrowserRouter>
  );
}

export default App;

Let's understand the main components.

BrowserRouter

BrowserRouter enables client-side routing using the browser's History API.

It provides routing context to the components inside it.

Routes

Routes contains your route definitions.

React Router matches the current URL against the available routes.

Route

Each Route connects a URL pattern to a React element.

For example:

<Route path="/about" element={<AboutPage />} />

When the URL matches /about, React Router renders AboutPage.

4. Navigation with Link

You could use a normal HTML anchor:

<a href="/about">About</a>

However, a regular anchor performs a full browser navigation.

For client-side navigation, use React Router's Link component.

import { Link } from "react-router";

function Navbar() {
  return (
    <nav>
      <Link to="/">Home</Link>
      <Link to="/about">About</Link>
      <Link to="/contact">Contact</Link>
    </nav>
  );
}

export default Navbar;

The Link component changes the URL and lets React Router render the matching route without a full-page reload.

Active Navigation with NavLink

Sometimes you want to style the current navigation item.

Use NavLink:

import { NavLink } from "react-router";

function Navbar() {
  return (
    <nav>
      <NavLink
        to="/"
        className={({ isActive }) =>
          isActive ? "active" : ""
        }
        end
      >
        Home
      </NavLink>

      <NavLink to="/about">
        About
      </NavLink>

      <NavLink to="/contact">
        Contact
      </NavLink>
    </nav>
  );
}

NavLink provides an isActive value that tells you whether the link matches the current route.

The end prop makes the home link match only the exact / route.

5. Dynamic Routes and URL Parameters

Real applications often need dynamic URLs.

For example:

/products/1
/products/2
/products/3

Creating a separate route for every product would be impractical.

Instead, define a dynamic route:

<Route
  path="/products/:productId"
  element={<ProductDetails />}
/>

The :productId section represents a URL parameter.

Now use useParams to access it:

import { useParams } from "react-router";

function ProductDetails() {
  const { productId } = useParams();

  return (
    <div>
      <h1>Product Details</h1>
      <p>Product ID: {productId}</p>
    </div>
  );
}

export default ProductDetails;

When the user visits:

/products/42

The component receives:

productId === "42"

Remember that URL parameters are strings, even when they contain numbers.

If you need a number, validate and convert it:

const id = Number(productId);

if (!Number.isInteger(id)) {
  return <p>Invalid product ID</p>;
}

6. Using URL Parameters to Fetch Data

Let's make the product details page more realistic.

import { useEffect, useState } from "react";
import { useParams } from "react-router";

function ProductDetails() {
  const { productId } = useParams();

  const [product, setProduct] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState("");

  useEffect(() => {
    const controller = new AbortController();

    async function loadProduct() {
      try {
        setLoading(true);
        setError("");

        const response = await fetch(
          `/api/products/${productId}`,
          { signal: controller.signal }
        );

        if (!response.ok) {
          throw new Error("Product not found");
        }

        const data = await response.json();

        setProduct(data);
      } catch (err) {
        if (err.name !== "AbortError") {
          setError(err.message || "Something went wrong");
        }
      } finally {
        if (!controller.signal.aborted) {
          setLoading(false);
        }
      }
    }

    loadProduct();

    return () => controller.abort();
  }, [productId]);

  if (loading) return <p>Loading product...</p>;
  if (error) return <p>{error}</p>;
  if (!product) return <p>Product not found.</p>;

  return (
    <article>
      <h1>{product.name}</h1>
      <p>${product.price}</p>
      <p>{product.description}</p>
    </article>
  );
}

export default ProductDetails;

This example demonstrates:

Reading a dynamic URL parameter.
Fetching data based on that parameter.
Displaying loading and error states.
Cancelling outdated requests when the route changes or the component unmounts.

For more complex applications, React Router's data APIs or a data-fetching library can handle these responsibilities more cleanly.

7. Nested Routes

Nested routes are useful when several pages share the same layout.

Imagine a dashboard with:

/dashboard
/dashboard/profile
/dashboard/settings
/dashboard/orders

All these pages should share a sidebar and header.

Instead of repeating the layout in every page, define a parent route.

DashboardLayout.jsx

import { Link, Outlet } from "react-router";

function DashboardLayout() {
  return (
    <div className="dashboard">
      <aside>
        <h2>Dashboard</h2>

        <nav>
          <Link to="/dashboard">Overview</Link>
          <Link to="/dashboard/profile">Profile</Link>
          <Link to="/dashboard/settings">Settings</Link>
          <Link to="/dashboard/orders">Orders</Link>
        </nav>
      </aside>

      <main>
        <Outlet />
      </main>
    </div>
  );
}

export default DashboardLayout;

The important part is:

<Outlet />

Outlet renders the matching child route inside the parent layout.

Now configure the nested routes:

import {
  BrowserRouter,
  Routes,
  Route
} from "react-router";

function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route
          path="/dashboard"
          element={<DashboardLayout />}
        >
          <Route
            index
            element={<DashboardHome />}
          />

          <Route
            path="profile"
            element={<ProfilePage />}
          />

          <Route
            path="settings"
            element={<SettingsPage />}
          />

          <Route
            path="orders"
            element={<OrdersPage />}
          />
        </Route>
      </Routes>
    </BrowserRouter>
  );
}

Notice that child paths don't begin with /.

React Router combines them with the parent path.

For example:

Parent: /dashboard
Child:  profile

Result: /dashboard/profile

What Is an Index Route?

An index route is the default child page rendered when the parent route matches exactly.

<Route index element={<DashboardHome />} />

This means DashboardHome appears at /dashboard.

8. Programmatic Navigation with useNavigate

Sometimes navigation needs to happen after an action.

For example:

After a successful login.
After submitting a form.
After deleting an item.
After completing a checkout.

Use the useNavigate Hook.

import { useNavigate } from "react-router";

function LoginPage() {
  const navigate = useNavigate();

  function handleLogin() {
    // Perform authentication here.

    navigate("/dashboard");
  }

  return (
    <button onClick={handleLogin}>
      Login
    </button>
  );
}

Replace the Current History Entry

You can replace the current history entry:

navigate("/dashboard", { replace: true });

This is useful when users shouldn't return to the previous page using the browser's back button, such as after certain authentication transitions.

Navigate Back

navigate(-1);

This moves back one entry in the browser history.

Be careful: the user may not have a previous application page to return to.

9. Passing State During Navigation

Sometimes you need to pass temporary data to another route.

For example:

import { useNavigate } from "react-router";

function ProductsPage() {
  const navigate = useNavigate();

  function openProduct() {
    navigate("/products/42", {
      state: {
        from: "featured-products"
      }
    });
  }

  return (
    <button onClick={openProduct}>
      View Product
    </button>
  );
}

Read the state in the destination component:

import { useLocation } from "react-router";

function ProductDetails() {
  const location = useLocation();

  const source = location.state?.from;

  return (
    <div>
      <h1>Product Details</h1>
      <p>Navigation source: {source || "Direct visit"}</p>
    </div>
  );
}

Navigation state is useful for temporary navigation context.

However, it is not a replacement for URL parameters or persistent storage.

A user may open the destination URL directly, in which case the navigation state may not exist.

10. Working with Query Parameters

URL parameters and query parameters are different.

A route parameter is part of the route path:

/products/42

A query parameter appears after ?:

/products?category=electronics&sort=price

Use useSearchParams to read and update query parameters.

import { useSearchParams } from "react-router";

function ProductsPage() {
  const [searchParams, setSearchParams] = useSearchParams();

  const category = searchParams.get("category") || "all";
  const sort = searchParams.get("sort") || "default";

  function updateCategory(event) {
    setSearchParams({
      category: event.target.value,
      sort
    });
  }

  return (
    <div>
      <h1>Products</h1>

      <select
        value={category}
        onChange={updateCategory}
      >
        <option value="all">All</option>
        <option value="electronics">Electronics</option>
        <option value="clothing">Clothing</option>
      </select>

      <p>Current sort: {sort}</p>
    </div>
  );
}

Query parameters are particularly useful for:

Search filters.
Sorting.
Pagination.
Category selection.
Shareable application states.

Because they're part of the URL, users can bookmark or share the current filtered view.

11. Protected Routes

Many applications have pages that should only be available to authenticated users.

Examples include:

Dashboard.
Account settings.
Order history.
Admin pages.

A simple protected route component can check whether the user is authenticated.

import { Navigate, Outlet } from "react-router";

function ProtectedRoute({ isAuthenticated }) {
  if (!isAuthenticated) {
    return <Navigate to="/login" replace />;
  }

  return <Outlet />;
}

Configure it:

<Routes>
  <Route path="/login" element={<LoginPage />} />

  <Route element={<ProtectedRoute isAuthenticated={true} />}>
    <Route path="/dashboard" element={<DashboardPage />} />
    <Route path="/settings" element={<SettingsPage />} />
  </Route>
</Routes>

In a real application, isAuthenticated should come from your authentication system or application state.

You might also want to preserve the page the user originally requested:

function ProtectedRoute({ isAuthenticated }) {
  const location = useLocation();

  if (!isAuthenticated) {
    return (
      <Navigate
        to="/login"
        state={{ from: location }}
        replace
      />
    );
  }

  return <Outlet />;
}

After login, you can navigate back to the requested page.

Important Security Note

A protected React route is only a user-interface restriction.

It does not secure your backend.

Your API must independently verify authentication and authorization for every protected operation. Never rely on client-side route checks to protect sensitive data.

12. Handling 404 Pages

What happens when a user visits a URL that doesn't match any route?

You should show a custom not-found page.

Create a component:

function NotFoundPage() {
  return (
    <div>
      <h1>404</h1>
      <p>Sorry, the page you're looking for doesn't exist.</p>
    </div>
  );
}

Add a wildcard route:

<Routes>
  <Route path="/" element={<HomePage />} />
  <Route path="/about" element={<AboutPage />} />
  <Route path="/contact" element={<ContactPage />} />

  <Route path="*" element={<NotFoundPage />} />
</Routes>

The wildcard path matches URLs that don't match another route.

This creates a better user experience than leaving users on a blank page.

13. Layout Routes

A layout route allows several pages to share a common interface.

For example, an application might have:

A public layout with a navbar and footer.
An authenticated layout with a sidebar.
An admin layout with administrative navigation.

A public layout could look like this:

import { Outlet } from "react-router";

function MainLayout() {
  return (
    <>
      <header>
        <h1>My Application</h1>
      </header>

      <main>
        <Outlet />
      </main>

      <footer>
        <p>Copyright 2026</p>
      </footer>
    </>
  );
}

Configure it:

<Routes>
  <Route element={<MainLayout />}>
    <Route path="/" element={<HomePage />} />
    <Route path="/about" element={<AboutPage />} />
    <Route path="/contact" element={<ContactPage />} />
  </Route>
</Routes>

The layout remains mounted while the child route changes, allowing shared UI to stay consistent.

14. React Router with TypeScript

If you're using TypeScript, you can type route parameters and component props.

For example:

import { useParams } from "react-router";

function ProductDetails() {
  const { productId } = useParams<"productId">();

  if (!productId) {
    return <p>Product ID is missing.</p>;
  }

  return <h1>Product ID: {productId}</h1>;
}

The generic parameter describes the name of the route parameter. It does not guarantee that the URL contains a valid product ID.

You still need to validate and convert it when necessary:

const id = Number(productId);

if (!Number.isInteger(id) || id <= 0) {
  return <p>Invalid product ID.</p>;
}

For navigation state, define an explicit type:

type NavigationState = {
  from?: string;
};

Then validate or narrow the state when reading it, because navigation state may be absent or may not have the shape you expect.

15. Data Routers: Loaders and Actions

React Router also provides a data-router approach.

Instead of fetching data inside every component with useEffect, you can define a loader for a route.

A loader runs as part of route navigation and provides data to the route component.

Example:

import {
  createBrowserRouter,
  RouterProvider,
  useLoaderData
} from "react-router";

async function productLoader({ params }) {
  const response = await fetch(
    `/api/products/${params.productId}`
  );

  if (!response.ok) {
    throw new Response("Product not found", {
      status: 404
    });
  }

  return response.json();
}

function ProductDetails() {
  const product = useLoaderData();

  return (
    <article>
      <h1>{product.name}</h1>
      <p>${product.price}</p>
    </article>
  );
}

Create the router:

const router = createBrowserRouter([
  {
    path: "/products/:productId",
    element: <ProductDetails />,
    loader: productLoader
  }
]);

function App() {
  return <RouterProvider router={router} />;
}

This is a simplified example. In production, validate the loader's external data and handle route errors appropriately.

What Are Actions?

Actions handle mutations associated with route navigation, such as:

Creating a product.
Updating a profile.
Submitting a form.
Deleting an item.

They can work with React Router's <Form> component and route data APIs.

A simplified action:

async function contactAction({ request }) {
  const formData = await request.formData();

  const email = formData.get("email");

  const response = await fetch("/api/contact", {
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify({ email })
  });

  if (!response.ok) {
    throw new Response("Unable to submit form", {
      status: response.status
    });
  }

  return { success: true };
}

Data routers are especially useful when your application has complex route-based data loading and mutations.

16. Handling Route Errors

Data routers support route-level error boundaries.

You can define an ErrorBoundary for a route:

import { isRouteErrorResponse, useRouteError } from "react-router";

function RouteErrorBoundary() {
  const error = useRouteError();

  if (isRouteErrorResponse(error)) {
    return (
      <div>
        <h1>{error.status}</h1>
        <p>{error.statusText}</p>
      </div>
    );
  }

  return (
    <div>
      <h1>Something went wrong</h1>
      <p>Please try again later.</p>
    </div>
  );
}

Attach it to a route:

{
  path: "/products/:productId",
  loader: productLoader,
  element: <ProductDetails />,
  ErrorBoundary: RouteErrorBoundary
}

This lets you show useful error UI when a loader or route rendering fails.

For production applications, you should also log unexpected errors and provide a way for users to recover.

17. Common React Router Mistakes

Here are some mistakes worth avoiding.

Mistake 1: Using Anchor Tags for Every Internal Link

Avoid:

<a href="/about">About</a>

Prefer:

<Link to="/about">About</Link>

Use regular anchors for external URLs or situations where a full document navigation is intended.

Mistake 2: Forgetting Outlet in Nested Layouts

If a parent route uses child routes but doesn't render <Outlet />, the child content won't appear inside that layout.

Mistake 3: Treating URL Parameters as Numbers

Remember:

const { productId } = useParams();

Returns a string or undefined, not a number.

Validate and convert the value before using it as a numeric identifier.

Mistake 4: Using Navigation State as Permanent Data

Navigation state is temporary context.

Use route parameters, query parameters, or persistent storage when data needs to survive direct visits or page reloads.

Mistake 5: Treating Protected Routes as Backend Security

Client-side route protection is not authentication security.

Your backend must verify permissions independently.

Mistake 6: Forgetting Server Configuration

In production, a client-side application may need server configuration so that direct requests to routes such as /products/42 return the application's entry HTML.

Without a proper fallback, refreshing a nested route may produce a server-side 404 even though client-side navigation works.

18. Recommended Project Structure

As your application grows, organizing route definitions and page components becomes important.

A practical structure could look like this:

src/
├── components/
│   ├── Navbar.jsx
│   └── Footer.jsx
├── layouts/
│   ├── MainLayout.jsx
│   └── DashboardLayout.jsx
├── pages/
│   ├── HomePage.jsx
│   ├── AboutPage.jsx
│   ├── ProductsPage.jsx
│   ├── ProductDetails.jsx
│   ├── LoginPage.jsx
│   └── NotFoundPage.jsx
├── routes/
│   └── router.jsx
├── services/
│   └── productApi.js
├── App.jsx
└── main.jsx

For larger projects, keep route configuration separate from individual page components.

This makes the routing system easier to understand and maintain.

19. Best Practices

Here are some recommendations for building maintainable routing systems:

Use Link and NavLink for internal navigation.
Keep route definitions organized.
Use nested routes for shared layouts.
Use dynamic parameters for resource-specific pages.
Use query parameters for filters, sorting, and pagination.
Validate URL parameters before using them.
Use navigation state only for temporary context.
Handle unknown routes with a 404 page.
Use route-level error handling for data routers.
Protect sensitive operations on the backend.
Configure your production server for client-side route fallback.
Choose declarative routing or data routers based on your application's needs.

20. Practice Project: Build a Small E-Commerce Router

Now it's your turn to put these concepts together.

Build a small e-commerce application with the following routes:

Route	Page
`/`	Home
`/products`	Product list
`/products/:productId`	Product details
`/cart`	Shopping cart
`/login`	Login
`/dashboard`	Protected dashboard
`*`	Not found

Your application should include:

A navigation bar.
Dynamic product detail pages.
Product category filters using query parameters.
A shared dashboard layout.
A protected dashboard route.
A custom 404 page.
Browser back and forward navigation.

Challenge: Add a product search field that updates the URL query parameters so users can share their search results.

Final Thoughts

React Router is an essential tool for building modern React applications.

It gives your application a clear navigation structure and makes it possible to build complex interfaces with multiple pages, shared layouts, and dynamic content.

Start with basic routes and Link.

Then learn dynamic parameters, nested layouts, and navigation state.

Finally, explore loaders, actions, and route-level error handling when your application needs more advanced data management.

Remember: good routing isn't just about changing URLs. It's about creating a predictable navigation experience for your users.

What's Next?

In Part 11: State Management in React — Context API, Redux Toolkit & Zustand, we'll explore how to manage shared application state as React projects become larger.

We'll cover:

Local state vs global state
React Context API
Prop drilling and how to avoid it
Redux Toolkit fundamentals
Zustand for lightweight state management
Managing asynchronous state
Choosing the right state management solution

Keep learning, keep building, and see you in the next part! 🚀

React Mastery Series — Part 9: React with TypeScript — Building Type-Safe Applications

Hamed Farazi — Wed, 04 Nov 2026 09:56:36 +0000

As React applications grow, keeping track of component props, state, API responses, and shared data becomes increasingly difficult.

JavaScript gives developers flexibility, but that flexibility can also lead to runtime errors that are difficult to catch before users encounter them.

This is where TypeScript comes in.

TypeScript adds a static type system to JavaScript. It helps identify mistakes during development, improves editor autocomplete, and makes refactoring safer.

In this guide, we'll learn how to use TypeScript effectively in React applications, from basic component props to advanced generics and API data validation.

By the end, you'll be able to build React components that are easier to understand, maintain, and scale.

1. Why Use TypeScript with React?

TypeScript provides several advantages:

Catch errors earlier: Detect incorrect prop values and incompatible types before running your application.
Better autocomplete: Get useful suggestions for component props, state, and function arguments.
Safer refactoring: Rename properties and update function signatures with more confidence.
Clearer contracts: Make it easier to understand what a component expects and returns.
Improved collaboration: Help teammates understand how different parts of an application work together.

Consider this JavaScript component:

function UserProfile({ user }) {
  return <h2>{user.name}</h2>;
}

What happens if someone passes a string instead of a user object?

JavaScript won't catch the problem until runtime.

With TypeScript:

type User = {
  id: number;
  name: string;
  email: string;
};

type UserProfileProps = {
  user: User;
};

function UserProfile({ user }: UserProfileProps) {
  return <h2>{user.name}</h2>;
}

Now TypeScript can detect incorrect usage before the application runs.

Important: TypeScript does not validate data at runtime. Its types are removed during compilation, so external data—such as API responses—still needs runtime validation.

2. Setting Up a React + TypeScript Project

The easiest way to start a new React TypeScript application is with Vite.

Run:

npm create vite@latest my-react-app -- --template react-ts

Then install dependencies:

cd my-react-app
npm install
npm run dev

Your project will contain files similar to:

my-react-app/
├── src/
│   ├── App.tsx
│   ├── main.tsx
│   ├── index.css
│   └── assets/
├── public/
├── package.json
├── tsconfig.json
└── vite.config.ts

`.tsx` vs `.ts`

Use:

.tsx for TypeScript files that contain JSX.
.ts for TypeScript files without JSX.

Examples:

Button.tsx
UserProfile.tsx
useProducts.ts
api.ts
types.ts

Understanding `tsconfig.json`

The TypeScript configuration file controls how TypeScript checks and compiles your code.

Some important options include:

{
  "compilerOptions": {
    "strict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noFallthroughCasesInSwitch": true
  }
}

This is an illustration of useful compiler options, not a complete replacement for Vite's generated configuration.

The most important option is:

"strict": true

It enables a collection of stricter type-checking rules and helps prevent many common mistakes.

For most React projects, keeping strict mode enabled is a great starting point.

3. TypeScript Fundamentals

Before typing React components, let's review the essential TypeScript types.

Basic Types

const username: string = "Alex";
const age: number = 28;
const isAdmin: boolean = false;

const scores: number[] = [90, 85, 100];

TypeScript can often infer these types automatically:

const username = "Alex";
const age = 28;

You don't need to explicitly annotate every variable.

Object Types

type User = {
  id: number;
  name: string;
  email: string;
  isActive: boolean;
};

const user: User = {
  id: 1,
  name: "Alex",
  email: "alex@example.com",
  isActive: true
};

Optional Properties

Use ? when a property is not required:

type User = {
  id: number;
  name: string;
  avatar?: string;
};

Now both of these objects are valid:

const userOne: User = {
  id: 1,
  name: "Alex"
};

const userTwo: User = {
  id: 2,
  name: "Sarah",
  avatar: "/avatars/sarah.png"
};

Union Types

A union allows a value to have more than one possible type:

let userId: string | number;

userId = 101;
userId = "user-101";

Union types are especially useful for application states:

type Status = "idle" | "loading" | "success" | "error";

Now TypeScript only accepts one of those four values.

`any` vs `unknown`

Avoid using any whenever possible.

let value: any = "hello";

value.toFixed(); // TypeScript won't protect you here.

unknown is safer:

let value: unknown = "hello";

// You must narrow the type before using it.
if (typeof value === "string") {
  console.log(value.toUpperCase());
}

Use unknown when you receive data whose type hasn't been established yet.

4. Typing React Component Props

Props are one of the most common places where TypeScript becomes useful.

You can define props using either type or interface.

Using `type`

type GreetingProps = {
  name: string;
  age: number;
};

function Greeting({ name, age }: GreetingProps) {
  return (
    <div>
      <h2>Hello, {name}!</h2>
      <p>You are {age} years old.</p>
    </div>
  );
}

export default Greeting;

Usage:

<Greeting name="Alex" age={28} />

Passing an incorrect type will produce a TypeScript error:

<Greeting name="Alex" age="twenty-eight" />

Using `interface`

interface ProductProps {
  title: string;
  price: number;
}

function ProductCard({ title, price }: ProductProps) {
  return (
    <article>
      <h2>{title}</h2>
      <p>${price}</p>
    </article>
  );
}

Both type and interface are perfectly valid for describing object-shaped props.

A practical guideline:

Use interface when describing object contracts that may be extended or implemented.
Use type when working with unions, intersections, and more complex type expressions.

You don't need to enforce a strict rule. Consistency matters more.

5. Working with Children Props

React components often need to accept nested content.

Use React.ReactNode to describe content that React can render:

import type { ReactNode } from "react";

type CardProps = {
  title: string;
  children: ReactNode;
};

function Card({ title, children }: CardProps) {
  return (
    <section className="card">
      <h2>{title}</h2>
      <div>{children}</div>
    </section>
  );
}

Usage:

<Card title="Welcome">
  <p>This is some content inside the card.</p>
  <button>Learn More</button>
</Card>

You can also make children optional:

type CardProps = {
  title: string;
  children?: ReactNode;
};

Another option is PropsWithChildren:

import type { PropsWithChildren } from "react";

type PanelProps = PropsWithChildren<{
  title: string;
}>;

function Panel({ title, children }: PanelProps) {
  return (
    <section>
      <h2>{title}</h2>
      {children}
    </section>
  );
}

Remember that PropsWithChildren makes children optional. If your component requires children, explicitly declare children: ReactNode.

6. Typing Event Handlers

React event handlers are another important part of TypeScript development.

You can use React's event types to describe the events your functions receive.

Input Events

import type { ChangeEvent } from "react";

function SearchInput() {
  const handleChange = (event: ChangeEvent<HTMLInputElement>) => {
    console.log(event.target.value);
  };

  return (
    <input
      type="text"
      placeholder="Search..."
      onChange={handleChange}
    />
  );
}

Form Events

import type { FormEvent } from "react";

function LoginForm() {
  const handleSubmit = (event: FormEvent<HTMLFormElement>) => {
    event.preventDefault();

    console.log("Form submitted!");
  };

  return (
    <form onSubmit={handleSubmit}>
      <input type="email" placeholder="Email" />
      <button type="submit">Login</button>
    </form>
  );
}

Mouse Events

import type { MouseEvent } from "react";

function ActionButton() {
  const handleClick = (event: MouseEvent<HTMLButtonElement>) => {
    console.log(event.currentTarget);
  };

  return (
    <button onClick={handleClick}>
      Click Me
    </button>
  );
}

Common React Event Types

Event	Type
Input change	`ChangeEvent<HTMLInputElement>`
Textarea change	`ChangeEvent<HTMLTextAreaElement>`
Form submit	`FormEvent<HTMLFormElement>`
Button click	`MouseEvent<HTMLButtonElement>`
Select change	`ChangeEvent<HTMLSelectElement>`

You don't always need to write these types manually.

TypeScript can infer the event type when you define the handler inline:

function SearchInput() {
  return (
    <input
      onChange={(event) => {
        console.log(event.target.value);
      }}
    />
  );
}

Use explicit event types when defining reusable handler functions or when inference isn't sufficient.

7. Typing `useState`

React's useState works naturally with TypeScript.

Primitive State

TypeScript usually infers the type automatically:

import { useState } from "react";

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

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

Since the initial value is a number, TypeScript knows that count is a number.

Array State

When initializing an empty array, provide its element type:

type Product = {
  id: number;
  name: string;
};

function ProductList() {
  const [products, setProducts] = useState<Product[]>([]);

  const addProduct = () => {
    setProducts((currentProducts) => [
      ...currentProducts,
      { id: 1, name: "Laptop" }
    ]);
  };

  return (
    <div>
      {products.map((product) => (
        <p key={product.id}>{product.name}</p>
      ))}

      <button onClick={addProduct}>Add Product</button>
    </div>
  );
}

Nullable State

Sometimes a state value starts as null and receives an object later.

type User = {
  id: number;
  name: string;
};

function UserProfile() {
  const [user, setUser] = useState<User | null>(null);

  return (
    <div>
      {user ? <h2>{user.name}</h2> : <p>No user selected.</p>}
    </div>
  );
}

The union User | null makes the possible states explicit.

Union State

type Status = "idle" | "loading" | "success" | "error";

function DataLoader() {
  const [status, setStatus] = useState<Status>("idle");

  return (
    <div>
      <p>Current status: {status}</p>

      <button onClick={() => setStatus("loading")}>
        Start Loading
      </button>
    </div>
  );
}

A useful rule: let TypeScript infer types when it can, but provide explicit types when the initial value doesn't communicate enough information.

8. Typing `useRef`

Refs are commonly used to access DOM elements or store mutable values.

DOM References

import { useRef } from "react";

function SearchBox() {
  const inputRef = useRef<HTMLInputElement>(null);

  const focusInput = () => {
    inputRef.current?.focus();
  };

  return (
    <div>
      <input ref={inputRef} type="text" />

      <button onClick={focusInput}>
        Focus Input
      </button>
    </div>
  );
}

Here:

HTMLInputElement describes the DOM element.
null represents the initial state before React attaches the element.
Optional chaining prevents accessing a method when the ref is still null.

Mutable Values

Refs can also store values that don't need to trigger a render:

import { useRef } from "react";

function Timer() {
  const renderCount = useRef(0);

  renderCount.current += 1;

  return <p>Render count: {renderCount.current}</p>;
}

The value of a ref persists across renders, but changing it does not trigger a new render.

In real applications, avoid using a ref to manage data that should be displayed reactively. That's what state is for.

9. Typing `useEffect`

Most effects can rely on TypeScript's inference.

import { useEffect, useState } from "react";

function WindowWidth() {
  const [width, setWidth] = useState(window.innerWidth);

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

    window.addEventListener("resize", handleResize);

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

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

TypeScript understands the effect callback and its cleanup function.

You generally don't need to manually annotate the return type of useEffect.

10. Typing Custom Hooks

Custom Hooks benefit greatly from TypeScript because they often return data and functions that other components reuse.

Consider a Hook for managing a counter:

import { useState } from "react";

function useCounter(initialValue: number = 0) {
  const [count, setCount] = useState(initialValue);

  const increment = () => setCount((value) => value + 1);
  const decrement = () => setCount((value) => value - 1);
  const reset = () => setCount(initialValue);

  return {
    count,
    increment,
    decrement,
    reset
  };
}

Usage:

function Counter() {
  const { count, increment, decrement, reset } = useCounter(5);

  return (
    <div>
      <h2>{count}</h2>

      <button onClick={increment}>+</button>
      <button onClick={decrement}>-</button>
      <button onClick={reset}>Reset</button>
    </div>
  );
}

TypeScript automatically infers the Hook's parameter and return types.

You can add explicit return types when they improve clarity or when a public API needs a stable contract.

type CounterResult = {
  count: number;
  increment: () => void;
  decrement: () => void;
  reset: () => void;
};

function useCounter(initialValue = 0): CounterResult {
  const [count, setCount] = useState(initialValue);

  return {
    count,
    increment: () => setCount((value) => value + 1),
    decrement: () => setCount((value) => value - 1),
    reset: () => setCount(initialValue)
  };
}

11. Typing React Context Safely

Context allows components to share data without passing props through every level of the component tree.

Let's create a theme context.

First, define the context type:

type Theme = "light" | "dark";

type ThemeContextValue = {
  theme: Theme;
  toggleTheme: () => void;
};

Next, create the context:

import { createContext } from "react";

const ThemeContext = createContext<ThemeContextValue | undefined>(
  undefined
);

Create a provider:

import { useState } from "react";
import type { ReactNode } from "react";

type ThemeProviderProps = {
  children: ReactNode;
};

function ThemeProvider({ children }: ThemeProviderProps) {
  const [theme, setTheme] = useState<Theme>("light");

  const toggleTheme = () => {
    setTheme((current) =>
      current === "light" ? "dark" : "light"
    );
  };

  return (
    <ThemeContext.Provider value={{ theme, toggleTheme }}>
      {children}
    </ThemeContext.Provider>
  );
}

Create a custom Hook that safely accesses the context:

import { useContext } from "react";

function useTheme() {
  const context = useContext(ThemeContext);

  if (!context) {
    throw new Error("useTheme must be used inside ThemeProvider");
  }

  return context;
}

Now any component can use it:

function ThemeButton() {
  const { theme, toggleTheme } = useTheme();

  return (
    <button onClick={toggleTheme}>
      Current theme: {theme}
    </button>
  );
}

This pattern is better than using an empty object or forcing a type assertion to pretend the context always has a value.

It gives you a clear error when a component is rendered outside its provider.

12. Typing API Responses

One of the most important TypeScript lessons is understanding that external data is not automatically safe.

Consider an API response:

{
  "id": 1,
  "name": "Laptop",
  "price": 1200
}

We can describe the expected structure:

type Product = {
  id: number;
  name: string;
  price: number;
};

However, this does not guarantee that the server actually sends that structure.

A Basic API Function

async function fetchProducts(): Promise<Product[]> {
  const response = await fetch("/api/products");

  if (!response.ok) {
    throw new Error("Failed to fetch products");
  }

  const data: unknown = await response.json();

  if (!Array.isArray(data)) {
    throw new Error("Invalid products response");
  }

  return data.map((item): Product => {
    if (
      typeof item !== "object" ||
      item === null ||
      !("id" in item) ||
      !("name" in item) ||
      !("price" in item) ||
      typeof item.id !== "number" ||
      typeof item.name !== "string" ||
      typeof item.price !== "number"
    ) {
      throw new Error("Invalid product data");
    }

    return {
      id: item.id,
      name: item.name,
      price: item.price
    };
  });
}

This example performs runtime checks before returning the data as Product[].

Important: Type Assertions Don't Validate Data

You might see code like this:

const products = (await response.json()) as Product[];

This only tells TypeScript to trust you.

It does not inspect the response or verify that the properties exist.

For larger applications, a runtime validation library such as Zod can make this process more convenient.

Example:

import { z } from "zod";

const ProductSchema = z.object({
  id: z.number(),
  name: z.string(),
  price: z.number()
});

type Product = z.infer<typeof ProductSchema>;

async function fetchProduct(): Promise<Product> {
  const response = await fetch("/api/product/1");

  if (!response.ok) {
    throw new Error("Failed to fetch product");
  }

  const data: unknown = await response.json();

  return ProductSchema.parse(data);
}

Now the same schema provides both runtime validation and a TypeScript type.

This is especially useful when working with external APIs, forms, or user-generated data.

13. Understanding Generics in React

Generics allow you to create reusable functions and components that work with different types while preserving type safety.

Consider a simple function:

function identity<T>(value: T): T {
  return value;
}

const numberValue = identity(10);
const stringValue = identity("Hello");

TypeScript understands the type of each returned value.

Generic List Component

Imagine building a list component that can display users, products, or any other data type.

Instead of creating a separate component for each type, use a generic component.

import type { ReactNode } from "react";

type ListProps<T> = {
  items: T[];
  getKey: (item: T) => string | number;
  renderItem: (item: T) => ReactNode;
};

function List<T>({
  items,
  getKey,
  renderItem
}: ListProps<T>) {
  return (
    <ul>
      {items.map((item) => (
        <li key={getKey(item)}>
          {renderItem(item)}
        </li>
      ))}
    </ul>
  );
}

Use it with products:

type Product = {
  id: number;
  name: string;
  price: number;
};

const products: Product[] = [
  { id: 1, name: "Laptop", price: 1200 },
  { id: 2, name: "Phone", price: 800 }
];

function ProductList() {
  return (
    <List
      items={products}
      getKey={(product) => product.id}
      renderItem={(product) => (
        <span>
          {product.name} — ${product.price}
        </span>
      )}
    />
  );
}

TypeScript infers T as Product.

The renderItem callback therefore knows that its argument has id, name, and price properties.

Generic Constraints

Sometimes a generic needs to have a particular property.

Use extends to define a constraint:

function getId<T extends { id: number }>(item: T): number {
  return item.id;
}

Now the function accepts any object that has a numeric id.

Generics are especially useful for reusable UI components, data utilities, Hooks, and API helpers.

14. Typing Native HTML Props

Sometimes you want a custom React component to support all the normal HTML attributes of an element.

For example, a custom button may need to support disabled, type, aria-label, and onClick.

You can reuse React's built-in prop types:

import type { ComponentProps } from "react";

type ButtonProps = ComponentProps<"button"> & {
  variant?: "primary" | "secondary";
};

function Button({
  variant = "primary",
  children,
  ...props
}: ButtonProps) {
  return (
    <button
      className={`button button-${variant}`}
      {...props}
    >
      {children}
    </button>
  );
}

Usage:

<Button
  variant="primary"
  disabled={false}
  onClick={() => console.log("Clicked")}
>
  Save Changes
</Button>

This approach avoids manually recreating every native button property.

You can use ComponentProps<"input">, ComponentProps<"a">, and other HTML element types in the same way.

15. Discriminated Unions for Better Component APIs

Sometimes a component supports multiple modes, and each mode requires different props.

A discriminated union can make invalid combinations impossible to represent.

Consider a button that can behave as either a link or an action button:

type ButtonProps =
  | {
      variant: "link";
      href: string;
      onClick?: never;
    }
  | {
      variant: "button";
      onClick: () => void;
      href?: never;
    };

Implement the component:

function ActionButton(props: ButtonProps) {
  if (props.variant === "link") {
    return <a href={props.href}>Open Page</a>;
  }

  return (
    <button onClick={props.onClick}>
      Perform Action
    </button>
  );
}

Valid usage:

<ActionButton variant="link" href="/about" />

<ActionButton
  variant="button"
  onClick={() => console.log("Saved")}
/>

Invalid usage:

<ActionButton
  variant="link"
  href="/about"
  onClick={() => console.log("Clicked")}
/>

TypeScript will report an error because the link variant doesn't accept an onClick property.

This pattern is useful for buttons, dialogs, notifications, input components, and other UI elements with multiple modes.

16. Building a Small Type-Safe Product Interface

Let's combine several concepts into a practical example.

We'll create:

A Product type
A typed ProductCard component
A typed product list
A callback for adding products to a cart

Step 1: Define the Product Type

export type Product = {
  id: number;
  name: string;
  price: number;
  category: "electronics" | "clothing" | "books";
  inStock: boolean;
};

Step 2: Create ProductCard

import type { Product } from "./types";

type ProductCardProps = {
  product: Product;
  onAddToCart: (product: Product) => void;
};

function ProductCard({
  product,
  onAddToCart
}: ProductCardProps) {
  return (
    <article className="product-card">
      <h2>{product.name}</h2>

      <p>Category: {product.category}</p>
      <p>Price: ${product.price}</p>

      {product.inStock ? (
        <button onClick={() => onAddToCart(product)}>
          Add to Cart
        </button>
      ) : (
        <p>Out of stock</p>
      )}
    </article>
  );
}

export default ProductCard;

Step 3: Create the Product List

import { useState } from "react";
import type { Product } from "./types";
import ProductCard from "./ProductCard";

const initialProducts: Product[] = [
  {
    id: 1,
    name: "Laptop",
    price: 1200,
    category: "electronics",
    inStock: true
  },
  {
    id: 2,
    name: "T-Shirt",
    price: 25,
    category: "clothing",
    inStock: true
  },
  {
    id: 3,
    name: "React Guide",
    price: 40,
    category: "books",
    inStock: false
  }
];

function ProductList() {
  const [cart, setCart] = useState<Product[]>([]);

  const addToCart = (product: Product) => {
    setCart((currentCart) => [
      ...currentCart,
      product
    ]);
  };

  return (
    <main>
      <h1>Products</h1>

      <p>Cart items: {cart.length}</p>

      <div className="product-grid">
        {initialProducts.map((product) => (
          <ProductCard
            key={product.id}
            product={product}
            onAddToCart={addToCart}
          />
        ))}
      </div>
    </main>
  );
}

export default ProductList;

Notice how TypeScript protects the entire data flow:

Every product must match the Product type.
ProductCard requires a valid product.
The callback must receive a Product.
The cart can only contain products.

This makes the application easier to maintain as it grows.

17. Common TypeScript Mistakes in React

Even experienced developers can misuse TypeScript.

Here are some common mistakes to avoid.

Mistake 1: Using `any` Everywhere

Avoid:

function UserCard({ user }: any) {
  return <h2>{user.name}</h2>;
}

Prefer:

type User = {
  id: number;
  name: string;
};

type UserCardProps = {
  user: User;
};

function UserCard({ user }: UserCardProps) {
  return <h2>{user.name}</h2>;
}

Mistake 2: Overusing Type Assertions

Avoid:

const user = responseData as User;

This doesn't validate the data.

Prefer runtime validation when the data comes from an untrusted source.

Mistake 3: Using the Non-Null Assertion Everywhere

Avoid:

inputRef.current!.focus();

The ! tells TypeScript to assume the value is not null.

If that assumption is wrong, the application can still crash.

Prefer:

inputRef.current?.focus();

Mistake 4: Ignoring Nullable State

Avoid:

const [user, setUser] = useState<User>(null as any);

Prefer:

const [user, setUser] = useState<User | null>(null);

Mistake 5: Manually Typing Every Variable

You don't need to annotate every value.

const count: number = 10;
const name: string = "Alex";

Can usually be simplified to:

const count = 10;
const name = "Alex";

Let TypeScript infer obvious types.

Mistake 6: Confusing TypeScript Types with Runtime Checks

This:

type User = {
  name: string;
};

Doesn't guarantee that a server response contains a valid name.

Types help during development. Runtime validation protects your application from unexpected data.

18. Best Practices for React + TypeScript

Here are some practical recommendations:

Enable strict TypeScript checking.
Define reusable types for important domain models.
Prefer precise types over any.
Use unknown for untrusted values until they're validated.
Let TypeScript infer types when the intent is obvious.
Use React.ReactNode for renderable children.
Type event handlers accurately.
Use discriminated unions for components with multiple variants.
Keep API validation separate from UI rendering.
Use generics when they improve reuse without making code unnecessarily complex.
Avoid unnecessary type assertions and non-null assertions.
Keep component props focused and easy to understand.

Suggested Project Structure

As your application grows, organizing types and components becomes increasingly important.

src/
├── components/
│   ├── Button.tsx
│   ├── ProductCard.tsx
│   └── ProductList.tsx
├── hooks/
│   └── useProducts.ts
├── context/
│   └── ThemeContext.tsx
├── services/
│   └── productApi.ts
├── types/
│   ├── product.ts
│   └── user.ts
├── App.tsx
└── main.tsx

You don't need to create a separate type file for every component. Keep small, component-specific prop types near the component itself.

Move shared domain types into dedicated files when multiple parts of the application need them.

19. TypeScript React Checklist

Before considering your React TypeScript code ready, check the following:

[ ] Strict mode is enabled.
[ ] Component props have meaningful types.
[ ] State types represent all possible values.
[ ] Nullable values are handled safely.
[ ] Event handlers use appropriate event types.
[ ] Custom Hooks expose clear return values.
[ ] Context values are checked safely.
[ ] API responses are validated at runtime.
[ ] any is avoided unless there's a strong reason.
[ ] Type assertions are used carefully.
[ ] Reusable components use generics when appropriate.
[ ] Components have clear and predictable contracts.

Final Thoughts

TypeScript doesn't replace good React architecture, testing, or runtime error handling.

What it does is make your code easier to reason about.

When you combine React's component model with TypeScript's type system, you get applications that are more predictable, easier to refactor, and simpler to maintain.

You don't need to use advanced generics or complicated utility types everywhere.

Start with component props, state, event handlers, and API models. As your application grows, introduce more advanced patterns where they provide real value.

The goal isn't to write the most complicated types.

The goal is to make incorrect code harder to write.

What's Next?

In Part 10: React Router — Routing, Nested Routes & Navigation, we'll explore how to build multi-page React applications without losing the benefits of a component-based architecture.

We'll cover:

Installing and configuring React Router
Creating routes and navigation links
Dynamic URL parameters
Nested routes and layouts
Route parameters and query strings
Protected routes
Programmatic navigation
Handling 404 pages

Stay tuned, and keep building! 🚀

React Mastery Series — Part 8: React Testing — Unit, Integration & End-to-End Testing

Hamed Farazi — Wed, 04 Nov 2026 09:53:05 +0000

Writing React components is only part of building a reliable application.

Imagine you have built a shopping application with:

A product list.
A search field.
A shopping cart.
User authentication.
Checkout functionality.
API integration.

Everything works perfectly during development.

Then you make a small change to the cart logic, and suddenly the checkout page stops working.

How can you catch problems like this before your users do?

The answer is testing.

Testing helps you verify that your application behaves as expected, detect bugs earlier, and make changes with confidence.

In this article, we'll learn how to test React applications using modern testing tools and practical examples.

We'll cover:

Unit testing.
Integration testing.
React Testing Library.
Vitest.
User interactions.
API mocking.
Asynchronous UI testing.
End-to-end testing with Playwright.
Common testing mistakes.
A practical testing strategy.

Let's get started!

1. Why Is Testing Important?

Testing is not just about finding bugs.

It also helps you maintain your application as it grows.

Imagine you have a function that calculates the total price of a shopping cart.

function calculateTotal(products) {
  return products.reduce(
    (total, product) => total + product.price * product.quantity,
    0
  );
}

You know it works for your current data.

But what happens when:

The cart is empty?
A product has a quantity of zero?
A product has a decimal price?
Someone changes the calculation later?

Without tests, you may need to manually check every scenario.

With tests, you can verify expected behavior automatically.

Benefits of Testing

Catch bugs early: Find problems before they reach production.
Prevent regressions: Make sure existing functionality continues working.
Improve code design: Testable code often has clearer responsibilities.
Refactor safely: Change implementation without accidentally breaking behavior.
Document behavior: Tests show how components and functions are expected to work.
Build confidence: Make releases with fewer surprises.

Testing doesn't guarantee that an application is bug-free, but it significantly improves reliability.

2. Types of Testing

There are several levels of testing.

The most common categories are unit, integration, and end-to-end testing.

A. Unit Testing

Unit tests verify small, isolated pieces of functionality.

Examples:

A utility function.
A price calculator.
A date formatter.
A validation function.
A small component's behavior.

Example:

function add(a, b) {
  return a + b;
}

A unit test might verify:

expect(add(2, 3)).toBe(5);

The goal is to verify one small unit independently.

B. Integration Testing

Integration tests verify that multiple parts work together.

Examples:

A form and its validation logic.
A product list and a search field.
A component and its API interaction.
A shopping cart and its total calculation.

A React integration test might:

Render a product list.
Type into the search field.
Verify that matching products appear.
Verify that unrelated products disappear.

This tests how different parts of the application interact.

C. End-to-End Testing

End-to-end tests verify complete user journeys.

For example, a shopping application test might:

Open the homepage.
Search for a product.
Open the product page.
Add the product to the cart.
Open the cart.
Complete checkout.

These tests run against a real browser and exercise the application from the user's perspective.

Comparing the Three Types

Test type	Main purpose	Typical scope
Unit	Verify isolated logic	Small
Integration	Verify connected parts	Medium
End-to-end	Verify complete workflows	Large

All three are useful, but they have different costs and purposes.

3. The React Testing Tools

There are several tools commonly used in React projects.

Let's understand their responsibilities.

Vitest

https://vitest.dev/

Vitest is a JavaScript testing framework.

It provides:

Test execution.
Assertions.
Mock functions.
Setup and teardown hooks.
Watch mode.
Coverage integration.

It works particularly well with Vite projects.

React Testing Library

https://testing-library.com/docs/react-testing-library/intro/

React Testing Library helps you test React components through their rendered output.

Its philosophy is simple:

Test your application the way users interact with it.

Instead of checking internal implementation details, you interact with buttons, inputs, headings, and other visible elements.

jest-dom

https://github.com/testing-library/jest-dom

@testing-library/jest-dom provides useful DOM assertions.

For example:

expect(screen.getByRole("button")).toBeInTheDocument();

Or:

expect(screen.getByText("Welcome")).toBeVisible();

user-event

https://testing-library.com/docs/user-event/intro/

@testing-library/user-event simulates user interactions.

For example:

await user.click(button);
await user.type(input, "React");

It generally provides a more realistic interaction model than directly dispatching individual DOM events.

Playwright

https://playwright.dev/

Playwright is an end-to-end testing framework.

It can:

Open browsers.
Navigate between pages.
Click buttons.
Fill inputs.
Verify page content.
Test multiple browser engines.
Capture screenshots.
Intercept network requests.

We'll use these tools in practical examples.

4. Setting Up a React Testing Environment

Let's create a React application using Vite.

npm create vite@latest react-testing-demo -- --template react
cd react-testing-demo
npm install

Install the testing dependencies:

npm install -D vitest jsdom @testing-library/react @testing-library/jest-dom @testing-library/user-event

Your project will contain something similar to:

react-testing-demo/
|
├── src/
│   ├── App.jsx
│   ├── main.jsx
│   └── ...
|
├── package.json
└── vite.config.js

Configure Vitest

Open vite.config.js:

import { defineConfig } from "vitest/config";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [react()],
  test: {
    environment: "jsdom",
    setupFiles: "./src/test/setup.js",
    globals: true,
    clearMocks: true,
  },
});

Here:

environment: "jsdom" provides a simulated browser DOM.
setupFiles loads shared test configuration.
globals: true allows using describe, it, and expect without importing them in every test.
clearMocks: true clears mock call history between tests.

Create:

src/
└── test/
    └── setup.js

Inside setup.js:

import "@testing-library/jest-dom/vitest";

This enables additional DOM assertions.

Add Test Scripts

In package.json, add:

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "test": "vitest",
    "test:run": "vitest run",
    "test:coverage": "vitest run --coverage"
  }
}

If you want coverage reports, install a coverage provider compatible with your Vitest version, such as @vitest/coverage-v8.

Now you can run:

npm test

Or run tests once:

npm run test:run

Your testing environment is ready.

5. Writing Your First Unit Test

Let's start with a simple utility function.

Create:

src/utils/calculateTotal.js

export function calculateTotal(products) {
  return products.reduce(
    (total, product) => {
      return total + product.price * product.quantity;
    },
    0
  );
}

Now create:

src/utils/calculateTotal.test.js

import { describe, it, expect } from "vitest";
import { calculateTotal } from "./calculateTotal";

describe("calculateTotal", () => {
  it("calculates the total price", () => {
    const products = [
      { price: 10, quantity: 2 },
      { price: 20, quantity: 1 },
    ];

    expect(calculateTotal(products)).toBe(40);
  });

  it("returns zero for an empty cart", () => {
    expect(calculateTotal([])).toBe(0);
  });

  it("handles decimal prices", () => {
    const products = [
      { price: 9.99, quantity: 2 },
    ];

    expect(calculateTotal(products)).toBeCloseTo(19.98);
  });
});

Let's understand the structure.

describe

Groups related tests.

describe("calculateTotal", () => {
  // Tests go here
});

it

Defines one test case.

it("calculates the total price", () => {
  // Test logic
});

expect

Checks whether a value matches the expected result.

expect(result).toBe(40);

Common Assertions

Assertion	Purpose
`toBe()`	Checks primitive equality or reference identity
`toEqual()`	Checks deep equality
`toBeTruthy()`	Checks whether a value is truthy
`toBeFalsy()`	Checks whether a value is falsy
`toContain()`	Checks whether an item exists
`toHaveLength()`	Checks collection length
`toThrow()`	Checks whether a function throws
`toBeCloseTo()`	Compares floating-point numbers

You can now test utility functions independently from React.

6. Testing React Components

Let's test a simple counter component.

Create:

src/components/Counter.jsx

import { useState } from "react";

export default function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <h1>Count: {count}</h1>

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

Now create:

src/components/Counter.test.jsx

import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
import { describe, it, expect } from "vitest";

import Counter from "./Counter";

describe("Counter", () => {
  it("renders the initial count", () => {
    render(<Counter />);

    expect(
      screen.getByRole("heading", {
        name: "Count: 0",
      })
    ).toBeInTheDocument();
  });

  it("increments the count when clicked", async () => {
    const user = userEvent.setup();

    render(<Counter />);

    const button = screen.getByRole("button", {
      name: "Increment",
    });

    await user.click(button);

    expect(
      screen.getByRole("heading", {
        name: "Count: 1",
      })
    ).toBeInTheDocument();
  });
});

What Is render()?

render(<Counter />);

This renders the component into the test DOM.

What Is screen?

screen provides queries for finding elements in the rendered document.

For example:

screen.getByRole("button");
screen.getByText("Hello");
screen.getByLabelText("Email");

What Is userEvent?

const user = userEvent.setup();

await user.click(button);

This simulates a user clicking the button.

The test verifies the visible behavior rather than checking the component's internal state.

That is the central idea behind React Testing Library.

7. Querying Elements the Right Way

React Testing Library provides several query methods.

Understanding their differences is important.

getBy

Use getBy when the element should exist immediately.

screen.getByRole("button", {
  name: "Submit",
});

If the element does not exist, the test fails immediately.

queryBy

Use queryBy when the element may not exist.

expect(
  screen.queryByText("Error")
).not.toBeInTheDocument();

It returns null if no matching element exists.

findBy

Use findBy when an element is expected to appear asynchronously.

const message = await screen.findByText(
  "Data loaded"
);

It waits for the element to appear, up to the configured timeout.

Query Priority

Prefer accessible queries:

getByRole
getByLabelText
getByPlaceholderText
getByText
getByTestId

For example:

<label htmlFor="email">Email</label>

<input
  id="email"
  type="email"
/>

Test it with:

screen.getByRole("textbox", {
  name: "Email",
});

This encourages accessible interfaces and makes tests closer to real user interactions.

Avoid relying on implementation-specific selectors when an accessible query is available.

8. Testing Forms

Forms are common sources of bugs.

Let's build a login form.

import { useState } from "react";

export default function LoginForm({ onSubmit }) {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");

  function handleSubmit(event) {
    event.preventDefault();

    if (!email || !password) {
      return;
    }

    onSubmit({
      email,
      password,
    });
  }

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="email">Email</label>

      <input
        id="email"
        type="email"
        value={email}
        onChange={(event) => setEmail(event.target.value)}
      />

      <label htmlFor="password">Password</label>

      <input
        id="password"
        type="password"
        value={password}
        onChange={(event) => setPassword(event.target.value)}
      />

      <button type="submit">
        Login
      </button>
    </form>
  );
}

Now test it:

import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
import { describe, it, expect, vi } from "vitest";

import LoginForm from "./LoginForm";

describe("LoginForm", () => {
  it("submits email and password", async () => {
    const user = userEvent.setup();
    const handleSubmit = vi.fn();

    render(
      <LoginForm onSubmit={handleSubmit} />
    );

    await user.type(
      screen.getByRole("textbox", {
        name: "Email",
      }),
      "alex@example.com"
    );

    await user.type(
      screen.getByLabelText("Password"),
      "secret123"
    );

    await user.click(
      screen.getByRole("button", {
        name: "Login",
      })
    );

    expect(handleSubmit).toHaveBeenCalledWith({
      email: "alex@example.com",
      password: "secret123",
    });
  });

  it("does not submit when fields are empty", async () => {
    const user = userEvent.setup();
    const handleSubmit = vi.fn();

    render(
      <LoginForm onSubmit={handleSubmit} />
    );

    await user.click(
      screen.getByRole("button", {
        name: "Login",
      })
    );

    expect(handleSubmit).not.toHaveBeenCalled();
  });
});

What Is vi.fn()?

Vitest provides vi.fn() to create mock functions.

A mock function allows you to inspect:

Whether it was called.
How many times it was called.
Which arguments it received.

For example:

expect(handleSubmit).toHaveBeenCalledTimes(1);

Mock functions are extremely useful when testing callbacks and component interactions.

9. Testing Conditional Rendering

React applications often display different UI depending on state.

For example:

function Notification({ message }) {
  if (!message) {
    return null;
  }

  return (
    <div role="alert">
      {message}
    </div>
  );
}

export default Notification;

Test both states:

import { render, screen } from "@testing-library/react";
import { describe, it, expect } from "vitest";

import Notification from "./Notification";

describe("Notification", () => {
  it("renders nothing when there is no message", () => {
    render(<Notification message="" />);

    expect(
      screen.queryByRole("alert")
    ).not.toBeInTheDocument();
  });

  it("displays the notification message", () => {
    render(
      <Notification message="Something went wrong" />
    );

    expect(
      screen.getByRole("alert")
    ).toHaveTextContent("Something went wrong");
  });
});

This is useful for testing:

Error messages.
Empty states.
Loading indicators.
Success notifications.
Conditional buttons.
Permission-based UI.

10. Testing Asynchronous Components

Many React components depend on asynchronous data.

For example, a component may fetch users from an API.

Let's create a simple component.

import { useEffect, useState } from "react";

export default function UserList() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    async function loadUsers() {
      try {
        const response = await fetch("/api/users");

        if (!response.ok) {
          throw new Error("Failed to load users");
        }

        const data = await response.json();

        setUsers(data);
      } finally {
        setLoading(false);
      }
    }

    loadUsers();
  }, []);

  if (loading) {
    return <p>Loading users...</p>;
  }

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

We want to test:

The loading state.
Successful data loading.
Error behavior.

Mocking fetch

We can replace the global fetch function during a test.

import {
  render,
  screen,
} from "@testing-library/react";

import {
  describe,
  it,
  expect,
  vi,
} from "vitest";

import UserList from "./UserList";

describe("UserList", () => {
  it("shows users after loading", async () => {
    vi.stubGlobal(
      "fetch",
      vi.fn().mockResolvedValue({
        ok: true,
        json: async () => [
          { id: 1, name: "Alex" },
          { id: 2, name: "Jordan" },
        ],
      })
    );

    render(<UserList />);

    expect(
      screen.getByText("Loading users...")
    ).toBeInTheDocument();

    expect(
      await screen.findByText("Alex")
    ).toBeInTheDocument();

    expect(
      screen.getByText("Jordan")
    ).toBeInTheDocument();

    vi.unstubAllGlobals();
  });
});

The important part is:

await screen.findByText("Alex");

Because the data arrives asynchronously, we wait for the expected UI to appear.

A Better Pattern for Mock Cleanup

For larger test suites, put cleanup in shared setup or use afterEach.

For example:

import {
  afterEach,
  vi,
} from "vitest";

afterEach(() => {
  vi.unstubAllGlobals();
});

You should also test failure cases.

For example, a rejected request or a response with ok: false should result in a meaningful error state.

A production component should generally have an explicit error state rather than simply stopping the loading indicator.

11. Testing API Requests with Mock Service Worker

Mocking fetch directly is useful for simple examples.

However, when your application has many API interactions, a more scalable solution is Mock Service Worker (MSW).

Website:

https://mswjs.io/

MSW intercepts network requests and provides mock responses.

This allows your application to make requests normally while your tests control the server responses.

Install it:

npm install -D msw

Create:

src/test/handlers.js

import { http, HttpResponse } from "msw";

export const handlers = [
  http.get("/api/users", () => {
    return HttpResponse.json([
      { id: 1, name: "Alex" },
      { id: 2, name: "Jordan" },
    ]);
  }),
];

Create:

src/test/server.js

import { setupServer } from "msw/node";
import { handlers } from "./handlers";

export const server = setupServer(...handlers);

Update src/test/setup.js:

import "@testing-library/jest-dom/vitest";

import {
  afterAll,
  afterEach,
  beforeAll,
} from "vitest";

import { server } from "./server";

beforeAll(() => {
  server.listen({
    onUnhandledRequest: "error",
  });
});

afterEach(() => {
  server.resetHandlers();
});

afterAll(() => {
  server.close();
});

Now your tests can use the actual application request logic without manually replacing fetch in every test.

You can also override a response for a specific test:

import { http, HttpResponse } from "msw";

import { server } from "../test/server";

server.use(
  http.get("/api/users", () => {
    return HttpResponse.json(
      {
        message: "Server error",
      },
      {
        status: 500,
      }
    );
  })
);

This makes it easier to test loading, success, and failure scenarios.

12. Testing Custom Hooks

React Testing Library provides renderHook for testing Hooks independently.

Imagine a custom Hook:

import { useState } from "react";

export function useCounter(initialValue = 0) {
  const [count, setCount] = useState(initialValue);

  function increment() {
    setCount((current) => current + 1);
  }

  function decrement() {
    setCount((current) => current - 1);
  }

  return {
    count,
    increment,
    decrement,
  };
}

Test it:

import {
  renderHook,
  act,
} from "@testing-library/react";

import {
  describe,
  it,
  expect,
} from "vitest";

import { useCounter } from "./useCounter";

describe("useCounter", () => {
  it("starts with the initial value", () => {
    const { result } = renderHook(() =>
      useCounter(5)
    );

    expect(result.current.count).toBe(5);
  });

  it("increments the count", () => {
    const { result } = renderHook(() =>
      useCounter(0)
    );

    act(() => {
      result.current.increment();
    });

    expect(result.current.count).toBe(1);
  });

  it("decrements the count", () => {
    const { result } = renderHook(() =>
      useCounter(0)
    );

    act(() => {
      result.current.decrement();
    });

    expect(result.current.count).toBe(-1);
  });
});

What Is act()?

act() ensures that React updates related to an interaction or state change have been processed before assertions are made.

Testing Library's user interaction helpers generally handle the required React update wrapping for you.

When directly invoking Hook methods or triggering updates manually, act() is useful.

Don't wrap every Testing Library operation in act() unnecessarily.

13. Testing Context Providers

React Context is often used for global application state.

Imagine a theme provider:

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

const ThemeContext = createContext(null);

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

  function toggleTheme() {
    setTheme((current) =>
      current === "light" ? "dark" : "light"
    );
  }

  return (
    <ThemeContext.Provider
      value={{
        theme,
        toggleTheme,
      }}
    >
      {children}
    </ThemeContext.Provider>
  );
}

export function useTheme() {
  const context = useContext(ThemeContext);

  if (!context) {
    throw new Error(
      "useTheme must be used within ThemeProvider"
    );
  }

  return context;
}

Create a component:

import { useTheme } from "./ThemeContext";

export default function ThemeButton() {
  const { theme, toggleTheme } = useTheme();

  return (
    <button onClick={toggleTheme}>
      Current theme: {theme}
    </button>
  );
}

Test it:

import {
  render,
  screen,
} from "@testing-library/react";

import userEvent from "@testing-library/user-event";

import {
  describe,
  it,
  expect,
} from "vitest";

import {
  ThemeProvider,
} from "./ThemeContext";

import ThemeButton from "./ThemeButton";

describe("ThemeButton", () => {
  it("changes the theme when clicked", async () => {
    const user = userEvent.setup();

    render(
      <ThemeProvider>
        <ThemeButton />
      </ThemeProvider>
    );

    expect(
      screen.getByRole("button")
    ).toHaveTextContent("light");

    await user.click(
      screen.getByRole("button")
    );

    expect(
      screen.getByRole("button")
    ).toHaveTextContent("dark");
  });
});

Testing providers this way verifies the behavior of the actual Context integration.

For applications with several providers, you can create a reusable test wrapper.

14. Testing Components with Props

Let's test a product card.

export default function ProductCard({ product, onAdd }) {
  return (
    <article>
      <h2>{product.name}</h2>

      <p>${product.price}</p>

      <button onClick={() => onAdd(product)}>
        Add to Cart
      </button>
    </article>
  );
}

Test:

import {
  render,
  screen,
} from "@testing-library/react";

import userEvent from "@testing-library/user-event";

import {
  describe,
  it,
  expect,
  vi,
} from "vitest";

import ProductCard from "./ProductCard";

describe("ProductCard", () => {
  it("displays product information", () => {
    const product = {
      id: 1,
      name: "Laptop",
      price: 1200,
    };

    render(
      <ProductCard
        product={product}
        onAdd={() => {}}
      />
    );

    expect(
      screen.getByRole("heading", {
        name: "Laptop",
      })
    ).toBeInTheDocument();

    expect(
      screen.getByText("$1200")
    ).toBeInTheDocument();
  });

  it("calls onAdd with the product", async () => {
    const user = userEvent.setup();

    const product = {
      id: 1,
      name: "Laptop",
      price: 1200,
    };

    const onAdd = vi.fn();

    render(
      <ProductCard
        product={product}
        onAdd={onAdd}
      />
    );

    await user.click(
      screen.getByRole("button", {
        name: "Add to Cart",
      })
    );

    expect(onAdd).toHaveBeenCalledWith(product);
  });
});

This verifies both the component's displayed content and its interaction behavior.

15. What Is End-to-End Testing?

So far, we've mostly tested functions and React components.

But a real application consists of multiple connected systems:

Frontend.
Backend.
Database.
Authentication.
Routing.
Browser behavior.

End-to-end testing verifies complete user workflows.

For example:

Open application
      |
      v
Search for a product
      |
      v
Open product details
      |
      v
Add product to cart
      |
      v
Open shopping cart
      |
      v
Verify product and price

This type of testing can catch problems that unit tests cannot.

A component may work perfectly in isolation while the complete application has a routing or integration bug.

That's why end-to-end tests are valuable.

16. Setting Up Playwright

Install Playwright:

npm install -D @playwright/test

Install browser binaries:

npx playwright install

Initialize the configuration:

npx playwright init

Follow the setup prompts for your project.

A typical configuration might look like:

import { defineConfig, devices } from "@playwright/test";

export default defineConfig({
  testDir: "./e2e",

  use: {
    baseURL: "http://localhost:5173",
    trace: "on-first-retry",
  },

  projects: [
    {
      name: "chromium",
      use: {
        ...devices["Desktop Chrome"],
      },
    },
  ],

  webServer: {
    command: "npm run dev -- --host 127.0.0.1",
    url: "http://127.0.0.1:5173",
    reuseExistingServer: !process.env.CI,
  },
});

Depending on the Playwright version and initialization workflow, some configuration may already be generated for you.

Create:

e2e/
└── homepage.spec.js

17. Writing Your First Playwright Test

Imagine your application displays a heading:

function App() {
  return (
    <main>
      <h1>Welcome to My Store</h1>

      <button>
        Explore Products
      </button>
    </main>
  );
}

Create an end-to-end test:

import {
  test,
  expect,
} from "@playwright/test";

test("homepage displays the main heading", async ({ page }) => {
  await page.goto("/");

  await expect(
    page.getByRole("heading", {
      name: "Welcome to My Store",
    })
  ).toBeVisible();
});

Let's understand the code.

page.goto()

Navigates to the application.

await page.goto("/");

getByRole()

Finds an element using its accessible role and name.

page.getByRole("heading", {
  name: "Welcome to My Store",
});

toBeVisible()

Checks that the element is visible.

await expect(element).toBeVisible();

Playwright automatically waits for many expected conditions, making tests more reliable than using arbitrary fixed delays.

18. Testing a Complete User Interaction

Let's test a search feature.

Imagine:

function SearchPage() {
  const products = [
    "Laptop",
    "Phone",
    "Keyboard",
  ];

  const [search, setSearch] = useState("");

  const filteredProducts = products.filter((product) =>
    product.toLowerCase().includes(search.toLowerCase())
  );

  return (
    <main>
      <h1>Products</h1>

      <label htmlFor="search">
        Search products
      </label>

      <input
        id="search"
        value={search}
        onChange={(event) => setSearch(event.target.value)}
      />

      <ul>
        {filteredProducts.map((product) => (
          <li key={product}>
            {product}
          </li>
        ))}
      </ul>
    </main>
  );
}

A Playwright test:

import {
  test,
  expect,
} from "@playwright/test";

test("user can search for products", async ({ page }) => {
  await page.goto("/");

  const searchInput = page.getByRole("textbox", {
    name: "Search products",
  });

  await searchInput.fill("Laptop");

  await expect(
    page.getByText("Laptop")
  ).toBeVisible();

  await expect(
    page.getByText("Phone")
  ).not.toBeVisible();

  await expect(
    page.getByText("Keyboard")
  ).not.toBeVisible();
});

This verifies the actual browser experience.

It checks that a user can enter a search term and see the expected results.

19. Testing Navigation

Navigation is another important part of end-to-end testing.

Imagine:

function App() {
  return (
    <nav>
      <a href="/">Home</a>
      <a href="/about">About</a>
    </nav>
  );
}

Test navigation:

test("user can navigate to About", async ({ page }) => {
  await page.goto("/");

  await page.getByRole("link", {
    name: "About",
  }).click();

  await expect(page).toHaveURL(/about/);

  await expect(
    page.getByRole("heading", {
      name: "About Us",
    })
  ).toBeVisible();
});

This verifies that the link works and the destination page is displayed.

For client-side routing, make sure your development or test server is configured to serve the application entry point for application routes.

20. Testing API-Driven UI with Playwright

Playwright can intercept network requests.

This is useful when you want to test a frontend without depending on a live backend.

Example:

test("displays products returned by the API", async ({ page }) => {
  await page.route("**/api/products", async (route) => {
    await route.fulfill({
      status: 200,
      contentType: "application/json",
      body: JSON.stringify([
        {
          id: 1,
          name: "Laptop",
          price: 1200,
        },
        {
          id: 2,
          name: "Phone",
          price: 800,
        },
      ]),
    });
  });

  await page.goto("/");

  await expect(
    page.getByText("Laptop")
  ).toBeVisible();

  await expect(
    page.getByText("Phone")
  ).toBeVisible();
});

You can also simulate a server failure:

await page.route("**/api/products", async (route) => {
  await route.fulfill({
    status: 500,
    contentType: "application/json",
    body: JSON.stringify({
      message: "Internal server error",
    }),
  });
});

Then verify that the application displays a meaningful error message.

This makes it possible to test different network scenarios without requiring a real backend for every test.

21. Testing Loading, Error, and Empty States

A robust application should handle more than successful API responses.

Consider these scenarios:

Scenario	Expected UI
Request is pending	Loading indicator
Request succeeds	Data is displayed
Request returns no items	Empty state
Request fails	Error message
User retries	Request is attempted again

For example:

function ProductList({ products, loading, error }) {
  if (loading) {
    return <p role="status">Loading products...</p>;
  }

  if (error) {
    return <p role="alert">Unable to load products.</p>;
  }

  if (products.length === 0) {
    return <p>No products found.</p>;
  }

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

Each state deserves a test.

For example:

it("shows the loading message", () => {
  render(
    <ProductList
      products={[]}
      loading={true}
      error={null}
    />
  );

  expect(
    screen.getByRole("status")
  ).toHaveTextContent("Loading products...");
});

And:

it("shows the empty state", () => {
  render(
    <ProductList
      products={[]}
      loading={false}
      error={null}
    />
  );

  expect(
    screen.getByText("No products found.")
  ).toBeInTheDocument();
});

Thinking about different UI states helps prevent incomplete user experiences.

22. Test Coverage: How Much Testing Is Enough?

Test coverage measures how much of your code is executed by tests.

Common coverage metrics include:

Statement coverage.
Branch coverage.
Function coverage.
Line coverage.

For example, consider:

function getDiscount(price, isMember) {
  if (isMember) {
    return price * 0.9;
  }

  return price;
}

A test for a member:

expect(getDiscount(100, true)).toBe(90);

This doesn't exercise the non-member branch.

You need another test:

expect(getDiscount(100, false)).toBe(100);

Is 100% Coverage Necessary?

Not always.

A project with 100% line coverage can still contain bugs.

Coverage tells you which code was executed, not whether every important behavior was verified correctly.

Focus on:

Business-critical logic.
Payment calculations.
Authentication.
Permissions.
Data transformations.
Error handling.
Important user workflows.

High coverage is useful, but meaningful tests are more important than chasing a percentage.

23. Common React Testing Mistakes

Let's look at mistakes that make tests unreliable or unnecessarily difficult.

Mistake 1: Testing Internal State

Avoid testing implementation details that users cannot observe.

Instead of checking a component's internal state, test the resulting UI.

Bad approach:

// Testing implementation-specific details
expect(componentState).toBe(1);

Better:

expect(
  screen.getByText("Count: 1")
).toBeInTheDocument();

Mistake 2: Using Test IDs Everywhere

This works:

<div data-testid="product-name">
  Laptop
</div>

But prefer accessible queries when possible:

screen.getByText("Laptop");

Or:

screen.getByRole("heading", {
  name: "Laptop",
});

Test IDs are useful when there is no suitable accessible query, but they shouldn't be the default.

Mistake 3: Using Arbitrary Timeouts

Avoid:

await new Promise((resolve) => {
  setTimeout(resolve, 2000);
});

This can make tests slow and unreliable.

Prefer:

await screen.findByText("Data loaded");

Or use Playwright's automatic waiting assertions.

Mistake 4: Testing Too Many Details in One Test

A test should have a clear purpose.

Instead of testing loading, searching, sorting, and checkout in one enormous test, divide the behaviors into focused test cases.

Mistake 5: Ignoring Error States

Don't test only the happy path.

Test failed requests, invalid input, empty data, and unexpected conditions.

Mistake 6: Mocking Everything

Mocks are useful, but excessive mocking can make tests unrealistic.

Keep the important integration boundaries real when possible.

For example, React Testing Library tests can use the real component tree while MSW mocks the network boundary.

Mistake 7: Depending on Test Execution Order

Each test should establish its own required state.

Avoid making one test depend on another test having run first.

24. A Practical Testing Strategy for a React Project

You don't need to write hundreds of tests for every component.

Start by identifying the most important behavior.

For a shopping application, a practical strategy might look like this:

Unit Tests

Test:

Price calculations.
Discount calculations.
Form validation.
Data formatting.
Cart quantity logic.
Utility functions.

Integration Tests

Test:

Login form submission.
Product search.
Cart updates.
Context providers.
API loading and error states.
Form validation and error messages.

End-to-End Tests

Test:

User registration.
Login.
Product browsing.
Adding items to the cart.
Checkout flow.
Important navigation paths.

This gives you coverage at multiple levels without making every test unnecessarily expensive.

Example Project Structure

src/
|
├── components/
│   ├── Button/
│   │   ├── Button.jsx
│   │   └── Button.test.jsx
│   |
│   ├── ProductCard/
│   │   ├── ProductCard.jsx
│   │   └── ProductCard.test.jsx
│
├── features/
│   ├── cart/
│   │   ├── Cart.jsx
│   │   └── Cart.test.jsx
│   |
│   └── products/
│       ├── ProductList.jsx
│       └── ProductList.test.jsx
│
├── utils/
│   ├── calculateTotal.js
│   └── calculateTotal.test.js
│
└── test/
    ├── setup.js
    ├── handlers.js
    └── server.js

e2e/
├── homepage.spec.js
├── search.spec.js
└── checkout.spec.js

Keeping tests close to the code they verify makes them easier to discover and maintain.

25. Running Tests in Continuous Integration

Testing is most useful when it happens regularly.

You can run tests manually, but a professional development workflow should also run them automatically.

For example, a GitHub Actions workflow can run tests whenever code is pushed or a pull request is opened.

Create:

.github/workflows/tests.yml

name: React Tests

on:
  push:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Run unit and integration tests
        run: npm run test:run

      - name: Build application
        run: npm run build

This workflow:

Checks out the repository.
Sets up Node.js.
Installs dependencies.
Runs tests.
Builds the application.

You can add a separate Playwright job for browser tests.

For production projects, pin and update Node.js and GitHub Actions versions according to your team's supported environment.

The important principle is simple:

A pull request should not be considered ready just because the code looks correct. It should also pass the project's automated checks.

26. Final Testing Checklist

Before shipping a React feature, ask yourself:

[ ] Does the important business logic have unit tests?
[ ] Are components tested through visible behavior?
[ ] Do forms have validation tests?
[ ] Are user interactions tested?
[ ] Are loading states tested?
[ ] Are error states tested?
[ ] Are empty states tested?
[ ] Are API responses mocked appropriately?
[ ] Are important workflows covered by end-to-end tests?
[ ] Are tests independent of execution order?
[ ] Are accessible queries used where possible?
[ ] Do automated tests run in CI?
[ ] Does the production build succeed?

Conclusion

Testing is a fundamental part of professional React development.

It helps you catch bugs, prevent regressions, and maintain confidence as your application grows.

The most important concepts from this article are:

Unit tests verify isolated logic.
Integration tests verify connected components and systems.
End-to-end tests verify complete user workflows.
Vitest provides a powerful test runner.
React Testing Library focuses on user-visible behavior.
MSW makes API testing more realistic.
Playwright helps test real browser interactions.
Coverage is useful, but meaningful assertions matter more.
Automated CI checks help prevent broken code from reaching production.

Remember:

A good test doesn't care how your component works internally. It cares whether it behaves correctly for the user.

Start with important business logic, test the critical interactions, and gradually build a reliable testing strategy.

What's Next?

In Part 9 — React with TypeScript: Building Type-Safe Applications, we'll learn how to combine React with TypeScript.

We'll cover:

Why TypeScript matters in React.
Typing component props.
Typing state.
Event types.
Form handling.
Typing Hooks.
Context API with TypeScript.
API response types.
Generics in reusable components.
Common TypeScript mistakes.
Building a practical typed React feature.

See you in Part 9! 🚀

React Mastery Series — Part 7: React Internals — Virtual DOM, Fiber & Reconciliation

Hamed Farazi — Wed, 04 Nov 2026 09:47:56 +0000

You've probably used React for a while.

You know how to create components, manage state, use Hooks, fetch data, and optimize performance.

But have you ever wondered what actually happens when you call setState?

How does React know which part of the interface needs to change?

Why do keys matter when rendering lists?

What is the Virtual DOM, and what does React Fiber do?

Understanding these concepts will help you write better React code, debug difficult problems, and understand why React behaves the way it does.

In this article, we'll explore the internal concepts behind React's rendering process.

1. What Is the Virtual DOM?

The DOM, or Document Object Model, is the browser's representation of an HTML document.

For example:

<div>
  <h1>Hello React</h1>
  <p>Welcome to my application</p>
</div>

The browser represents this structure as a tree of nodes.

When you manipulate the DOM directly, you can change elements, attributes, and text.

For example:

const heading = document.querySelector("h1");

heading.textContent = "Hello World";

React provides a declarative way to describe what the UI should look like.

function App() {
  return (
    <div>
      <h1>Hello React</h1>
      <p>Welcome to my application</p>
    </div>
  );
}

Instead of manually updating DOM nodes, you describe the desired UI, and React manages the updates.

So, What Is the Virtual DOM?

The term Virtual DOM is commonly used to describe React's in-memory representation of UI structure.

React elements are lightweight descriptions of what should appear in the interface.

For example:

const element = (
  <h1 className="title">
    Hello React
  </h1>
);

Conceptually, this describes:

An element of type h1.
A className prop.
A text child.

React uses these descriptions as part of its rendering process.

An important distinction:

React elements are not actual DOM nodes.

They are JavaScript objects describing the UI.

Also, the Virtual DOM is not a browser feature. It is part of the way React models and manages UI updates.

2. Why Does React Use a Virtual Representation?

Imagine building a counter without React.

let count = 0;

const button = document.querySelector("button");

button.addEventListener("click", () => {
  count++;

  document.querySelector("h1").textContent = count;
});

You are responsible for knowing which DOM element needs updating.

Now imagine an application with:

Hundreds of components.
Shared state.
Conditional rendering.
Dynamic lists.
Nested components.
Complex interactions.

Manually managing every DOM update becomes difficult.

React lets you describe the UI based on state:

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

  return (
    <div>
      <h1>{count}</h1>

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

When the state changes, React calculates the next UI and determines which host changes are necessary.

This makes application code more predictable and easier to maintain.

However, don't assume that creating a Virtual DOM automatically makes every React application faster than every manually updated DOM application.

React's main benefit is its declarative programming model and its ability to coordinate updates efficiently.

3. Understanding the React Render Process

When a component's state changes, React doesn't immediately update every DOM element.

There is a process.

A simplified view looks like this:

An update is scheduled.
React renders the affected component tree.
React reconciles the new result with the previous result.
React commits necessary changes to the host environment.
The browser performs its rendering work.

Let's examine these stages.

Step 1: An Update Is Scheduled

Consider:

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

  function increment() {
    setCount(count + 1);
  }

  return (
    <button onClick={increment}>
      Count: {count}
    </button>
  );
}

When the user clicks the button, setCount schedules a state update.

React determines when to process that update according to its scheduling rules and priority.

Step 2: React Renders Components

React calls the relevant component functions to calculate the next UI.

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

  console.log("Rendering Counter");

  return <h1>{count}</h1>;
}

When the state changes, React calls the component again.

This is the render phase.

During rendering, React calculates what the UI should look like.

Step 3: React Reconciles the Result

React compares the new element tree with the previous one.

It determines which parts can be reused and which changes are necessary.

This process is called reconciliation.

Step 4: React Commits Changes

React applies the required changes to the host environment.

For React DOM, this means updating the browser DOM where necessary.

The render phase and commit phase are different.

Render phase: Calculate the next UI.

Commit phase: Apply the necessary changes.

A render does not necessarily result in a DOM mutation.

Step 5: The Browser Updates the Screen

After React commits DOM changes, the browser may need to perform layout, painting, and compositing work.

These browser operations are separate from React's component rendering.

This distinction is important when investigating performance problems.

4. What Is Reconciliation?

Reconciliation is the process React uses to determine how the previous rendered tree relates to the next rendered tree.

Imagine the current UI:

function App() {
  return (
    <div>
      <h1>Hello</h1>
      <p>Welcome</p>
    </div>
  );
}

Now the component changes:

function App() {
  return (
    <div>
      <h1>Hello</h1>
      <p>Welcome to React</p>
    </div>
  );
}

The structure is mostly the same.

Only the text inside the paragraph changed.

React can reuse the existing DOM structure and update the relevant text.

It doesn't need to remove the entire div and recreate everything.

This is one of the practical benefits of reconciliation.

React Uses Heuristics

Comparing two arbitrary trees perfectly can be expensive.

React uses heuristics to make reconciliation efficient.

Some important principles include:

Elements of different types are generally treated as different structures.
Elements of the same type can often be updated in place.
Keys help React match items in collections.

Let's explore each one.

5. Why Element Types Matter

Consider this component:

function App() {
  const [showProfile, setShowProfile] = useState(true);

  return (
    <div>
      {showProfile ? (
        <UserProfile />
      ) : (
        <UserSettings />
      )}
    </div>
  );
}

When showProfile changes, React sees a different component type at that position.

It generally unmounts the previous component and mounts the new one.

This means:

The old component's local state is discarded.
Its cleanup logic runs where applicable.
The new component gets its own state.
Its mounting logic runs.

Now consider two elements of the same type:

function App({ title }) {
  return <h1>{title}</h1>;
}

If title changes, React can reuse the existing h1 DOM element and update its text.

The element type remains the same.

This is why component identity and element types matter.

6. Keys: One of the Most Important Concepts in React

If you've worked with React lists, you've probably seen this warning:

Each child in a list should have a unique "key" prop.

But why does React need keys?

Consider:

function TodoList({ todos }) {
  return (
    <ul>
      {todos.map((todo) => (
        <li>{todo.text}</li>
      ))}
    </ul>
  );
}

React sees a collection of similar elements.

Now imagine inserting a new item at the beginning:

Before:

Apple
Banana
Orange

After:

Strawberry
Apple
Banana
Orange

Without stable keys, React has less information about which old item corresponds to which new item.

Keys provide that identity information.

Correct Usage

function TodoList({ todos }) {
  return (
    <ul>
      {todos.map((todo) => (
        <li key={todo.id}>
          {todo.text}
        </li>
      ))}
    </ul>
  );
}

Now React can match items using their stable IDs.

Why Shouldn't We Use Array Indexes?

Consider:

{todos.map((todo, index) => (
  <TodoItem
    key={index}
    todo={todo}
  />
))}

This might work for a list that never changes order.

But consider a list with local component state.

function TodoItem({ todo }) {
  const [completed, setCompleted] = useState(false);

  return (
    <li>
      <input
        type="checkbox"
        checked={completed}
        onChange={(event) => setCompleted(event.target.checked)}
      />

      {todo.text}
    </li>
  );
}

Imagine checking the second item and then inserting a new item at the beginning.

If indexes are used as keys, React may associate existing component state with different logical items.

The checkbox state can appear on the wrong todo.

Using stable IDs avoids this problem.

When Is an Index Acceptable?

Using an index as a key can be acceptable when:

The list is static.
Items are never inserted or deleted.
Items are never reordered.
There is no identity-sensitive local component state.

Still, stable IDs are usually the better choice.

Keys Are Not Props

This is another important detail.

<ProductCard
  key={product.id}
  product={product}
/>

The key is a special React attribute.

It is not passed to the component as a normal prop.

If your component needs the ID, pass it separately:

<ProductCard
  key={product.id}
  id={product.id}
  product={product}
/>

7. Keys Can Also Reset Component State

Keys aren't only useful in lists.

They can also control component identity.

Consider:

function ProfilePage({ userId }) {
  return <UserProfile userId={userId} />;
}

If userId changes, React may preserve the component's local state because the component type and position remain the same.

Sometimes that's not what you want.

For example, perhaps a profile editor should start fresh when the user changes.

You can use a key:

function ProfilePage({ userId }) {
  return (
    <UserProfile
      key={userId}
      userId={userId}
    />
  );
}

When the key changes, React treats it as a different component identity.

The previous component is removed, and a new one is mounted.

This resets its local state.

It's often cleaner than writing multiple Effects just to reset state when a different entity is selected.

8. What Is React Fiber?

Now let's talk about one of the most important architectural changes in React.

React Fiber is the reconciliation architecture introduced in React 16.

It changed how React represents and processes rendering work.

Before Fiber, React's rendering process was more difficult to interrupt and resume.

Fiber introduced a more flexible architecture that allows React to:

Break rendering work into smaller units.
Schedule work with different priorities.
Pause rendering work.
Resume work later.
Abandon outdated work.
Support concurrent rendering capabilities.

Fiber is an internal implementation detail, but understanding its purpose helps explain modern React behavior.

What Is a Fiber?

A Fiber is an internal JavaScript object representing work associated with a component or another part of the React tree.

A simplified Fiber structure can be thought of as containing information such as:

The component or element type.
Pending props.
Previous props.
State and update information.
Relationships with parent, child, and sibling Fibers.
Effect-related information.
Scheduling and priority information.

The real implementation is more complex.

You don't normally create or manipulate Fiber objects yourself.

How Are Fibers Connected?

Fiber nodes are connected using relationships such as:

return: the parent Fiber.
child: the first child Fiber.
sibling: the next sibling Fiber.

A simplified conceptual structure:

App
 |
 +-- Header
 |
 +-- Main
 |    |
 |    +-- Sidebar
 |    |
 |    +-- Content
 |
 +-- Footer

This representation allows React to traverse the component tree and manage work.

9. The Current Tree and Work-In-Progress Tree

One useful concept in Fiber is that React can maintain two related versions of its tree.

They are commonly referred to as:

Current tree.
Work-in-progress tree.

The current tree represents the committed UI.

The work-in-progress tree represents the next version React is preparing.

A simplified process:

React starts with the current tree.
An update is scheduled.
React prepares work on a work-in-progress tree.
React processes the required rendering work.
If the work completes successfully, React commits the result.
The newly committed tree becomes the current tree.

This architecture helps React prepare updates without immediately changing the committed UI.

It is also part of how React supports concurrent rendering.

The exact internal mechanics are more complicated, but this mental model is useful.

10. What Is Concurrent Rendering?

Concurrent rendering is a capability that allows React to work on rendering updates in a more flexible way.

It does not mean React renders everything simultaneously on multiple CPU cores.

Instead, React can prioritize, pause, resume, or discard rendering work when appropriate.

Imagine a search page with:

An input field.
A very large result list.
Expensive filtering and rendering.

Typing should remain responsive even if updating the results requires more work.

React can use scheduling features to prioritize urgent updates.

For example:

import {
  useState,
  useTransition,
} from "react";

function SearchPage({ products }) {
  const [input, setInput] = useState("");
  const [search, setSearch] = useState("");

  const [isPending, startTransition] = useTransition();

  function handleChange(event) {
    const value = event.target.value;

    setInput(value);

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

  const filteredProducts = products.filter((product) =>
    product.name.toLowerCase().includes(search.toLowerCase())
  );

  return (
    <div>
      <input
        value={input}
        onChange={handleChange}
        placeholder="Search products..."
      />

      {isPending && <p>Updating results...</p>}

      {filteredProducts.map((product) => (
        <p key={product.id}>
          {product.name}
        </p>
      ))}
    </div>
  );
}

The input update is urgent.

The search update is marked as a transition.

React can prioritize the urgent update while managing the transition work.

Important: Concurrent Rendering Is Not a Guarantee of Faster Code

Concurrent capabilities improve scheduling flexibility and responsiveness.

They don't automatically make expensive calculations cheaper.

If a calculation takes 500 milliseconds, React still needs an efficient way to perform that calculation.

You may need:

Better algorithms.
Memoization.
Pagination.
Virtualization.
Web Workers for CPU-intensive tasks.

Scheduling and computational efficiency are different concerns.

11. React Rendering Can Be Interrupted

This is one of the major ideas behind Fiber.

In suitable situations, React can pause rendering work and continue it later.

Imagine React is preparing a low-priority update.

Then the user performs an urgent interaction.

React can prioritize the urgent work rather than requiring every unit of the previous render to finish first.

It can also discard outdated work.

For example, imagine the user types:

R
Re
Rea
Reac
React

If React is still preparing an update for Rea when a newer update arrives, it may abandon the outdated render and work toward the latest result.

This helps avoid wasting time on UI states that are no longer relevant.

There are two important qualifications:

React rendering work can be interrupted in concurrent scenarios.
The commit phase is synchronous; React does not partially commit a tree and then pause halfway through applying that commit.

Also, component render functions should remain pure.

A render can happen more than once, and work that never commits should not produce external side effects.

12. Why React Components Should Be Pure

React expects components to behave like pure functions with respect to their props, state, and context.

A pure component render should:

Return the same UI for the same inputs.
Avoid modifying external variables.
Avoid performing network requests.
Avoid directly changing the DOM.
Avoid updating unrelated state during rendering.

Bad example:

let total = 0;

function Product({ price }) {
  total += price;

  return <p>${price}</p>;
}

Every render changes an external variable.

If React renders the component more than once, total may become incorrect.

Better:

function Product({ price }) {
  return <p>${price}</p>;
}

If you need to calculate a total, derive it from data:

function Cart({ products }) {
  const total = products.reduce(
    (sum, product) => sum + product.price,
    0
  );

  return <h2>Total: ${total}</h2>;
}

This is predictable and safe.

What About Side Effects?

Side effects belong in appropriate places:

Event handlers for user-triggered actions.
Effects for synchronizing with external systems.
Framework-specific server or data-loading mechanisms where appropriate.

For example:

function SaveButton() {
  async function handleSave() {
    await fetch("/api/save", {
      method: "POST",
    });
  }

  return (
    <button onClick={handleSave}>
      Save
    </button>
  );
}

The network request happens because of a user action, not because React happened to render the component.

This distinction is especially important in concurrent rendering.

13. Why Strict Mode May Render Components More Than Once

You may have noticed something strange during development.

A component logs twice:

function App() {
  console.log("App rendered");

  return <h1>Hello</h1>;
}

Why?

If your application uses Strict Mode:

import { StrictMode } from "react";
import { createRoot } from "react-dom/client";

createRoot(document.getElementById("root")).render(
  <StrictMode>
    <App />
  </StrictMode>
);

React performs additional development-only checks to help identify unsafe behavior.

In particular, Strict Mode can call component functions an extra time during development to help reveal impure rendering.

Effects also receive an extra setup-and-cleanup cycle in development under Strict Mode.

This is intentional.

It helps detect problems such as:

Missing cleanup logic.
Impure rendering.
Incorrect assumptions about component mounting.
Effects that don't safely handle repeated setup.

These development checks do not mean production components will behave identically.

Don't remove Strict Mode just because you see extra logs.

Instead, make your components and Effects safe.

14. What Happens When State Changes?

Let's look at a slightly more realistic example.

function Dashboard() {
  const [user, setUser] = useState({
    name: "Alex",
    role: "Developer",
  });

  function updateRole() {
    setUser({
      ...user,
      role: "Senior Developer",
    });
  }

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.role}</p>

      <button onClick={updateRole}>
        Update Role
      </button>
    </div>
  );
}

When the user clicks the button:

setUser schedules an update.
React processes the update.
Dashboard renders again.
React creates the next element descriptions.
React reconciles the new result.
React commits the required DOM changes.

The browser doesn't need to replace the entire page.

The heading text is unchanged.

The paragraph text changes.

React can reuse the existing DOM elements and update the necessary text.

This is the combination of rendering, reconciliation, and committing.

15. Batching: Why Multiple State Updates Can Produce One Render

React also uses batching to group state updates.

Consider:

function Counter() {
  const [count, setCount] = useState(0);
  const [name, setName] = useState("Alex");

  function handleClick() {
    setCount((current) => current + 1);
    setName("Jordan");
  }

  return (
    <div>
      <p>Count: {count}</p>
      <p>Name: {name}</p>

      <button onClick={handleClick}>
        Update
      </button>
    </div>
  );
}

React can batch these updates so that they are processed together, rather than necessarily rendering after each individual setter call.

Modern React supports automatic batching in many update contexts, including common asynchronous callbacks.

This reduces unnecessary rendering work.

However, batching doesn't mean every state update in every possible situation is always combined into one render.

The exact behavior depends on the update context and React APIs being used.

Functional State Updates

When the next state depends on the previous state, use a functional update:

setCount((current) => current + 1);

This is especially useful when multiple updates are scheduled:

function handleClick() {
  setCount((current) => current + 1);
  setCount((current) => current + 1);
  setCount((current) => current + 1);
}

The final count increases by three.

React processes each updater using the result of the previous updater.

16. The Difference Between React Elements, Components, and DOM Nodes

These terms are often confused.

Let's clarify them.

Component

A component is a function or class that describes a part of the UI.

function Greeting() {
  return <h1>Hello</h1>;
}

React Element

A React element is an object describing what should appear in the UI.

const element = <Greeting />;

Conceptually, this is a description of a component element.

DOM Node

A DOM node is an actual browser object representing part of the document.

For example:

const heading = document.querySelector("h1");

This returns a real DOM element.

The relationship is:

Components describe UI.
React elements represent descriptions of UI.
React DOM translates the resulting work into browser DOM operations.

This distinction makes many React concepts easier to understand.

17. A Mental Model of React Internals

Let's bring everything together.

User interaction
      |
      v
State update scheduled
      |
      v
React begins rendering
      |
      v
Component functions execute
      |
      v
New React elements are created
      |
      v
Reconciliation
      |
      v
Work-in-progress tree prepared
      |
      v
Commit phase
      |
      v
Necessary DOM updates
      |
      v
Browser rendering

This is a simplified mental model, not a complete description of every internal operation.

In concurrent scenarios, rendering work may be interrupted, resumed, or discarded before a commit.

But the main concepts are:

Render: Calculate the next UI.
Reconciliation: Determine how the new UI relates to the previous UI.
Fiber: React's internal architecture for managing rendering work.
Commit: Apply the required changes.
Keys: Help React preserve identity in collections and component trees.

18. Practical Rules Based on React Internals

Now that you understand the fundamentals, here are some practical rules to apply in real projects.

Rule 1: Keep Rendering Pure

Don't perform side effects inside component rendering.

Rule 2: Use Stable Keys

Use stable identifiers for dynamic collections.

Rule 3: Understand Component Identity

Changing a component's type or key can cause it to unmount and mount again.

Rule 4: Don't Assume Every Render Changes the DOM

React can render a component without committing any DOM changes.

Rule 5: Don't Fight React's Rendering Model

Avoid manual DOM manipulation unless you're integrating with an external system that requires it.

Rule 6: Keep State Updates Predictable

Use immutable updates and functional state setters when appropriate.

Rule 7: Use Strict Mode

Let development checks reveal problems early.

Rule 8: Optimize Based on Measurements

Understanding Fiber doesn't mean you need to manually control it.

Use React's public APIs and performance tools rather than depending on internal implementation details.

19. Common Misconceptions About React Internals

Let's clear up a few common misunderstandings.

Misconception 1: The Virtual DOM is always faster than the real DOM.

Not necessarily. React's performance depends on the application, update patterns, and the work being performed.

Misconception 2: Every component render updates the browser DOM.

No. Rendering calculates the next UI. The commit phase applies necessary changes.

Misconception 3: Keys are only needed to remove React warnings.

No. Keys help React preserve the identity of elements across collection updates.

Misconception 4: Fiber means React uses multiple CPU threads.

No. Fiber enables flexible scheduling and interruptible rendering. It does not mean component rendering automatically happens in parallel across CPU cores.

Misconception 5: Concurrent rendering means every update is interruptible.

No. React's scheduling capabilities depend on the type and priority of the work. The commit phase is synchronous.

Misconception 6: Strict Mode double rendering happens in production.

The extra development checks are development-only behavior.

Misconception 7: React directly updates the DOM during the render phase.

No. React separates calculating the next UI from committing host changes.

20. Final Checklist

Before moving on, make sure you understand these concepts:

[ ] What the Virtual DOM term describes.
[ ] The difference between a component and a React element.
[ ] The difference between rendering and committing.
[ ] What reconciliation means.
[ ] Why element types matter.
[ ] Why stable keys are important.
[ ] How keys can reset component state.
[ ] What React Fiber is.
[ ] What a Fiber node represents.
[ ] The purpose of current and work-in-progress trees.
[ ] What concurrent rendering means.
[ ] Why components should be pure.
[ ] Why Strict Mode can produce extra development renders.
[ ] How batching helps reduce unnecessary updates.

Conclusion

React is much more than a library that turns JSX into HTML.

Behind its declarative API is a sophisticated rendering architecture designed to manage UI updates efficiently.

The most important ideas from this article are:

React elements describe the UI.
Rendering calculates the next UI.
Reconciliation determines how the new tree relates to the previous one.
Fiber allows React to manage rendering work more flexibly.
The commit phase applies the necessary host changes.
Keys help React preserve element identity.
Concurrent rendering improves scheduling flexibility.
Pure components make rendering predictable and safe.

You don't need to understand every internal detail to build excellent React applications.

But understanding these fundamentals gives you a much stronger mental model of how React works.

And that makes debugging, performance optimization, and architecture decisions easier.

What's Next?

In Part 8 — React Testing: Unit, Integration & End-to-End Testing, we'll learn how to test React applications with confidence.

We'll cover:

Why testing matters.
Unit testing components and utilities.
Integration testing.
React Testing Library.
User interactions and accessible queries.
Mocking API requests.
Testing asynchronous UI.
End-to-end testing with Playwright.
Common testing mistakes.
Building a practical testing strategy.

See you in Part 8! 🚀

React Mastery Series — Part 6: React Performance Optimization

Hamed Farazi — Wed, 04 Nov 2026 09:42:58 +0000

A React application can work perfectly and still feel slow.

Maybe typing into a search box causes the entire page to lag. Maybe a product list takes too long to render. Maybe users have to download a huge JavaScript bundle before they can interact with your application.

These are performance problems.

The good news is that React provides several tools and patterns to help us build responsive applications. The important part is knowing when to use them, why they work, and how to measure their impact.

In this article, we'll explore practical React performance optimization techniques, from understanding re-renders to memoization, list virtualization, code splitting, and responsive updates.

1. What Does Performance Actually Mean?

Performance is more than just making a page load quickly.

When evaluating a React application, consider several dimensions:

Area	What it means
Initial load	How quickly the application becomes usable
Responsiveness	How quickly the application reacts to user input
Rendering	How efficiently React updates the interface
Bundle size	How much JavaScript users need to download
Memory usage	How much memory the application consumes
Network performance	How efficiently data and assets are requested

For example:

A page might load quickly but freeze when filtering 10,000 products.
A page might render smoothly but download several megabytes of JavaScript.
A search field might work correctly but feel sluggish because every keystroke triggers expensive work.

Good performance means improving the experience as a whole.

2. Measure Before You Optimize

One of the biggest mistakes developers make is optimizing code based on assumptions.

You see a component with several state variables and immediately add useMemo, useCallback, and React.memo.

But are those components actually causing a performance problem?

Measure first.

React Developer Tools Profiler

The React Developer Tools browser extension includes a Profiler.

It helps you understand:

Which components rendered.
How frequently they rendered.
How long rendering took.
Which updates caused components to render.
Whether memoization prevented unnecessary work.

A useful workflow:

Open your application.
Open React Developer Tools.
Select the Profiler tab.
Start recording.
Interact with the application.
Stop recording.
Inspect the components that rendered.

Look for components that render frequently or take unusually long.

Browser Performance Panel

The browser's Performance panel helps investigate work beyond React rendering.

It can reveal:

JavaScript execution time.
Long tasks.
Layout and painting work.
Event processing delays.
Main-thread bottlenecks.

This is particularly useful when the application feels frozen or interactions are delayed.

Lighthouse

Lighthouse provides an overview of website performance and other quality metrics.

It can help identify:

Large JavaScript bundles.
Render-blocking resources.
Image optimization opportunities.
Loading performance problems.
Accessibility and SEO issues.

These tools serve different purposes:

React Profiler: Investigates React component rendering.
Browser Performance: Investigates browser execution and rendering.
Lighthouse: Audits overall page quality and loading performance.

Don't optimize blindly. Find the bottleneck first.

3. Understand How React Rendering Works

Before optimizing React, we need to understand what happens when a component renders.

Consider:

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

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

When the button is clicked:

The state update is scheduled.
React calls the component function again.
React calculates the next UI.
React compares the result with the previous render.
React commits the necessary changes to the DOM.

There are two important concepts:

Render phase: React calls components and calculates what the next UI should look like.

Commit phase: React applies the required changes to the DOM and performs related commit work.

A component rendering again does not necessarily mean the browser DOM changes.

What Triggers a Re-render?

Common causes include:

The component's own state changes.
Its parent renders again.
A Context value it consumes changes.
A subscribed external store reports an update.

For example:

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

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

      <Child />
    </div>
  );
}

function Child() {
  console.log("Child rendered");

  return <p>Hello from Child</p>;
}

Every time Parent renders, Child normally renders too.

Even though Child doesn't use count, it still participates in the render.

This is normal React behavior. It is not automatically a performance problem.

The goal is not to prevent every render. The goal is to avoid expensive, unnecessary work.

4. Avoid Keeping State Too High in the Component Tree

One common performance problem is placing state higher in the component tree than necessary.

Consider:

function App() {
  const [search, setSearch] = useState("");

  return (
    <div>
      <Header />
      <SearchBox
        value={search}
        onChange={setSearch}
      />
      <ProductList />
      <Footer />
    </div>
  );
}

Every time the user types, App renders again.

That means its children may render again too.

If the search state is only needed by the search feature, consider moving it closer to where it is used.

function SearchSection() {
  const [search, setSearch] = useState("");

  return (
    <>
      <SearchBox
        value={search}
        onChange={setSearch}
      />

      <ProductList search={search} />
    </>
  );
}

function App() {
  return (
    <div>
      <Header />
      <SearchSection />
      <Footer />
    </div>
  );
}

Now typing doesn't directly cause App to render.

This pattern is called state locality.

A useful rule:

Keep state as close as possible to the components that need it.

This often provides more benefit than adding memoization everywhere.

5. React.memo: Prevent Unnecessary Child Renders

React provides memo to skip rendering a component when its props have not changed.

Example:

import { memo, useState } from "react";

const UserCard = memo(function UserCard({ user }) {
  console.log("UserCard rendered");

  return (
    <div>
      <h3>{user.name}</h3>
      <p>{user.email}</p>
    </div>
  );
});

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

  const user = {
    name: "Alex",
    email: "alex@example.com",
  };

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>
        Count: {count}
      </button>

      <UserCard user={user} />
    </div>
  );
}

There is a problem.

Every time App renders, it creates a new object:

const user = {
  name: "Alex",
  email: "alex@example.com",
};

Even though the values are identical, the object has a new reference.

React's default memo comparison checks props using shallow comparison. The new object means the user prop is considered changed.

As a result, UserCard renders again.

We can solve this with useMemo:

import {
  memo,
  useMemo,
  useState,
} from "react";

const UserCard = memo(function UserCard({ user }) {
  console.log("UserCard rendered");

  return (
    <div>
      <h3>{user.name}</h3>
      <p>{user.email}</p>
    </div>
  );
});

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

  const user = useMemo(() => ({
    name: "Alex",
    email: "alex@example.com",
  }), []);

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>
        Count: {count}
      </button>

      <UserCard user={user} />
    </div>
  );
}

Now the user reference remains stable between renders, so memo can skip rendering UserCard when its other relevant conditions are unchanged.

When Should You Use React.memo?

Consider it when:

A component renders frequently.
Rendering is relatively expensive.
Its props often remain unchanged.
Profiling shows that skipping the render is beneficial.

Don't wrap every component in memo.

Memoization has its own costs, and it does not prevent renders caused by the component's own state or consumed Context changing.

6. useMemo: Cache Expensive Calculations

Sometimes the problem isn't rendering a child component.

Sometimes the component performs an expensive calculation on every render.

Consider:

function ProductList({ products, search }) {
  const filteredProducts = products.filter((product) =>
    product.name
      .toLowerCase()
      .includes(search.toLowerCase())
  );

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

If filtering is expensive and the component renders frequently, we may want to cache the result.

import { useMemo } from "react";

function ProductList({ products, search }) {
  const filteredProducts = useMemo(() => {
    return products.filter((product) =>
      product.name
        .toLowerCase()
        .includes(search.toLowerCase())
    );
  }, [products, search]);

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

React recalculates the filtered list when products or search changes.

Otherwise, it can reuse the previous result.

Important: useMemo Is Not Always Necessary

This is usually unnecessary:

const fullName = useMemo(() => {
  return firstName + " " + lastName;
}, [firstName, lastName]);

The calculation is extremely cheap.

Just write:

const fullName = firstName + " " + lastName;

Use useMemo when:

A calculation is genuinely expensive.
A stable object or array reference helps a memoized child.
Profiling shows a meaningful improvement.

useMemo is a performance optimization, not a semantic guarantee. Your application should remain correct even if React recalculates the value.

7. useCallback: Cache Function References

Functions are objects in JavaScript.

When a component renders, functions declared inside it are recreated.

Consider:

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

  const handleClick = () => {
    console.log("Clicked");
  };

  return (
    <>
      <button onClick={() => setCount(count + 1)}>
        Count: {count}
      </button>

      <Child onClick={handleClick} />
    </>
  );
}

Even if the function's behavior hasn't changed, its reference is different after each render.

If Child is memoized, this new function can cause it to render again.

We can use useCallback:

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

const Child = memo(function Child({ onClick }) {
  console.log("Child rendered");

  return (
    <button onClick={onClick}>
      Click Child
    </button>
  );
});

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

  const handleClick = useCallback(() => {
    console.log("Clicked");
  }, []);

  return (
    <>
      <button onClick={() => setCount(count + 1)}>
        Count: {count}
      </button>

      <Child onClick={handleClick} />
    </>
  );
}

Now the function reference remains stable between renders.

When Does useCallback Help?

It is useful when:

Passing callbacks to memoized children.
A callback is a dependency of another Hook.
Stable function identity prevents meaningful unnecessary work.

It is not necessary for every event handler.

Also remember that dependencies matter:

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

Here, count must be included because the callback reads it.

An alternative is using a functional state update:

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

This callback no longer needs to capture count.

8. React Compiler and Automatic Memoization

Modern React development also includes the React Compiler.

In projects where it is correctly configured and enabled, the compiler can automatically optimize certain components, values, and functions.

This can reduce the need for manually adding memo, useMemo, and useCallback.

However:

It is not automatically enabled in every React project.
Your build setup must support it.
You should follow the configuration requirements for your environment.
It does not eliminate the need to understand performance fundamentals.

Manual memoization is still useful when working in environments without the compiler or when investigating specific performance problems.

The best approach is to understand what causes unnecessary work and use the optimization tools your project supports.

9. Use Component Composition to Reduce Re-rendering

Sometimes you can improve performance by changing the component structure rather than adding Hooks.

Imagine an expensive component that doesn't depend on a piece of frequently changing state.

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

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>
        Count: {count}
      </button>

      <ExpensiveComponent />
    </div>
  );
}

ExpensiveComponent renders whenever App renders.

One option is memoization. Another is component composition:

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

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

function App() {
  return (
    <div>
      <Counter />
      <ExpensiveComponent />
    </div>
  );
}

Now the state update happens inside Counter, so it doesn't require App to render again.

You can also pass stable children into a component that owns state:

function Layout({ children }) {
  const [open, setOpen] = useState(false);

  return (
    <div>
      <button onClick={() => setOpen(!open)}>
        Toggle
      </button>

      {open && <p>Menu is open</p>}

      <main>{children}</main>
    </div>
  );
}

function App() {
  return (
    <Layout>
      <ExpensiveComponent />
    </Layout>
  );
}

When Layout updates its own state, the children prop can remain the same reference because it was created by the parent.

This can help avoid unnecessary work in the child subtree.

Composition is often a clean architectural solution.

10. Avoid Unnecessary Effects and Derived State

Another source of unnecessary renders is storing values in state when they can be calculated from existing data.

Consider:

function ProductList({ products }) {
  const [search, setSearch] = useState("");
  const [filteredProducts, setFilteredProducts] = useState([]);

  useEffect(() => {
    const result = products.filter((product) =>
      product.name
        .toLowerCase()
        .includes(search.toLowerCase())
    );

    setFilteredProducts(result);
  }, [products, search]);

  return (
    // Render filteredProducts
    <div />
  );
}

This introduces an unnecessary update cycle:

search changes.
React renders the component.
The Effect runs.
The Effect updates filteredProducts.
React renders again.

You don't need an Effect here.

Calculate the derived value during rendering:

function ProductList({ products }) {
  const [search, setSearch] = useState("");

  const filteredProducts = products.filter((product) =>
    product.name
      .toLowerCase()
      .includes(search.toLowerCase())
  );

  return (
    <div>
      <input
        value={search}
        onChange={(event) => setSearch(event.target.value)}
        placeholder="Search products..."
      />

      {filteredProducts.map((product) => (
        <p key={product.id}>
          {product.name}
        </p>
      ))}
    </div>
  );
}

If the calculation is expensive, add useMemo.

The general rule:

Don't use an Effect to synchronize values that can be calculated from existing props or state during rendering.

Also, logic that belongs to a user action should usually live in the event handler.

For example, if clicking a button should submit a form, perform that action in the click or submit handler rather than watching a state variable with an Effect.

Effects are primarily for synchronizing React with external systems, such as subscriptions, browser APIs, timers, and network connections.

11. Optimize Large Lists

Rendering large lists can be expensive.

Imagine displaying 10,000 products:

function ProductList({ products }) {
  return (
    <div>
      {products.map((product) => (
        <ProductCard
          key={product.id}
          product={product}
        />
      ))}
    </div>
  );
}

React can handle lists, but rendering thousands of complex DOM elements can consume significant time and memory.

There are several strategies.

A. Use Stable Keys

Always use stable identifiers when rendering collections.

Good:

{products.map((product) => (
  <ProductCard
    key={product.id}
    product={product}
  />
))}

Avoid using array indexes when items can be inserted, deleted, reordered, or filtered:

{products.map((product, index) => (
  <ProductCard
    key={index}
    product={product}
  />
))}

Indexes can cause React to associate the wrong component state with an item after the list changes.

B. Use Pagination

Instead of rendering every item, render a limited number at a time.

function ProductList({ products }) {
  const [page, setPage] = useState(1);

  const pageSize = 20;

  const startIndex = (page - 1) * pageSize;

  const visibleProducts = products.slice(
    startIndex,
    startIndex + pageSize
  );

  return (
    <div>
      {visibleProducts.map((product) => (
        <p key={product.id}>
          {product.name}
        </p>
      ))}

      <button
        disabled={page === 1}
        onClick={() => setPage((current) => current - 1)}
      >
        Previous
      </button>

      <button
        disabled={startIndex + pageSize >= products.length}
        onClick={() => setPage((current) => current + 1)}
      >
        Next
      </button>
    </div>
  );
}

Pagination reduces the number of items rendered at once.

C. Use Virtualization

Virtualization, also called windowing, renders only the items currently visible in the viewport, plus a small buffer.

Instead of rendering 10,000 rows, the application might render only 20 or 30 at a time.

Popular libraries include:

react-window
@tanstack/react-virtual

Virtualization is especially useful for:

Large tables.
Long product lists.
Activity feeds.
Logs.
Data-heavy dashboards.

Remember that virtualization adds complexity. For smaller lists, ordinary rendering may be perfectly sufficient.

12. Code Splitting and Lazy Loading

A common performance problem is downloading the entire application before users need it.

Imagine an application with:

Dashboard
Reports
Settings
Admin panel
Analytics

A user opening the dashboard may not need the analytics module immediately.

Code splitting allows us to load parts of the application when they are needed.

React.lazy

React provides lazy for loading components dynamically.

import { lazy, Suspense } from "react";

const Dashboard = lazy(() => import("./Dashboard"));
const Reports = lazy(() => import("./Reports"));

function App() {
  const [page, setPage] = useState("dashboard");

  return (
    <div>
      <button onClick={() => setPage("dashboard")}>
        Dashboard
      </button>

      <button onClick={() => setPage("reports")}>
        Reports
      </button>

      <Suspense fallback={<p>Loading page...</p>}>
        {page === "dashboard" ? (
          <Dashboard />
        ) : (
          <Reports />
        )}
      </Suspense>
    </div>
  );
}

The dynamically imported components can be loaded as separate chunks by a supporting build tool.

Suspense displays fallback UI while the lazy component is loading.

Route-Level Code Splitting

In larger applications, splitting code by route is often a good starting point.

For example:

const HomePage = lazy(() => import("./pages/HomePage"));
const ProfilePage = lazy(() => import("./pages/ProfilePage"));
const SettingsPage = lazy(() => import("./pages/SettingsPage"));

Then configure your routing system to load the appropriate page.

This can reduce the amount of JavaScript users need during the initial visit.

Don't forget to provide useful loading states. A blank screen is not a great user experience.

13. Optimize Images and Static Assets

JavaScript isn't the only source of performance problems.

Large images can significantly affect loading performance.

Consider these practices:

Use Appropriate Image Dimensions

Don't load a 4000-pixel image when the UI displays it at 300 pixels.

Serve an image close to the size actually needed.

Use Modern Formats

Formats such as WebP and AVIF can often reduce image size while maintaining good visual quality.

Lazy-Load Below-the-Fold Images

<img
  src="/images/product.webp"
  alt="Product"
  loading="lazy"
  width="400"
  height="300"
/>

The browser can defer loading images that are not immediately needed.

However, don't blindly lazy-load critical images near the top of the page.

For an important hero image, eager loading or an appropriate fetch priority may be more suitable.

Use Responsive Images

<img
  src="/images/product-800.webp"
  srcSet="
    /images/product-400.webp 400w,
    /images/product-800.webp 800w,
    /images/product-1200.webp 1200w
  "
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="Product"
  width="800"
  height="600"
/>

This allows the browser to select an appropriate image resource based on the display context.

Providing width and height also helps prevent layout shifts.

14. Reduce JavaScript Bundle Size

A large bundle can make an application slower to download, parse, and execute.

Some practical strategies:

Analyze Your Bundle

Use a bundle analyzer compatible with your build tool.

For example, Vite projects can use bundle visualization plugins to inspect which dependencies contribute most to the output.

Look for:

Large libraries.
Duplicate dependencies.
Unused code.
Modules that could be loaded on demand.

Avoid Unnecessarily Large Dependencies

Before adding a library, ask:

Do I really need it?
Can native JavaScript solve this problem?
Is there a smaller alternative?
Am I importing more than I use?

Use Tree Shaking

Tree shaking removes unused exports from production bundles when your build setup and dependencies support it.

Prefer clear imports:

import { format } from "date-fns";

But remember: actual tree-shaking behavior depends on the package's module format and build configuration.

Don't assume that every dependency will be optimized perfectly.

15. Keep Interfaces Responsive with useTransition

Sometimes an update is expensive, but the user should still be able to interact with the interface.

React provides useTransition to mark certain state updates as non-urgent.

Example:

import { useState, useTransition } from "react";

function SearchPage({ products }) {
  const [input, setInput] = useState("");
  const [search, setSearch] = useState("");

  const [isPending, startTransition] = useTransition();

  function handleChange(event) {
    const value = event.target.value;

    setInput(value);

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

  const filteredProducts = products.filter((product) =>
    product.name.toLowerCase().includes(search.toLowerCase())
  );

  return (
    <div>
      <input
        value={input}
        onChange={handleChange}
        placeholder="Search products..."
      />

      {isPending && <p>Updating results...</p>}

      <div>
        {filteredProducts.map((product) => (
          <p key={product.id}>
            {product.name}
          </p>
        ))}
      </div>
    </div>
  );
}

Here:

input updates urgently, keeping the input responsive.
search updates as a transition.
React can prioritize urgent updates over transition work.

Important: useTransition does not make an expensive calculation inherently faster.

It helps React schedule updates so urgent interactions can remain responsive.

16. useDeferredValue: Defer Expensive UI Updates

useDeferredValue is another tool for keeping interfaces responsive.

It allows a part of the UI to use a deferred version of a value.

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

const ProductResults = memo(function ProductResults({
  products,
  search,
}) {
  const filteredProducts = products.filter((product) =>
    product.name
      .toLowerCase()
      .includes(search.toLowerCase())
  );

  return (
    <div>
      {filteredProducts.map((product) => (
        <p key={product.id}>
          {product.name}
        </p>
      ))}
    </div>
  );
});

function SearchPage({ products }) {
  const [search, setSearch] = useState("");

  const deferredSearch = useDeferredValue(search);

  return (
    <div>
      <input
        value={search}
        onChange={(event) => setSearch(event.target.value)}
        placeholder="Search..."
      />

      <ProductResults
        products={products}
        search={deferredSearch}
      />
    </div>
  );
}

The input receives the latest value immediately, while the results can update using the deferred value.

This can improve the perceived responsiveness of expensive UI.

A useful distinction:

useTransition lets you mark state updates as non-urgent.
useDeferredValue lets you defer updating a value used by part of the UI.

Neither replaces proper optimization of genuinely expensive calculations.

17. Don't Ignore Network Performance

A React application can render efficiently and still feel slow because it waits too long for data.

Consider these techniques:

Pagination on the Server

Don't fetch 50,000 records if the user only needs the first 20.

Request data in manageable pages.

Cache Server Data

Libraries such as TanStack Query help manage server state with features such as caching, background refetching, and request lifecycle management.

This can reduce unnecessary network requests and improve perceived performance.

Debounce Search Requests

If every keystroke sends a request, the application may generate unnecessary traffic.

Debouncing waits until the user pauses typing before triggering the request.

A simple example:

import { useEffect, useState } from "react";

function SearchBox() {
  const [query, setQuery] = useState("");
  const [debouncedQuery, setDebouncedQuery] = useState("");

  useEffect(() => {
    const timer = setTimeout(() => {
      setDebouncedQuery(query);
    }, 300);

    return () => clearTimeout(timer);
  }, [query]);

  useEffect(() => {
    if (!debouncedQuery.trim()) return;

    console.log("Fetch results for:", debouncedQuery);
  }, [debouncedQuery]);

  return (
    <input
      value={query}
      onChange={(event) => setQuery(event.target.value)}
      placeholder="Search..."
    />
  );
}

In a real application, connect the second Effect to your API layer.

Also consider:

Cancelling obsolete requests with AbortController.
Handling race conditions.
Avoiding duplicate requests.
Showing loading and error states.

18. Practical Example: Optimizing a Searchable Product List

Let's combine several concepts.

Imagine a page with:

A search field.
A product list.
A counter unrelated to the search.
Product filtering.

Here is a simple implementation:

import { useState } from "react";

function ProductCard({ product }) {
  console.log("Rendering:", product.name);

  return (
    <article>
      <h3>{product.name}</h3>
      <p>${product.price}</p>
    </article>
  );
}

function ProductList({ products, search }) {
  const filteredProducts = products.filter((product) =>
    product.name
      .toLowerCase()
      .includes(search.toLowerCase())
  );

  return (
    <div>
      {filteredProducts.map((product) => (
        <ProductCard
          key={product.id}
          product={product}
        />
      ))}
    </div>
  );
}

export default function App() {
  const [search, setSearch] = useState("");
  const [count, setCount] = useState(0);

  const products = [
    { id: 1, name: "Laptop", price: 1200 },
    { id: 2, name: "Phone", price: 800 },
    { id: 3, name: "Keyboard", price: 100 },
  ];

  return (
    <main>
      <h1>Products</h1>

      <input
        value={search}
        onChange={(event) => setSearch(event.target.value)}
        placeholder="Search products..."
      />

      <button onClick={() => setCount((c) => c + 1)}>
        Counter: {count}
      </button>

      <ProductList
        products={products}
        search={search}
      />
    </main>
  );
}

This example has a few opportunities for improvement:

products is recreated whenever App renders.
Filtering runs whenever ProductList renders.
Product cards can render again even when their data hasn't changed.
Counter updates can trigger work unrelated to the counter.

Here is a more optimized structure:

import {
  memo,
  useMemo,
  useState,
} from "react";

const ProductCard = memo(function ProductCard({ product }) {
  return (
    <article>
      <h3>{product.name}</h3>
      <p>${product.price}</p>
    </article>
  );
});

function ProductSearch({ products }) {
  const [search, setSearch] = useState("");

  const filteredProducts = useMemo(() => {
    const normalizedSearch = search.toLowerCase();

    return products.filter((product) =>
      product.name
        .toLowerCase()
        .includes(normalizedSearch)
    );
  }, [products, search]);

  return (
    <section>
      <input
        value={search}
        onChange={(event) => setSearch(event.target.value)}
        placeholder="Search products..."
      />

      <div>
        {filteredProducts.map((product) => (
          <ProductCard
            key={product.id}
            product={product}
          />
        ))}
      </div>
    </section>
  );
}

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

  return (
    <button onClick={() => setCount((c) => c + 1)}>
      Counter: {count}
    </button>
  );
}

export default function App() {
  const products = [
    { id: 1, name: "Laptop", price: 1200 },
    { id: 2, name: "Phone", price: 800 },
    { id: 3, name: "Keyboard", price: 100 },
  ];

  return (
    <main>
      <h1>Products</h1>

      <Counter />

      <ProductSearch products={products} />
    </main>
  );
}

Now the counter's state is isolated, so updating it doesn't cause the product search component to render again.

The product list also memoizes its filtering calculation.

One important detail: in this example, the products array is created inside App. If App later gains state that changes, that array will receive a new reference. In a real application, keep static data outside the component, obtain it from a stable data source, or memoize it when necessary.

This example illustrates an important lesson:

Good component architecture is often the first performance optimization.

19. Common Performance Optimization Mistakes

Avoid these mistakes:

1. Using memoization everywhere

Memoization adds complexity and has its own costs.

Optimize components that actually need it.

2. Using useEffect for derived state

This can introduce unnecessary render cycles.

Calculate derived values during rendering instead.

3. Rendering thousands of DOM elements

Consider pagination or virtualization for genuinely large lists.

4. Ignoring bundle size

A fast component won't help much if users must download an unnecessarily large application.

5. Optimizing without measuring

You might spend hours improving code that isn't responsible for the slowdown.

6. Using unstable keys

Incorrect keys can cause bugs and unnecessary component work.

7. Treating useTransition as a performance magic button

Transitions improve scheduling and responsiveness. They don't automatically make calculations cheaper.

20. Performance Optimization Checklist

Before shipping a React application, review this checklist:

[ ] Have I measured performance before optimizing?
[ ] Have I checked expensive components with React Profiler?
[ ] Is state located close to where it is needed?
[ ] Am I avoiding unnecessary Effects?
[ ] Are expensive calculations cached when measurement justifies it?
[ ] Are memoized components receiving stable props?
[ ] Am I using stable keys for dynamic lists?
[ ] Should large lists use pagination or virtualization?
[ ] Have I implemented code splitting where useful?
[ ] Are images properly sized and optimized?
[ ] Have I checked the production bundle size?
[ ] Am I avoiding unnecessary network requests?
[ ] Does the interface remain responsive during expensive updates?

Conclusion

React performance optimization is not about adding as many Hooks as possible.

It's about understanding where time is being spent and choosing the right solution.

The most important principles are:

Measure before optimizing.
Understand why components render.
Keep state close to where it is needed.
Use memo, useMemo, and useCallback when they provide measurable value.
Avoid unnecessary Effects and duplicate state.
Optimize large lists with pagination or virtualization.
Use code splitting and lazy loading.
Optimize images, bundles, and network requests.
Keep urgent interactions responsive with transitions when appropriate.

And remember:

The fastest code is often the code you don't need to execute.

Start with clean architecture, measure real problems, and optimize only where it matters.

What's Next?

In Part 7 — React Internals: Virtual DOM, Fiber & Reconciliation, we'll go deeper into how React works internally.

We'll explore:

What the Virtual DOM actually is.
How reconciliation works.
What React Fiber does.
How React decides which updates to commit.
Why keys matter internally.
How React schedules rendering work.

Understanding these internals will help you become a much stronger React developer.

See you in Part 7! 🚀

React Mastery Series — Part 5: React Architecture & Best Practices

Hamed Farazi — Wed, 04 Nov 2026 09:39:10 +0000

Writing React components is relatively easy.

Building a React application that remains clean, maintainable, testable, and scalable as it grows is a different challenge.

At the beginning of a project, you might have only a few components:

src/
├── App.jsx
├── Header.jsx
├── Footer.jsx
└── main.jsx

This structure works perfectly well for a small application.

But what happens when your project grows to include:

Dozens or hundreds of components.
Authentication and authorization.
Multiple API integrations.
Complex forms.
Shared application state.
Reusable UI elements.
Different business features.
Automated tests.
Multiple developers working together.

Without a clear architecture, components become difficult to understand, files become difficult to find, and changing one feature can unexpectedly break another.

In this article, we'll explore practical React architecture principles and learn how to organize applications for long-term maintainability.

We'll cover:

Component architecture.
Project folder structures.
Separation of concerns.
Reusable components.
Composition patterns.
Custom Hooks.
Context and state management.
API service layers.
Error boundaries.
Environment variables.
Performance and maintainability.
A practical project architecture.

Let's get started.

1. What Is React Architecture?

React architecture describes how you organize the components, logic, data, and responsibilities of your application.

It answers questions such as:

Where should components live?
Where should API requests be implemented?
How should shared state be managed?
How should components communicate?
How should business logic be separated from UI?
How should the application grow without becoming difficult to maintain?

React does not force you to use one specific architecture.

Instead, it provides flexible building blocks that you can organize according to your application's needs.

The goal is not to create the most complicated folder structure.

The goal is to make your code:

Easy to understand.
Easy to change.
Easy to test.
Easy to reuse.
Easy to extend.

A good architecture should reduce complexity rather than introduce unnecessary abstractions.

2. Understanding Component Architecture

Components are the foundation of React applications.

A component should ideally have a clear responsibility.

Consider this example:

function UserDashboard() {
  return (
    <div>
      <header>
        <h1>Dashboard</h1>
      </header>

      <div>
        <h2>User Information</h2>
        <p>Alex</p>
      </div>

      <div>
        <h2>Statistics</h2>
        <p>120 Projects</p>
      </div>
    </div>
  );
}

This component works, but it combines several UI responsibilities.

As the application grows, it becomes harder to maintain.

A better approach is to split the interface into smaller components.

function Header() {
  return (
    <header>
      <h1>Dashboard</h1>
    </header>
  );
}

function UserInfo() {
  return (
    <section>
      <h2>User Information</h2>
      <p>Alex</p>
    </section>
  );
}

function Statistics() {
  return (
    <section>
      <h2>Statistics</h2>
      <p>120 Projects</p>
    </section>
  );
}

function UserDashboard() {
  return (
    <div>
      <Header />
      <UserInfo />
      <Statistics />
    </div>
  );
}

Now each component has a more focused responsibility.

Why Smaller Components Matter

Smaller components offer several benefits:

Easier debugging.
Better reusability.
Simpler testing.
Clearer code organization.
More manageable updates.

However, don't split every HTML element into its own component.

A component should represent a meaningful unit of UI or behavior.

For example, creating a component for a single static span may add unnecessary complexity.

Best practice: Split components when doing so improves clarity, reuse, or independent behavior.

3. Container and Presentation Components

A useful architectural concept is separating data-related responsibilities from visual presentation.

You may encounter two common component roles:

Container components.
Presentation components.

Presentation Components

Presentation components focus primarily on displaying data.

They receive information through props and render UI.

function UserCard({ user }) {
  return (
    <article>
      <h2>{user.name}</h2>
      <p>{user.email}</p>
    </article>
  );
}

This component doesn't need to know where the user data came from.

It simply displays the information it receives.

Container Components

Container components coordinate data and application behavior.

For example:

import { useEffect, useState } from "react";
import UserCard from "./UserCard";

function UserContainer() {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    async function fetchUser() {
      try {
        const response = await fetch("/api/user");

        if (!response.ok) {
          throw new Error("Failed to fetch user");
        }

        const data = await response.json();

        setUser(data);
      } finally {
        setLoading(false);
      }
    }

    fetchUser();
  }, []);

  if (loading) {
    return <p>Loading...</p>;
  }

  if (!user) {
    return <p>User not found.</p>;
  }

  return <UserCard user={user} />;
}

Here:

UserContainer manages data loading.
UserCard displays the user.

Is This Pattern Still Useful?

Yes, but it is not a mandatory architecture.

Modern React applications often use Custom Hooks, framework data-loading features, and data-fetching libraries to separate responsibilities.

You don't need to create a container component for every presentation component.

The important principle is separating responsibilities when it makes the code easier to maintain.

4. Organizing a React Project

One of the first architectural decisions is choosing a folder structure.

There is no universally perfect structure.

Let's explore three common approaches.

Approach 1: Organize by File Type

src/
├── components/
├── hooks/
├── services/
├── context/
├── pages/
├── utils/
└── App.jsx

This structure groups files according to their technical role.

For example:

All components live in components.
All Custom Hooks live in hooks.
API functions live in services.

It's simple and works well for small applications.

However, as the project grows, related files can become scattered across multiple folders.

Approach 2: Organize by Feature

A feature-based structure groups files according to application functionality.

src/
├── features/
│   ├── auth/
│   │   ├── components/
│   │   ├── hooks/
│   │   ├── services/
│   │   └── index.js
│   │
│   ├── users/
│   │   ├── components/
│   │   ├── hooks/
│   │   ├── services/
│   │   └── index.js
│   │
│   └── products/
│       ├── components/
│       ├── hooks/
│       ├── services/
│       └── index.js
│
├── shared/
│   ├── components/
│   ├── hooks/
│   └── utils/
│
├── app/
│   ├── App.jsx
│   └── providers.jsx
│
└── main.jsx

Now everything related to authentication lives inside the auth feature.

Everything related to products lives inside products.

This can make large applications easier to navigate.

Approach 3: Hybrid Structure

A hybrid structure combines feature-based organization with shared technical folders.

src/
├── app/
│   ├── App.jsx
│   ├── router.jsx
│   └── providers.jsx
│
├── features/
│   ├── auth/
│   │   ├── components/
│   │   ├── hooks/
│   │   ├── services/
│   │   └── types.js
│   │
│   ├── dashboard/
│   │   ├── components/
│   │   └── hooks/
│   │
│   └── products/
│       ├── components/
│       ├── hooks/
│       └── services/
│
├── shared/
│   ├── components/
│   ├── hooks/
│   ├── utils/
│   └── constants/
│
├── services/
│   └── apiClient.js
│
└── main.jsx

This is a practical starting point for many medium-sized applications.

Which Structure Should You Choose?

Project size	Suggested approach
Small application	Simple file-type structure
Medium application	Hybrid structure
Large application	Feature-based structure
Complex multi-team application	Feature-based structure with explicit module boundaries

These are guidelines, not strict rules.

Start simple and introduce more structure when the project needs it.

5. Separation of Concerns

Separation of concerns means keeping different responsibilities in appropriate places.

Consider a component that handles everything:

function Products() {
  // Fetch products
  // Validate data
  // Filter products
  // Handle user interactions
  // Manage loading state
  // Render product cards
  // Format prices
  // Handle errors

  return <div>...</div>;
}

This approach can become difficult to maintain.

Instead, separate the responsibilities.

For example:

features/products/
├── components/
│   ├── ProductList.jsx
│   └── ProductCard.jsx
│
├── hooks/
│   └── useProducts.js
│
├── services/
│   └── productService.js
│
└── utils/
    └── formatPrice.js

Each module has a specific purpose.

Example: Price Formatting

Instead of repeating price formatting logic in multiple components:

function formatPrice(price) {
  return new Intl.NumberFormat("en-US", {
    style: "currency",
    currency: "USD"
  }).format(price);
}

export default formatPrice;

Use it wherever needed:

import formatPrice from "../utils/formatPrice";

function ProductCard({ product }) {
  return (
    <article>
      <h2>{product.name}</h2>
      <p>{formatPrice(product.price)}</p>
    </article>
  );
}

Now the formatting logic exists in one place.

If the formatting rules change, you only need to update one function.

6. Reusable Components

One of React's greatest strengths is component reuse.

Instead of creating separate buttons with slightly different markup, build a reusable component.

Example: Button Component

function Button({
  children,
  variant = "primary",
  disabled = false,
  onClick
}) {
  return (
    <button
      className={`button button-${variant}`}
      disabled={disabled}
      onClick={onClick}
    >
      {children}
    </button>
  );
}

export default Button;

Usage:

function App() {
  return (
    <div>
      <Button variant="primary">
        Save
      </Button>

      <Button variant="secondary">
        Cancel
      </Button>

      <Button variant="danger">
        Delete
      </Button>
    </div>
  );
}

Why Use children?

The children prop allows a component to accept arbitrary nested content.

For example:

<Button>
  Save Changes
</Button>

Or:

<Button>
  <span>Download</span>
</Button>

This makes reusable components more flexible.

Don't Over-Abstract

Not every repeated line of JSX needs a reusable component.

A good abstraction should provide meaningful benefits.

For example, a reusable button makes sense because buttons often share:

Styling.
Accessibility behavior.
Disabled states.
Loading behavior.
Interaction patterns.

A component that only wraps one static element without adding useful behavior may not be necessary.

7. Component Composition

Composition is one of the most important React design principles.

Instead of creating one component that handles every possible configuration, create smaller components that can be combined.

Example: Card Component

function Card({ children }) {
  return (
    <div className="card">
      {children}
    </div>
  );
}

Now create a specialized card:

function UserProfile() {
  return (
    <Card>
      <h2>Alex Morgan</h2>
      <p>Frontend Developer</p>
      <button>View Profile</button>
    </Card>
  );
}

Another component can reuse the same card:

function ProductCard() {
  return (
    <Card>
      <h2>Mechanical Keyboard</h2>
      <p>$99</p>
      <button>Buy Now</button>
    </Card>
  );
}

The Card component doesn't need to know whether it contains a user profile or a product.

It simply provides a layout container.

Named Slots Through Props

You can also create components that accept multiple content regions.

function PageLayout({
  header,
  sidebar,
  children,
  footer
}) {
  return (
    <div className="page-layout">
      <header>{header}</header>

      <div className="page-content">
        <aside>{sidebar}</aside>

        <main>{children}</main>
      </div>

      <footer>{footer}</footer>
    </div>
  );
}

Usage:

function Dashboard() {
  return (
    <PageLayout
      header={<h1>Dashboard</h1>}
      sidebar={<nav>Navigation</nav>}
      footer={<p>Copyright 2026</p>}
    >
      <h2>Welcome!</h2>
      <p>Your dashboard content goes here.</p>
    </PageLayout>
  );
}

This is a flexible alternative to building one enormous component with many conditional branches.

8. Custom Hooks for Reusable Logic

Custom Hooks allow you to extract stateful behavior from components.

Suppose multiple components need to track whether a user is online.

Instead of repeating the same Effect, create a reusable Hook.

import { useEffect, useState } from "react";

function useOnlineStatus() {
  const [isOnline, setIsOnline] = useState(
    navigator.onLine
  );

  useEffect(() => {
    function handleOnline() {
      setIsOnline(true);
    }

    function handleOffline() {
      setIsOnline(false);
    }

    window.addEventListener("online", handleOnline);
    window.addEventListener("offline", handleOffline);

    return () => {
      window.removeEventListener("online", handleOnline);
      window.removeEventListener("offline", handleOffline);
    };
  }, []);

  return isOnline;
}

export default useOnlineStatus;

Now use it in different components:

function NetworkIndicator() {
  const isOnline = useOnlineStatus();

  return (
    <p>
      Status: {isOnline ? "Online" : "Offline"}
    </p>
  );
}

Another component can use the same Hook:

function SaveButton() {
  const isOnline = useOnlineStatus();

  return (
    <button disabled={!isOnline}>
      Save Changes
    </button>
  );
}

Each component gets its own Hook state, while the logic is reused.

When Should You Create a Custom Hook?

Consider creating one when:

Multiple components share stateful behavior.
A component contains a complicated Effect.
You want to separate behavior from presentation.
You need a reusable browser integration.
You want to make component logic easier to test.

Avoid creating a Custom Hook simply to move a few unrelated lines into another file.

9. Managing Shared State

As an application grows, multiple components may need access to the same state.

For example:

Current authenticated user.
Shopping cart.
Selected language.
Theme preferences.
Application notifications.

There are several ways to manage shared state.

Option 1: Lift State Up

If two components need the same state, move it to their closest common parent.

import { useState } from "react";

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

  return (
    <div>
      <CounterDisplay count={count} />

      <CounterControls
        count={count}
        setCount={setCount}
      />
    </div>
  );
}

function CounterDisplay({ count }) {
  return <h2>Count: {count}</h2>;
}

function CounterControls({ count, setCount }) {
  return (
    <button onClick={() => setCount(count + 1)}>
      Increase
    </button>
  );
}

This works well when components are relatively close in the tree.

Option 2: Context API

Context allows you to share values with deeply nested components.

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

const ThemeContext = createContext(null);

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

  const value = {
    theme,
    toggleTheme() {
      setTheme(current =>
        current === "light" ? "dark" : "light"
      );
    }
  };

  return (
    <ThemeContext.Provider value={value}>
      {children}
    </ThemeContext.Provider>
  );
}

function useTheme() {
  const context = useContext(ThemeContext);

  if (context === null) {
    throw new Error(
      "useTheme must be used within ThemeProvider"
    );
  }

  return context;
}

Usage:

function ThemeButton() {
  const { theme, toggleTheme } = useTheme();

  return (
    <button onClick={toggleTheme}>
      Current theme: {theme}
    </button>
  );
}

Option 3: Dedicated State Management

For larger applications, you may need a more specialized state-management solution.

Common options include:

Redux Toolkit.
Zustand.
Jotai.
MobX.

Each has a different approach.

For example, Zustand provides a relatively simple store API.

Install it:

npm install zustand

Create a store:

import { create } from "zustand";

const useCounterStore = create(set => ({
  count: 0,

  increment: () =>
    set(state => ({
      count: state.count + 1
    })),

  reset: () =>
    set({ count: 0 })
}));

export default useCounterStore;

Use it in a component:

import useCounterStore from "./counterStore";

function Counter() {
  const count = useCounterStore(state => state.count);
  const increment = useCounterStore(
    state => state.increment
  );

  return (
    <button onClick={increment}>
      Count: {count}
    </button>
  );
}

Which State Management Approach Should You Choose?

Situation	Recommended approach
State used by one component	useState
Complex local state transitions	useReducer
Shared state in a nearby component tree	Lift state up
Shared values across a component tree	Context
Complex global client state	Consider a state library
Remote API data and caching	Consider TanStack Query

A useful distinction:

Client state represents information managed by your application, such as an open modal or selected tab.

Server state represents information that originates from an external server, such as users, products, or orders.

These types of state often benefit from different tools.

10. Separating API Logic into Service Layers

A common mistake is placing all HTTP requests directly inside UI components.

For example:

function Products() {
  // Component state

  // Fetch request

  // Request headers

  // Error handling

  // Data transformation

  // Rendering

  return <div>...</div>;
}

This mixes several responsibilities.

A service layer provides a cleaner alternative.

Suggested Structure

features/
└── products/
    ├── components/
    │   ├── ProductList.jsx
    │   └── ProductCard.jsx
    │
    ├── hooks/
    │   └── useProducts.js
    │
    └── services/
        └── productService.js

Create a Service

productService.js

const API_URL = "/api/products";

export async function getProducts(signal) {
  const response = await fetch(API_URL, { signal });

  if (!response.ok) {
    throw new Error("Failed to fetch products");
  }

  return response.json();
}

export async function getProductById(id, signal) {
  const response = await fetch(
    `${API_URL}/${id}`,
    { signal }
  );

  if (!response.ok) {
    throw new Error("Product not found");
  }

  return response.json();
}

export async function createProduct(product) {
  const response = await fetch(API_URL, {
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify(product)
  });

  if (!response.ok) {
    throw new Error("Failed to create product");
  }

  return response.json();
}

Use the Service in a Custom Hook

useProducts.js

import { useEffect, useState } from "react";
import { getProducts } from "../services/productService";

export function useProducts() {
  const [products, setProducts] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState("");

  useEffect(() => {
    const controller = new AbortController();

    async function loadProducts() {
      try {
        setLoading(true);
        setError("");

        const data = await getProducts(controller.signal);

        setProducts(data);
      } catch (error) {
        if (error.name !== "AbortError") {
          setError(error.message);
        }
      } finally {
        if (!controller.signal.aborted) {
          setLoading(false);
        }
      }
    }

    loadProducts();

    return () => controller.abort();
  }, []);

  return {
    products,
    loading,
    error
  };
}

Use It in a Component

ProductList.jsx

import { useProducts } from "../hooks/useProducts";
import ProductCard from "./ProductCard";

function ProductList() {
  const {
    products,
    loading,
    error
  } = useProducts();

  if (loading) {
    return <p>Loading products...</p>;
  }

  if (error) {
    return <p>{error}</p>;
  }

  return (
    <div>
      {products.map(product => (
        <ProductCard
          key={product.id}
          product={product}
        />
      ))}
    </div>
  );
}

export default ProductList;

The component is now focused primarily on rendering.

The API request lives in a service, and reusable asynchronous behavior lives in a Custom Hook.

11. Error Boundaries

React applications need a strategy for handling unexpected rendering errors.

An Error Boundary is a component that catches errors thrown while rendering its descendant component tree and displays fallback UI.

This helps prevent an error in one part of the interface from breaking the entire application.

Creating an Error Boundary

Error Boundaries are traditionally implemented using class components.

import React from "react";

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);

    this.state = {
      hasError: false
    };
  }

  static getDerivedStateFromError() {
    return {
      hasError: true
    };
  }

  componentDidCatch(error, info) {
    console.error("Application error:", error);
    console.error("Component stack:", info.componentStack);
  }

  render() {
    if (this.state.hasError) {
      return (
        <div>
          <h2>Something went wrong.</h2>
          <p>Please try again later.</p>
        </div>
      );
    }

    return this.props.children;
  }
}

export default ErrorBoundary;

Using the Error Boundary

import ErrorBoundary from "./ErrorBoundary";
import Dashboard from "./Dashboard";

function App() {
  return (
    <ErrorBoundary>
      <Dashboard />
    </ErrorBoundary>
  );
}

You can also place Error Boundaries around individual application sections.

function App() {
  return (
    <div>
      <Header />

      <ErrorBoundary>
        <Dashboard />
      </ErrorBoundary>

      <Footer />
    </div>
  );
}

If the dashboard throws a rendering error, the rest of the application can remain available.

Important Limitations

Error Boundaries do not automatically catch every kind of error.

They generally do not catch:

Errors in event handlers.
Errors in asynchronous callbacks.
Errors in server-side rendering.
Errors thrown by the Error Boundary itself.

For API failures, continue using normal try / catch handling and appropriate loading and error states.

12. Environment Variables

Applications often need configuration values such as:

API base URLs.
Feature flags.
Public service identifiers.
Environment-specific settings.

You shouldn't hardcode configuration throughout your application.

Instead, use environment variables.

Example with Vite

Create a .env file:

VITE_API_URL=https://api.example.com

Access the value:

const API_URL = import.meta.env.VITE_API_URL;

export default API_URL;

Use it in your service:

const API_URL = import.meta.env.VITE_API_URL;

export async function getProducts() {
  const response = await fetch(`${API_URL}/products`);

  if (!response.ok) {
    throw new Error("Failed to fetch products");
  }

  return response.json();
}

Different Environments

You can create different configuration files:

.env
.env.development
.env.production

For example:

.env.development

VITE_API_URL=http://localhost:3000

.env.production

VITE_API_URL=https://api.example.com

Vite loads environment-specific files according to its current mode.

Important Security Rule

Environment variables exposed through frontend build tools are not secret.

For example, Vite exposes variables prefixed with VITE_ to browser code.

That means users can inspect them.

Never put these values in frontend environment variables:

Database passwords.
Private API keys.
Secret tokens.
Backend credentials.
Private signing keys.

Keep sensitive credentials on the server.

13. Avoiding Prop Drilling

Prop drilling happens when data is passed through several intermediate components that don't actually need it.

Imagine this structure:

App
└── Dashboard
    └── Layout
        └── Sidebar
            └── UserProfile

Suppose App owns the current user, but only UserProfile needs it.

Without Context, you might pass the user through every intermediate component.

function App() {
  const user = {
    name: "Alex"
  };

  return <Dashboard user={user} />;
}

function Dashboard({ user }) {
  return <Layout user={user} />;
}

function Layout({ user }) {
  return <Sidebar user={user} />;
}

function Sidebar({ user }) {
  return <UserProfile user={user} />;
}

function UserProfile({ user }) {
  return <h2>{user.name}</h2>;
}

This can become inconvenient when the component tree is deep.

Context offers another approach:

import {
  createContext,
  useContext
} from "react";

const UserContext = createContext(null);

function UserProfile() {
  const user = useContext(UserContext);

  return <h2>{user.name}</h2>;
}

function App() {
  const user = {
    name: "Alex"
  };

  return (
    <UserContext.Provider value={user}>
      <Dashboard />
    </UserContext.Provider>
  );
}

Now UserProfile can access the value directly.

However, prop drilling is not always bad.

Passing props explicitly can make dependencies easier to understand.

Use Context when it genuinely simplifies the component tree.

14. Avoiding Unnecessary Re-renders

React components can render again when their state, props, or consumed context values change.

Sometimes this is necessary.

Sometimes you can reduce unnecessary work.

React provides several tools for optimization.

React.memo

memo can skip rendering a component when its props remain unchanged.

import { memo } from "react";

const UserCard = memo(function UserCard({ user }) {
  console.log("UserCard rendered");

  return (
    <div>
      <h2>{user.name}</h2>
      <p>{user.email}</p>
    </div>
  );
});

export default UserCard;

useMemo

Use useMemo to cache an expensive calculation when appropriate.

const filteredProducts = useMemo(() => {
  return products.filter(product =>
    product.name.includes(search)
  );
}, [products, search]);

useCallback

Use useCallback when stable function identity is useful.

const handleClick = useCallback(() => {
  console.log("Clicked");
}, []);

Important: Don't Optimize Prematurely

Not every component needs memo.

Not every function needs useCallback.

Not every calculation needs useMemo.

Start with clear and correct code.

Use React DevTools Profiler and actual performance measurements to identify bottlenecks.

In projects using React Compiler, some manual memoization may be unnecessary depending on the compiler configuration.

15. A Practical Architecture: Building a Product Management Application

Now let's combine the ideas into a realistic project structure.

Imagine we're building a product management application.

It needs:

Product listing.
Product details.
Product creation.
Authentication.
Shared navigation.
API integration.
Reusable UI components.

A possible structure:

src/
│
├── app/
│   ├── App.jsx
│   ├── router.jsx
│   └── providers.jsx
│
├── features/
│   │
│   ├── auth/
│   │   ├── components/
│   │   │   └── LoginForm.jsx
│   │   ├── hooks/
│   │   │   └── useAuth.js
│   │   └── services/
│   │       └── authService.js
│   │
│   └── products/
│       ├── components/
│       │   ├── ProductList.jsx
│       │   ├── ProductCard.jsx
│       │   └── ProductForm.jsx
│       │
│       ├── hooks/
│       │   └── useProducts.js
│       │
│       ├── services/
│       │   └── productService.js
│       │
│       └── utils/
│           └── formatPrice.js
│
├── shared/
│   ├── components/
│   │   ├── Button.jsx
│   │   ├── Input.jsx
│   │   ├── Modal.jsx
│   │   └── Spinner.jsx
│   │
│   ├── hooks/
│   │   └── useOnlineStatus.js
│   │
│   └── utils/
│       └── formatDate.js
│
├── services/
│   └── apiClient.js
│
├── styles/
│   └── global.css
│
└── main.jsx

This structure separates the application into meaningful areas.

Understanding the Main Folders

app/

Contains application-level configuration, routing, and providers.

features/

Contains functionality organized around business features.

shared/

Contains reusable components, Hooks, and utilities that are not specific to one feature.

services/

Contains shared infrastructure for communicating with external systems.

styles/

Contains global styling and shared design rules.

Example: Shared API Client

services/apiClient.js

const API_URL = import.meta.env.VITE_API_URL;

export async function apiRequest(path, options = {}) {
  const response = await fetch(`${API_URL}${path}`, {
    ...options,
    headers: {
      ...(options.headers || {})
    }
  });

  if (!response.ok) {
    throw new Error(
      `Request failed with status ${response.status}`
    );
  }

  if (response.status === 204) {
    return null;
  }

  return response.json();
}

Now feature services can reuse it.

features/products/services/productService.js

import { apiRequest } from "../../../services/apiClient";

export function getProducts(signal) {
  return apiRequest("/products", { signal });
}

export function createProduct(product) {
  return apiRequest("/products", {
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify(product)
  });
}

This is a simple example. A production API client may also need authentication handling, request timeouts, structured error parsing, and retry policies.

16. Testing and Architecture

Good architecture makes testing easier.

When responsibilities are separated, you can test each part independently.

For example:

Utility functions can be tested without rendering React.
Components can be tested with React Testing Library.
API services can be tested with mocked network requests.
Custom Hooks can be tested through a component or a Hook testing utility.
Important user workflows can be tested end to end.

Consider a utility function:

export function calculateTotal(price, quantity) {
  return price * quantity;
}

It can be tested independently:

import { calculateTotal } from "./calculateTotal";

test("calculates the total price", () => {
  expect(calculateTotal(10, 3)).toBe(30);
});

The less tightly coupled your code is, the easier it usually becomes to test.

We'll explore testing in detail in Part 10 of this series.

17. Common React Architecture Mistakes

Let's review some mistakes that can make applications difficult to maintain.

Mistake 1: One Giant Component

A component that handles routing, API requests, validation, business logic, and rendering becomes difficult to understand.

Better approach: Split responsibilities into smaller components, Hooks, and services when appropriate.

Mistake 2: Over-Engineering

Creating dozens of folders and abstractions for a tiny application adds unnecessary complexity.

Better approach: Start simple and introduce abstractions when they solve a real problem.

Mistake 3: Duplicating Logic

Copying the same formatting, validation, or data-processing logic into multiple components creates maintenance problems.

Better approach: Extract genuinely reusable logic into utilities, components, or Custom Hooks.

Mistake 4: Putting Everything in Context

Context is useful, but using one enormous Context for every application value can cause unnecessary complexity and broad updates.

Better approach: Keep state close to where it is needed and separate unrelated contexts when appropriate.

Mistake 5: Mixing API Requests with UI Logic

Large components filled with request configuration and response handling are difficult to maintain.

Better approach: Consider service modules and Custom Hooks.

Mistake 6: Creating Too Many Generic Components

A highly configurable component with dozens of props can become harder to use than several simpler components.

Better approach: Prefer clear, focused APIs.

Mistake 7: Ignoring Error Handling

A production application needs strategies for network failures, invalid responses, and unexpected rendering errors.

Better approach: Handle errors at the appropriate layer.

Mistake 8: Sharing Everything Globally

Not every piece of state belongs in a global store.

Better approach: Keep local state local whenever possible.

Mistake 9: Treating Folder Structure as Architecture

Having folders named components, hooks, and services doesn't automatically make an application well-architected.

Architecture is about boundaries, responsibilities, dependencies, and communication between parts of the application.

18. A Practical Checklist for Clean React Architecture

Before considering a React feature complete, ask yourself:

Component design

Does each component have a clear responsibility?
Are reusable components genuinely reusable?
Is component composition used where appropriate?

State management

Is state stored close to where it is needed?
Is shared state actually shared only when necessary?
Is server state handled appropriately?

Code organization

Are feature-related files grouped logically?
Is API logic separated from UI?
Are utilities reusable and independent?

Reliability

Are loading and error states handled?
Are important rendering errors covered by Error Boundaries?
Are asynchronous operations cleaned up where appropriate?

Security

Are secrets kept out of frontend code?
Is server-side validation implemented?
Are permissions enforced on the backend?

Maintainability

Can another developer understand the structure?
Are important behaviors testable?
Are abstractions reducing complexity rather than increasing it?

19. Final Thoughts

Building a React application is not just about writing components.

It's about designing a system where components, state, services, and application features work together in a predictable way.

The most important principles from this article are:

Keep components focused.
Organize code around meaningful responsibilities.
Use composition to build flexible interfaces.
Extract reusable behavior into Custom Hooks.
Keep API logic separate from presentation.
Choose state-management tools based on actual requirements.
Handle errors and loading states intentionally.
Avoid unnecessary abstractions.
Optimize only when there is a measurable reason.
Design for maintainability, not just immediate functionality.

Remember:

Good architecture is not about writing more code or creating more folders. It's about making change easier.

Start with a simple structure, understand your application's needs, and evolve the architecture as the project grows.

What's Next?

In Part 6 of the React Mastery Series, we'll explore:

React Performance Optimization — Making Applications Faster and More Responsive

We'll cover:

Understanding React rendering.
Why components re-render.
React.memo.
useMemo and useCallback.
Lazy loading.
Code splitting.
Suspense.
List virtualization.
Avoiding unnecessary Effects.
React DevTools Profiler.
Practical performance optimization techniques.

We'll learn how to identify real performance problems and fix them without making our code unnecessarily complicated.

Happy coding! 🚀

React Mastery Series — Part 4: React Forms & API Integration

Hamed Farazi — Wed, 04 Nov 2026 07:57:07 +0000

Forms are everywhere in modern web applications.

Whether you're building a login page, registration system, checkout process, search interface, or admin dashboard, you'll need to collect information from users and process it correctly.

In React, forms introduce several important concepts:

Controlled and uncontrolled components.
Managing input state.
Handling form submissions.
Validating user input.
Displaying validation errors.
Working with asynchronous operations.
Fetching data from APIs.
Handling loading and error states.
Updating application data.

In this article, we'll explore these concepts step by step and build practical examples that demonstrate how real React applications handle forms and communicate with APIs.

1. Understanding Forms in React

In traditional HTML, a form manages its own input values through the DOM.

For example:

<form>
  <input type="text" name="username" />

  <button type="submit">
    Submit
  </button>
</form>

React provides a more flexible approach by allowing components to control input values through state.

This leads to two common approaches:

Controlled components.
Uncontrolled components.

Let's understand the difference.

2. Controlled Components

A controlled component is an input element whose value is controlled by React state.

Whenever the user changes the input, an event handler updates the state.

Basic Example

import { useState } from "react";

function UsernameForm() {
  const [username, setUsername] = useState("");

  return (
    <div>
      <input
        type="text"
        value={username}
        onChange={event => setUsername(event.target.value)}
        placeholder="Enter your username"
      />

      <p>Username: {username}</p>
    </div>
  );
}

export default UsernameForm;

Let's break it down.

Step 1: Create state

const [username, setUsername] = useState("");

The input starts with an empty string.

Step 2: Connect state to the input

value={username}

React controls the displayed value.

Step 3: Update state when the user types

onChange={event => setUsername(event.target.value)}

Every change updates the React state.

Why Use Controlled Components?

Controlled components provide several advantages:

You always know the current input value.
You can validate input while the user types.
You can conditionally disable buttons.
You can dynamically change input values.
You can easily reset forms.
You can display real-time feedback.

They are especially useful for forms with validation and conditional behavior.

3. Handling Multiple Inputs

Real applications usually contain multiple input fields.

Instead of creating separate state variables for every input, you can store form data in an object.

import { useState } from "react";

function RegistrationForm() {
  const [formData, setFormData] = useState({
    username: "",
    email: "",
    password: ""
  });

  function handleChange(event) {
    const { name, value } = event.target;

    setFormData(previousData => ({
      ...previousData,
      [name]: value
    }));
  }

  return (
    <form>
      <input
        name="username"
        value={formData.username}
        onChange={handleChange}
        placeholder="Username"
      />

      <input
        name="email"
        type="email"
        value={formData.email}
        onChange={handleChange}
        placeholder="Email"
      />

      <input
        name="password"
        type="password"
        value={formData.password}
        onChange={handleChange}
        placeholder="Password"
      />

      <pre>{JSON.stringify(formData, null, 2)}</pre>
    </form>
  );
}

Understanding the Dynamic Property

This expression is especially important:

[name]: value

It uses JavaScript's computed property syntax.

For example, if:

name = "email";
value = "alex@example.com";

Then:

{
  ...previousData,
  [name]: value
}

becomes:

{
  username: "Alex",
  email: "alex@example.com",
  password: ""
}

This pattern makes handling multiple inputs much easier.

4. Handling Form Submission

A form needs a submit handler.

In React, you can listen to the form's onSubmit event.

import { useState } from "react";

function LoginForm() {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");

  function handleSubmit(event) {
    event.preventDefault();

    console.log({
      email,
      password
    });
  }

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="email"
        value={email}
        onChange={event => setEmail(event.target.value)}
        placeholder="Email"
        required
      />

      <input
        type="password"
        value={password}
        onChange={event => setPassword(event.target.value)}
        placeholder="Password"
        required
      />

      <button type="submit">
        Login
      </button>
    </form>
  );
}

Why Use preventDefault()?

HTML forms normally perform a browser navigation or submission action.

In a typical React single-page application, you usually want to handle the submission using JavaScript.

That's why we use:

event.preventDefault();

It prevents the browser's default form submission behavior.

Why Use type="submit"?

A button inside a form can submit the form when its type is submit.

You can also use:

<button type="button">
  Cancel
</button>

This button won't submit the form.

Being explicit about button types prevents unexpected form submissions.

5. Working with Different Input Types

React supports the standard HTML form controls.

Let's explore some common examples.

Text Input

<input
  type="text"
  value={name}
  onChange={event => setName(event.target.value)}
/>

Email Input

<input
  type="email"
  value={email}
  onChange={event => setEmail(event.target.value)}
/>

Password Input

<input
  type="password"
  value={password}
  onChange={event => setPassword(event.target.value)}
/>

Checkbox

Checkboxes use the checked property rather than value to control whether they are selected.

import { useState } from "react";

function TermsCheckbox() {
  const [accepted, setAccepted] = useState(false);

  return (
    <label>
      <input
        type="checkbox"
        checked={accepted}
        onChange={event => setAccepted(event.target.checked)}
      />

      I accept the terms and conditions.
    </label>
  );
}

Notice:

event.target.checked

This returns a boolean.

Radio Buttons

import { useState } from "react";

function GenderForm() {
  const [gender, setGender] = useState("");

  return (
    <div>
      <label>
        <input
          type="radio"
          name="gender"
          value="male"
          checked={gender === "male"}
          onChange={event => setGender(event.target.value)}
        />
        Male
      </label>

      <label>
        <input
          type="radio"
          name="gender"
          value="female"
          checked={gender === "female"}
          onChange={event => setGender(event.target.value)}
        />
        Female
      </label>

      <p>Selected: {gender}</p>
    </div>
  );
}

Select Dropdown

import { useState } from "react";

function CountrySelect() {
  const [country, setCountry] = useState("");

  return (
    <div>
      <select
        value={country}
        onChange={event => setCountry(event.target.value)}
      >
        <option value="">Select a country</option>
        <option value="germany">Germany</option>
        <option value="france">France</option>
        <option value="canada">Canada</option>
      </select>

      <p>Selected country: {country}</p>
    </div>
  );
}

Textarea

<textarea
  value={message}
  onChange={event => setMessage(event.target.value)}
  placeholder="Write your message..."
/>

In React, use the value prop to control a textarea rather than placing its initial content between the opening and closing tags.

6. Uncontrolled Components

Unlike controlled components, uncontrolled components store their current values in the DOM.

React accesses those values when needed, commonly through refs.

Example

import { useRef } from "react";

function UncontrolledForm() {
  const usernameRef = useRef(null);

  function handleSubmit(event) {
    event.preventDefault();

    console.log(usernameRef.current.value);
  }

  return (
    <form onSubmit={handleSubmit}>
      <input
        ref={usernameRef}
        type="text"
        defaultValue="Alex"
      />

      <button type="submit">
        Submit
      </button>
    </form>
  );
}

Here:

defaultValue="Alex"

sets the initial value.

The DOM manages subsequent changes.

Controlled vs Uncontrolled Components

Feature	Controlled	Uncontrolled
Value managed by	React state	DOM
Main API	value	defaultValue
Change handling	onChange	Optional
Access current value	State	Ref
Real-time validation	Easy	Requires additional handling
Dynamic behavior	Flexible	Less direct

When Should You Use Each?

Use controlled components when:

You need real-time validation.
Input values affect other UI elements.
You need conditional form behavior.
You want predictable React state.

Use uncontrolled components when:

You only need the values at submission time.
You're integrating with traditional HTML forms.
You're working with file inputs.
You want a simpler form with minimal React state.

7. Form Validation

Validation ensures that users submit acceptable information.

For example:

Email must be valid.
Password must meet minimum requirements.
Username cannot be empty.
Required fields must be completed.
Password confirmation must match.

Let's build a simple validation system.

Basic Validation Example

function validateForm(values) {
  const errors = {};

  if (!values.username.trim()) {
    errors.username = "Username is required";
  }

  if (!values.email.trim()) {
    errors.email = "Email is required";
  } else if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(values.email)) {
    errors.email = "Please enter a valid email";
  }

  if (values.password.length < 8) {
    errors.password = "Password must contain at least 8 characters";
  }

  return errors;
}

The function receives form values and returns an object containing validation errors.

If there are no errors, the returned object is empty.

Using Validation in a React Component

import { useState } from "react";

function RegistrationForm() {
  const [values, setValues] = useState({
    username: "",
    email: "",
    password: ""
  });

  const [errors, setErrors] = useState({});

  function handleChange(event) {
    const { name, value } = event.target;

    setValues(previous => ({
      ...previous,
      [name]: value
    }));
  }

  function handleSubmit(event) {
    event.preventDefault();

    const validationErrors = validateForm(values);

    setErrors(validationErrors);

    if (Object.keys(validationErrors).length === 0) {
      console.log("Form submitted:", values);
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <input
          name="username"
          value={values.username}
          onChange={handleChange}
          placeholder="Username"
        />

        {errors.username && (
          <p>{errors.username}</p>
        )}
      </div>

      <div>
        <input
          name="email"
          type="email"
          value={values.email}
          onChange={handleChange}
          placeholder="Email"
        />

        {errors.email && (
          <p>{errors.email}</p>
        )}
      </div>

      <div>
        <input
          name="password"
          type="password"
          value={values.password}
          onChange={handleChange}
          placeholder="Password"
        />

        {errors.password && (
          <p>{errors.password}</p>
        )}
      </div>

      <button type="submit">
        Register
      </button>
    </form>
  );
}

This is a simple validation approach. In larger applications, you may want to validate fields as users interact with them and show errors only after a field has been touched or the form has been submitted.

Client-Side vs Server-Side Validation

Client-side validation improves the user experience.

However, it is not a security boundary.

Users can bypass browser validation and send requests directly to your server.

Always validate important data on the backend as well.

Never trust client-submitted information simply because it passed frontend validation.

8. Handling Asynchronous Form Submission

Many forms communicate with a backend.

For example:

Login requests.
Registration requests.
Contact forms.
Payment forms.
Profile updates.

These operations are asynchronous.

You need to handle at least three states:

Loading.
Success.
Error.

Example: Login Form

import { useState } from "react";

function LoginForm() {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");

  const [loading, setLoading] = useState(false);
  const [error, setError] = useState("");
  const [success, setSuccess] = useState("");

  async function handleSubmit(event) {
    event.preventDefault();

    setLoading(true);
    setError("");
    setSuccess("");

    try {
      const response = await fetch("/api/login", {
        method: "POST",
        headers: {
          "Content-Type": "application/json"
        },
        body: JSON.stringify({
          email,
          password
        })
      });

      if (!response.ok) {
        throw new Error("Login failed");
      }

      const data = await response.json();

      setSuccess("Login successful!");
      console.log(data);
    } catch (error) {
      setError(error.message);
    } finally {
      setLoading(false);
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="email"
        value={email}
        onChange={event => setEmail(event.target.value)}
        placeholder="Email"
        required
      />

      <input
        type="password"
        value={password}
        onChange={event => setPassword(event.target.value)}
        placeholder="Password"
        required
      />

      <button type="submit" disabled={loading}>
        {loading ? "Logging in..." : "Login"}
      </button>

      {error && <p>{error}</p>}
      {success && <p>{success}</p>}
    </form>
  );
}

Understanding the Fetch Request

Let's examine the important parts.

const response = await fetch("/api/login", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    email,
    password
  })
});

method

Specifies the HTTP method.

Common methods include:

GET
POST
PUT
PATCH
DELETE

headers

Provides metadata about the request.

Here, we're telling the server that the request body contains JSON.

body

Contains the information sent to the server.

JSON.stringify() converts a JavaScript object into a JSON string.

Why Check response.ok?

The fetch() function does not automatically reject its Promise when the server returns an HTTP error such as 404 or 500.

That's why we check:

if (!response.ok) {
  throw new Error("Login failed");
}

This allows our catch block to handle unsuccessful HTTP responses.

9. Understanding the Fetch API

The Fetch API is a built-in browser API for making HTTP requests.

Let's look at common operations.

GET — Fetch Data

async function getUsers() {
  const response = await fetch("/api/users");

  if (!response.ok) {
    throw new Error("Could not fetch users");
  }

  return response.json();
}

POST — Create Data

async function createUser(user) {
  const response = await fetch("/api/users", {
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify(user)
  });

  if (!response.ok) {
    throw new Error("Could not create user");
  }

  return response.json();
}

PUT — Replace Data

async function updateUser(id, user) {
  const response = await fetch(`/api/users/${id}`, {
    method: "PUT",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify(user)
  });

  if (!response.ok) {
    throw new Error("Could not update user");
  }

  return response.json();
}

PATCH — Partially Update Data

async function updateUserEmail(id, email) {
  const response = await fetch(`/api/users/${id}`, {
    method: "PATCH",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify({ email })
  });

  if (!response.ok) {
    throw new Error("Could not update email");
  }

  return response.json();
}

DELETE — Remove Data

async function deleteUser(id) {
  const response = await fetch(`/api/users/${id}`, {
    method: "DELETE"
  });

  if (!response.ok) {
    throw new Error("Could not delete user");
  }
}

These examples assume the backend supports the corresponding endpoints and request formats.

10. Fetching Data Inside useEffect

A common React pattern is fetching data when a component needs to display it.

Let's build a users list.

import { useEffect, useState } from "react";

function UsersList() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState("");

  useEffect(() => {
    const controller = new AbortController();

    async function fetchUsers() {
      try {
        setLoading(true);
        setError("");

        const response = await fetch(
          "https://jsonplaceholder.typicode.com/users",
          {
            signal: controller.signal
          }
        );

        if (!response.ok) {
          throw new Error("Failed to load users");
        }

        const data = await response.json();

        setUsers(data);
      } catch (error) {
        if (error.name !== "AbortError") {
          setError(error.message);
        }
      } finally {
        if (!controller.signal.aborted) {
          setLoading(false);
        }
      }
    }

    fetchUsers();

    return () => {
      controller.abort();
    };
  }, []);

  if (loading) {
    return <p>Loading...</p>;
  }

  if (error) {
    return <p>Error: {error}</p>;
  }

  return (
    <div>
      <h2>Users</h2>

      {users.map(user => (
        <div key={user.id}>
          <h3>{user.name}</h3>
          <p>{user.email}</p>
        </div>
      ))}
    </div>
  );
}

export default UsersList;

Why Use AbortController?

Suppose a user navigates away from the page while a request is still running.

The request may no longer be useful.

AbortController allows us to cancel the request when the Effect is cleaned up.

This is especially useful when working with requests that depend on changing component inputs.

What Happens When Data Changes?

Imagine fetching a user's profile based on a userId prop.

useEffect(() => {
  // Fetch data for the current userId
}, [userId]);

When userId changes:

React runs the previous Effect's cleanup.
The previous request can be cancelled.
React runs the new Effect.
A request for the new user can begin.

This helps prevent outdated requests from interfering with the current UI.

11. Building a Search Interface with an API

Search functionality is common in real-world applications.

Let's build a search component that requests data from an API.

import { useEffect, useState } from "react";

function SearchUsers() {
  const [query, setQuery] = useState("");
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState("");

  useEffect(() => {
    if (!query.trim()) {
      setUsers([]);
      setLoading(false);
      setError("");
      return;
    }

    const controller = new AbortController();

    const timeoutId = setTimeout(async () => {
      try {
        setLoading(true);
        setError("");

        const response = await fetch(
          `/api/users?search=${encodeURIComponent(query)}`,
          {
            signal: controller.signal
          }
        );

        if (!response.ok) {
          throw new Error("Search failed");
        }

        const data = await response.json();

        setUsers(data);
      } catch (error) {
        if (error.name !== "AbortError") {
          setError(error.message);
        }
      } finally {
        if (!controller.signal.aborted) {
          setLoading(false);
        }
      }
    }, 400);

    return () => {
      clearTimeout(timeoutId);
      controller.abort();
    };
  }, [query]);

  return (
    <div>
      <input
        value={query}
        onChange={event => setQuery(event.target.value)}
        placeholder="Search users..."
      />

      {loading && <p>Searching...</p>}

      {error && <p>{error}</p>}

      <ul>
        {users.map(user => (
          <li key={user.id}>{user.name}</li>
        ))}
      </ul>
    </div>
  );
}

Understanding Debouncing

Notice this part:

setTimeout(async () => {
  // API request
}, 400);

The request waits for 400 milliseconds after the user stops typing.

This technique is called debouncing.

Without debouncing, typing a search query such as:

react

could trigger multiple requests:

r
re
rea
reac
react

Debouncing reduces unnecessary requests.

The cleanup function cancels the previous timer and request when the query changes.

12. Updating Data After an API Request

Fetching data is only part of API integration.

Applications also need to create, update, and delete records.

Let's build a small example that adds a new user.

import { useState } from "react";

function CreateUser() {
  const [name, setName] = useState("");
  const [loading, setLoading] = useState(false);
  const [message, setMessage] = useState("");

  async function handleSubmit(event) {
    event.preventDefault();

    setLoading(true);
    setMessage("");

    try {
      const response = await fetch("/api/users", {
        method: "POST",
        headers: {
          "Content-Type": "application/json"
        },
        body: JSON.stringify({ name })
      });

      if (!response.ok) {
        throw new Error("Could not create user");
      }

      const newUser = await response.json();

      setMessage(`Created user: ${newUser.name}`);
      setName("");
    } catch (error) {
      setMessage(error.message);
    } finally {
      setLoading(false);
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <input
        value={name}
        onChange={event => setName(event.target.value)}
        placeholder="User name"
        required
      />

      <button disabled={loading}>
        {loading ? "Creating..." : "Create User"}
      </button>

      {message && <p>{message}</p>}
    </form>
  );
}

In a real application, you would also update the displayed users list after successfully creating the record.

This can be done by:

Updating local React state.
Refreshing the data.
Invalidating a query cache.
Updating a shared state store.

13. Handling File Uploads

File uploads are another common form requirement.

React can access selected files through the input element.

import { useState } from "react";

function FileUpload() {
  const [file, setFile] = useState(null);
  const [message, setMessage] = useState("");

  function handleFileChange(event) {
    setFile(event.target.files[0] ?? null);
  }

  async function handleSubmit(event) {
    event.preventDefault();

    if (!file) {
      setMessage("Please select a file.");
      return;
    }

    const formData = new FormData();

    formData.append("file", file);

    try {
      const response = await fetch("/api/upload", {
        method: "POST",
        body: formData
      });

      if (!response.ok) {
        throw new Error("Upload failed");
      }

      setMessage("File uploaded successfully!");
    } catch (error) {
      setMessage(error.message);
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="file"
        onChange={handleFileChange}
      />

      <button type="submit">
        Upload
      </button>

      {message && <p>{message}</p>}
    </form>
  );
}

Important: Don't Set Content-Type Manually for FormData

When sending FormData, the browser automatically sets the appropriate multipart content type and boundary.

Avoid doing this:

headers: {
  "Content-Type": "multipart/form-data"
}

Let the browser generate it.

Also remember that file type and size checks in the frontend are not sufficient security controls. The server must validate uploaded files.

14. Using FormData for Traditional Form Submission

For some forms, you don't need to manage every input through separate React state.

The browser's FormData API can collect form values.

function ContactForm() {
  function handleSubmit(event) {
    event.preventDefault();

    const formData = new FormData(event.currentTarget);

    const values = Object.fromEntries(formData.entries());

    console.log(values);
  }

  return (
    <form onSubmit={handleSubmit}>
      <input
        name="name"
        placeholder="Your name"
        required
      />

      <input
        name="email"
        type="email"
        placeholder="Your email"
        required
      />

      <textarea
        name="message"
        placeholder="Your message"
        required
      />

      <button type="submit">
        Send Message
      </button>
    </form>
  );
}

This approach is particularly convenient for forms where you only need the values when the user submits.

Remember that unchecked checkboxes and unselected controls may not appear in the resulting FormData.

15. Organizing API Logic

As an application grows, placing every API request directly inside components can make the code difficult to maintain.

A better approach is to separate API logic into dedicated modules.

For example:

src/
├── components/
│   ├── UserList.jsx
│   └── CreateUser.jsx
│
├── services/
│   └── userService.js
│
├── hooks/
│   └── useUsers.js
│
├── App.jsx
└── main.jsx

Step 1: Create an API Service

services/userService.js

const API_URL = "/api/users";

export async function getUsers(signal) {
  const response = await fetch(API_URL, { signal });

  if (!response.ok) {
    throw new Error("Failed to fetch users");
  }

  return response.json();
}

export async function createUser(user) {
  const response = await fetch(API_URL, {
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify(user)
  });

  if (!response.ok) {
    throw new Error("Failed to create user");
  }

  return response.json();
}

export async function deleteUser(id) {
  const response = await fetch(`${API_URL}/${id}`, {
    method: "DELETE"
  });

  if (!response.ok) {
    throw new Error("Failed to delete user");
  }
}

Step 2: Create a Custom Hook

hooks/useUsers.js

import { useEffect, useState } from "react";
import { getUsers } from "../services/userService";

export function useUsers() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState("");

  useEffect(() => {
    const controller = new AbortController();

    async function loadUsers() {
      try {
        const data = await getUsers(controller.signal);

        setUsers(data);
      } catch (error) {
        if (error.name !== "AbortError") {
          setError(error.message);
        }
      } finally {
        if (!controller.signal.aborted) {
          setLoading(false);
        }
      }
    }

    loadUsers();

    return () => controller.abort();
  }, []);

  return {
    users,
    loading,
    error
  };
}

Step 3: Use the Hook in a Component

components/UserList.jsx

import { useUsers } from "../hooks/useUsers";

function UserList() {
  const {
    users,
    loading,
    error
  } = useUsers();

  if (loading) {
    return <p>Loading users...</p>;
  }

  if (error) {
    return <p>{error}</p>;
  }

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

export default UserList;

This structure separates responsibilities:

Components handle presentation.
Services handle HTTP requests.
Custom Hooks manage reusable React logic.

For larger applications, you may also introduce a dedicated API client and a data-fetching library.

16. React Query and Modern Data Fetching

As applications become more complex, manually managing every API request can become repetitive.

You may need to handle:

Caching.
Background refetching.
Request deduplication.
Retries.
Pagination.
Infinite scrolling.
Optimistic updates.
Synchronizing server data.

A popular solution is TanStack Query, formerly known as React Query.

It provides tools for managing asynchronous server state.

Installing TanStack Query

npm install @tanstack/react-query

Configure the Query Client

import {
  QueryClient,
  QueryClientProvider
} from "@tanstack/react-query";

const queryClient = new QueryClient();

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Users />
    </QueryClientProvider>
  );
}

export default App;

Fetch Data with useQuery

import { useQuery } from "@tanstack/react-query";

async function fetchUsers() {
  const response = await fetch("/api/users");

  if (!response.ok) {
    throw new Error("Failed to fetch users");
  }

  return response.json();
}

function Users() {
  const {
    data,
    isLoading,
    isError,
    error
  } = useQuery({
    queryKey: ["users"],
    queryFn: fetchUsers
  });

  if (isLoading) {
    return <p>Loading...</p>;
  }

  if (isError) {
    return <p>{error.message}</p>;
  }

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

Why Use TanStack Query?

It helps manage server state separately from local component state.

For example:

useState is great for a modal's open/closed state.
TanStack Query is useful for managing users fetched from an API.

They solve different problems and can work together.

17. Common Mistakes When Working with Forms and APIs

Let's review mistakes that frequently cause problems.

Mistake 1: Forgetting event.preventDefault()

Incorrect:

function handleSubmit(event) {
  console.log("Submitted");
}

Correct:

function handleSubmit(event) {
  event.preventDefault();

  console.log("Submitted");
}

Without preventing the default behavior, the browser may navigate or reload the page.

Mistake 2: Forgetting the onChange Handler

Incorrect:

<input value={name} />

Correct:

<input
  value={name}
  onChange={event => setName(event.target.value)}
/>

A controlled input needs a way to update its state.

Mistake 3: Using value Instead of checked for Checkboxes

Incorrect:

<input type="checkbox" value={accepted} />

Correct:

<input
  type="checkbox"
  checked={accepted}
  onChange={event => setAccepted(event.target.checked)}
/>

Mistake 4: Assuming Fetch Rejects on HTTP Errors

Incorrect:

const response = await fetch("/api/users");

const data = await response.json();

Better:

const response = await fetch("/api/users");

if (!response.ok) {
  throw new Error("Request failed");
}

const data = await response.json();

Mistake 5: Forgetting Loading States

Users should know when an operation is running.

Use a loading state to prevent duplicate submissions and provide feedback.

Mistake 6: Ignoring Errors

Always consider network failures and unsuccessful server responses.

A good application should display meaningful error messages.

Mistake 7: Not Cancelling Outdated Requests

When requests depend on changing values, consider using AbortController or another strategy to prevent stale results from updating the UI.

Mistake 8: Trusting Frontend Validation

Frontend validation improves usability, but backend validation is essential for security and data integrity.

Mistake 9: Hardcoding Sensitive API Credentials

Never put private API keys or secrets inside frontend code.

Anything bundled into a browser application can be inspected by users.

Keep sensitive credentials on the server.

18. Practical Project: Build a Contact Form with API Integration

Let's combine the concepts into a more complete example.

Our contact form will include:

Controlled inputs.
Form validation.
Loading state.
API submission.
Success feedback.
Error handling.
Input reset.

import { useState } from "react";

function ContactForm() {
  const [formData, setFormData] = useState({
    name: "",
    email: "",
    message: ""
  });

  const [errors, setErrors] = useState({});
  const [loading, setLoading] = useState(false);
  const [status, setStatus] = useState("");

  function handleChange(event) {
    const { name, value } = event.target;

    setFormData(previous => ({
      ...previous,
      [name]: value
    }));
  }

  function validate() {
    const newErrors = {};

    if (!formData.name.trim()) {
      newErrors.name = "Name is required";
    }

    if (!formData.email.trim()) {
      newErrors.email = "Email is required";
    } else if (
      !/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(formData.email)
    ) {
      newErrors.email = "Enter a valid email";
    }

    if (!formData.message.trim()) {
      newErrors.message = "Message is required";
    }

    return newErrors;
  }

  async function handleSubmit(event) {
    event.preventDefault();

    setStatus("");

    const validationErrors = validate();

    setErrors(validationErrors);

    if (Object.keys(validationErrors).length > 0) {
      return;
    }

    setLoading(true);

    try {
      const response = await fetch("/api/contact", {
        method: "POST",
        headers: {
          "Content-Type": "application/json"
        },
        body: JSON.stringify(formData)
      });

      if (!response.ok) {
        throw new Error("Failed to send message");
      }

      setStatus("Your message was sent successfully!");

      setFormData({
        name: "",
        email: "",
        message: ""
      });

      setErrors({});
    } catch (error) {
      setStatus(error.message);
    } finally {
      setLoading(false);
    }
  }

  return (
    <form onSubmit={handleSubmit}>
      <h2>Contact Us</h2>

      <div>
        <label htmlFor="name">Name</label>

        <input
          id="name"
          name="name"
          value={formData.name}
          onChange={handleChange}
        />

        {errors.name && <p>{errors.name}</p>}
      </div>

      <div>
        <label htmlFor="email">Email</label>

        <input
          id="email"
          name="email"
          type="email"
          value={formData.email}
          onChange={handleChange}
        />

        {errors.email && <p>{errors.email}</p>}
      </div>

      <div>
        <label htmlFor="message">Message</label>

        <textarea
          id="message"
          name="message"
          value={formData.message}
          onChange={handleChange}
        />

        {errors.message && <p>{errors.message}</p>}
      </div>

      <button type="submit" disabled={loading}>
        {loading ? "Sending..." : "Send Message"}
      </button>

      {status && <p role="status">{status}</p>}
    </form>
  );
}

export default ContactForm;

This example is a good starting point for building real forms.

For production, you should also consider:

Server-side validation.
Rate limiting and spam protection.
Accessible error announcements.
Secure handling of submitted information.
Appropriate success and failure responses.
Preventing duplicate submissions on the backend.

19. Best Practices for React Forms and API Integration

Here are some practical recommendations.

1. Keep form state predictable.

Use controlled inputs when the UI needs to respond to input changes.

2. Separate validation logic.

Keep validation functions outside the component when possible.

3. Always handle loading and error states.

Don't leave users wondering whether an operation succeeded.

4. Separate API services from UI components.

This makes code easier to test and maintain.

5. Cancel outdated requests when appropriate.

Use AbortController for requests that should stop when their Effect is cleaned up.

6. Use appropriate data-fetching tools.

For complex server-state requirements, consider TanStack Query or framework-provided data-loading features.

7. Validate data on the server.

Never depend exclusively on frontend validation.

8. Make forms accessible.

Use labels, meaningful error messages, keyboard-friendly controls, and appropriate semantic HTML.

9. Avoid storing unnecessary duplicate state.

If a value can be calculated from existing state, calculate it rather than maintaining another synchronized state variable.

10. Never expose private credentials in frontend code.

Sensitive operations should be handled by a secure backend.

20. Final Thoughts

Forms and API integration are essential skills for every React developer.

Understanding how to manage input values, validate user data, submit forms, and communicate with APIs allows you to build applications that go beyond static interfaces.

The most important concepts from this article are:

Controlled and uncontrolled components.
Managing multiple inputs.
Handling form submissions.
Validating user input.
Working with asynchronous operations.
Fetching and updating API data.
Managing loading and error states.
Organizing API services.
Using TanStack Query for server-state management.

Don't just memorize these patterns.

Build a registration form, create a contact page, connect an application to an API, and experiment with different validation strategies.

The more you practice, the more natural these patterns will become.

What's Next?

In Part 5 of the React Mastery Series, we'll explore:

React Architecture & Best Practices — Building Maintainable and Scalable Applications

We'll cover:

Organizing React project structures.
Component architecture.
Container and presentation components.
Reusable components.
Composition patterns.
Separation of concerns.
Custom Hooks and service layers.
Error boundaries.
Environment variables.
Clean code principles.
Scaling React applications.

We'll move from writing individual components to designing complete React applications.

Happy coding! 🚀

React Mastery Series — Part 3: React Hooks — The Complete Practical Guide

Hamed Farazi — Wed, 04 Nov 2026 07:52:32 +0000

React Hooks are one of the most important concepts in modern React development.

They allow functional components to use state, manage side effects, access context, reference DOM elements, optimize performance, and reuse stateful logic.

Before Hooks were introduced, many React features required class components. Hooks changed that by making powerful React capabilities available directly inside function components.

In this guide, we'll explore the most important React Hooks, understand when to use them, avoid common mistakes, and build practical examples.

By the end, you'll understand not only how Hooks work, but also how to choose the right Hook for a particular problem.

1. What Are React Hooks?

Hooks are special functions provided by React that let function components use React features.

For example:

import { useState } from "react";

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

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

Here, useState allows a function component to remember a value between renders.

Without Hooks, function components were primarily used for presenting UI based on props.

With Hooks, function components can manage much more complex behavior.

Why Were Hooks Introduced?

Hooks help solve several problems:

Reusing stateful logic between components.
Avoiding large and complicated class components.
Organizing related logic together.
Managing component state and lifecycle behavior.
Making React code easier to understand and maintain.

The most important idea is that Hooks let you organize component logic around features rather than lifecycle methods.

2. Rules of Hooks

Before learning individual Hooks, you must understand two important rules.

Rule 1: Only Call Hooks at the Top Level

Never call Hooks inside:

Conditions.
Loops.
Nested functions.
Event handlers.
try / catch blocks.

Incorrect:

function Profile({ isLoggedIn }) {
  if (isLoggedIn) {
    const [name, setName] = useState("Alex");
  }

  return <h1>Profile</h1>;
}

Correct:

function Profile({ isLoggedIn }) {
  const [name, setName] = useState("Alex");

  if (!isLoggedIn) {
    return <p>Please log in.</p>;
  }

  return <h1>Hello, {name}</h1>;
}

Why?

React relies on the order of Hook calls to associate Hook state with the correct component.

If Hooks are called conditionally, their order can change between renders, causing bugs.

Rule 2: Only Call Hooks from React Functions

Hooks should be called from:

React function components.
Custom Hooks.

Incorrect:

function calculateSomething() {
  const [value, setValue] = useState(0);
}

Correct:

function useCounter() {
  const [value, setValue] = useState(0);

  return { value, setValue };
}

Custom Hooks are discussed later in this article.

3. useState — Managing Component State

useState is probably the Hook you'll use most frequently.

It allows a component to store information that can change over time.

Basic Syntax

const [state, setState] = useState(initialValue);

It returns an array containing:

The current state value.
A function for updating that value.

Example:

import { useState } from "react";

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

  return (
    <div>
      <h2>Count: {count}</h2>

      <button onClick={() => setCount(count + 1)}>
        Increase
      </button>

      <button onClick={() => setCount(count - 1)}>
        Decrease
      </button>
    </div>
  );
}

When setCount is called, React schedules an update and renders the component with the new state.

Updating State Based on Previous State

Sometimes you need to calculate the next state using the previous state.

In this situation, use the functional updater form.

setCount(previousCount => previousCount + 1);

For example:

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

  function increaseThreeTimes() {
    setCount(value => value + 1);
    setCount(value => value + 1);
    setCount(value => value + 1);
  }

  return (
    <div>
      <h2>{count}</h2>

      <button onClick={increaseThreeTimes}>
        Increase by 3
      </button>
    </div>
  );
}

Why use this approach?

State values are snapshots associated with a particular render. Multiple updates that depend on the previous value should use updater functions to avoid calculating from an outdated snapshot.

Managing Objects with useState

You can also store objects in state.

function UserProfile() {
  const [user, setUser] = useState({
    name: "Alex",
    age: 25,
    city: "Berlin"
  });

  function updateAge() {
    setUser(previousUser => ({
      ...previousUser,
      age: previousUser.age + 1
    }));
  }

  return (
    <div>
      <h2>{user.name}</h2>
      <p>Age: {user.age}</p>
      <p>City: {user.city}</p>

      <button onClick={updateAge}>
        Increase Age
      </button>
    </div>
  );
}

Notice the use of the spread operator:

{
  ...previousUser,
  age: previousUser.age + 1
}

React state should be treated as immutable.

Instead of modifying the existing object, create a new object with the updated properties.

Managing Arrays with useState

function TodoList() {
  const [todos, setTodos] = useState([
    "Learn React",
    "Practice JavaScript"
  ]);

  function addTodo() {
    setTodos(previousTodos => [
      ...previousTodos,
      "Build a project"
    ]);
  }

  return (
    <div>
      <ul>
        {todos.map((todo, index) => (
          <li key={index}>{todo}</li>
        ))}
      </ul>

      <button onClick={addTodo}>
        Add Todo
      </button>
    </div>
  );
}

For lists that can be reordered, inserted into, or deleted from, use stable unique IDs instead of array indexes as keys.

4. useEffect — Synchronizing with External Systems

useEffect is one of the most misunderstood React Hooks.

It allows a component to synchronize with systems outside React.

Examples include:

Fetching data from an API.
Subscribing to browser events.
Connecting to a WebSocket.
Starting and cleaning up timers.
Synchronizing with third-party libraries.
Updating certain external browser APIs.

Basic Syntax

useEffect(() => {
  // Synchronization logic

  return () => {
    // Cleanup logic
  };
}, [dependencies]);

The dependency array determines when React needs to re-synchronize the Effect.

Example 1: An Effect After Every Commit

import { useEffect, useState } from "react";

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

  useEffect(() => {
    console.log("Component committed.");
  });

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

There is no dependency array.

The Effect runs after every commit of this component.

Example 2: An Effect with an Empty Dependency Array

useEffect(() => {
  console.log("Effect setup");

}, []);

This Effect has no reactive dependencies.

It runs when the component mounts, and its cleanup runs when the component unmounts.

In development, React Strict Mode may perform an additional setup-and-cleanup cycle to help reveal bugs. Therefore, don't assume an Effect's setup always runs exactly once in every environment.

Example 3: An Effect with Dependencies

function UserProfile({ userId }) {
  useEffect(() => {
    console.log("User ID changed:", userId);
  }, [userId]);

  return <h2>User: {userId}</h2>;
}

The Effect runs after the initial commit and again when userId changes.

Understanding Dependency Arrays

Dependency array	When the Effect runs
No array	After every commit
`[]`	After initial mount
`[value]`	After mount and when `value` changes

React compares dependency values using Object.is.

Every reactive value used by an Effect should be included in its dependency array.

Don't remove dependencies just to force an Effect to run less frequently. Instead, restructure the code so that the Effect genuinely depends only on the values it needs.

5. useEffect Cleanup

Some Effects create resources that must be released.

For example:

Event listeners.
Timers.
WebSocket connections.
Subscriptions.

React lets you return a cleanup function from an Effect.

Example:

import { useEffect } from "react";

function WindowWidth() {
  useEffect(() => {
    function handleResize() {
      console.log(window.innerWidth);
    }

    window.addEventListener("resize", handleResize);

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

  return <p>Resize the browser window.</p>;
}

The cleanup function runs:

Before the Effect runs again with changed dependencies.
When the component unmounts.

This prevents old subscriptions and event listeners from remaining active.

Practical Example: A Timer

import { useEffect, useState } from "react";

function Timer() {
  const [seconds, setSeconds] = useState(0);

  useEffect(() => {
    const intervalId = setInterval(() => {
      setSeconds(previous => previous + 1);
    }, 1000);

    return () => {
      clearInterval(intervalId);
    };
  }, []);

  return <h2>Seconds: {seconds}</h2>;
}

The cleanup function stops the interval when the component is removed.

6. Fetching API Data with useEffect

A common use case for Effects is synchronizing a component with data from an API.

Let's build a simple example.

import { useEffect, useState } from "react";

function Users() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const controller = new AbortController();

    async function fetchUsers() {
      try {
        setLoading(true);
        setError(null);

        const response = await fetch(
          "https://jsonplaceholder.typicode.com/users",
          { signal: controller.signal }
        );

        if (!response.ok) {
          throw new Error("Failed to fetch users");
        }

        const data = await response.json();

        setUsers(data);
      } catch (error) {
        if (error.name !== "AbortError") {
          setError(error.message);
        }
      } finally {
        if (!controller.signal.aborted) {
          setLoading(false);
        }
      }
    }

    fetchUsers();

    return () => {
      controller.abort();
    };
  }, []);

  if (loading) {
    return <p>Loading users...</p>;
  }

  if (error) {
    return <p>Error: {error}</p>;
  }

  return (
    <ul>
      {users.map(user => (
        <li key={user.id}>
          {user.name} — {user.email}
        </li>
      ))}
    </ul>
  );
}

This example demonstrates several important concepts:

Loading state.
Error handling.
API requests.
Effect cleanup.
Request cancellation.
Rendering dynamic data.

Important: useEffect is not automatically the best solution for every data-fetching requirement. Larger applications often benefit from framework data-loading features or dedicated libraries that handle caching, request deduplication, retries, and server rendering.

A Common useEffect Mistake

Avoid using Effects to calculate values that can be calculated directly during rendering.

Unnecessary:

function Product({ price, quantity }) {
  const [total, setTotal] = useState(0);

  useEffect(() => {
    setTotal(price * quantity);
  }, [price, quantity]);

  return <p>Total: {total}</p>;
}

Better:

function Product({ price, quantity }) {
  const total = price * quantity;

  return <p>Total: {total}</p>;
}

Why?

The total is derived from existing props. It doesn't need separate state or an Effect.

Use Effects for synchronization with external systems, not as a general mechanism for responding to every change in React data.

7. useRef — Referencing DOM Elements and Storing Mutable Values

useRef creates an object that persists between renders.

Its .current property can be changed without triggering a re-render.

Basic Syntax

const myRef = useRef(initialValue);

Example 1: Accessing a DOM Element

import { useRef } from "react";

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

  function focusInput() {
    inputRef.current.focus();
  }

  return (
    <div>
      <input ref={inputRef} type="text" />

      <button onClick={focusInput}>
        Focus Input
      </button>
    </div>
  );
}

Let's understand what happens:

useRef(null) creates a reference object.
The object is assigned to the input using the ref attribute.
After React attaches the DOM element, inputRef.current points to it.
Calling .focus() focuses the input.

Example 2: Storing a Previous Value

import { useEffect, useRef } from "react";

function Counter({ count }) {
  const previousCount = useRef(count);

  useEffect(() => {
    previousCount.current = count;
  }, [count]);

  return (
    <div>
      <p>Current: {count}</p>
      <p>Previous: {previousCount.current}</p>
    </div>
  );
}

The ref stores a value between renders without causing another render when it changes.

useState vs useRef

Feature	useState	useRef
Stores values	Yes	Yes
Persists between renders	Yes	Yes
Updating triggers render	Yes	No
Common use	UI state	DOM references and mutable values

Remember: If changing a value should update the UI, state is usually the right choice. If the value must persist but doesn't need to trigger rendering, a ref may be appropriate.

8. useContext — Sharing Data Across Components

Sometimes multiple components need access to the same information.

For example:

Current user.
Theme settings.
Language preferences.
Application configuration.

Passing props through many intermediate components can become inconvenient. This is often called prop drilling.

React Context provides a way to share values across a component tree.

Step 1: Create a Context

import { createContext } from "react";

export const ThemeContext = createContext("light");

Step 2: Provide the Context Value

import { ThemeContext } from "./ThemeContext";

function App() {
  return (
    <ThemeContext.Provider value="dark">
      <Dashboard />
    </ThemeContext.Provider>
  );
}

Step 3: Consume the Context

import { useContext } from "react";
import { ThemeContext } from "./ThemeContext";

function Dashboard() {
  const theme = useContext(ThemeContext);

  return (
    <div>
      <h1>Current theme: {theme}</h1>
    </div>
  );
}

Now the Dashboard component can access the theme without receiving it through props.

Context with State

Context can also share state.

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

const AuthContext = createContext(null);

function AuthProvider({ children }) {
  const [user, setUser] = useState(null);

  function login(username) {
    setUser({ username });
  }

  function logout() {
    setUser(null);
  }

  return (
    <AuthContext.Provider
      value={{ user, login, logout }}
    >
      {children}
    </AuthContext.Provider>
  );
}

function useAuth() {
  const context = useContext(AuthContext);

  if (context === null) {
    throw new Error(
      "useAuth must be used inside AuthProvider"
    );
  }

  return context;
}

A component can now consume the shared authentication state:

function Profile() {
  const { user, logout } = useAuth();

  if (!user) {
    return <p>Please log in.</p>;
  }

  return (
    <div>
      <h2>Welcome, {user.username}</h2>
      <button onClick={logout}>Logout</button>
    </div>
  );
}

Wrap the application with the provider:

function App() {
  return (
    <AuthProvider>
      <Profile />
    </AuthProvider>
  );
}

Context is useful for sharing values across a component tree, but it isn't automatically a replacement for every state-management solution.

For frequently changing, complex application state, consider whether a dedicated state-management approach is more appropriate.

9. useReducer — Managing Complex State Logic

useReducer is an alternative to useState.

It is particularly useful when:

State has multiple related properties.
Many actions can change the state.
Update logic is becoming complicated.
You want to centralize state transitions.

Basic Syntax

const [state, dispatch] = useReducer(reducer, initialState);

The reducer receives the current state and an action, then returns the next state.

Example: Counter with useReducer

import { useReducer } from "react";

const initialState = {
  count: 0
};

function reducer(state, action) {
  switch (action.type) {
    case "increment":
      return {
        ...state,
        count: state.count + 1
      };

    case "decrement":
      return {
        ...state,
        count: state.count - 1
      };

    case "reset":
      return initialState;

    default:
      throw new Error("Unknown action");
  }
}

function Counter() {
  const [state, dispatch] = useReducer(
    reducer,
    initialState
  );

  return (
    <div>
      <h2>{state.count}</h2>

      <button
        onClick={() => dispatch({ type: "increment" })}
      >
        Increase
      </button>

      <button
        onClick={() => dispatch({ type: "decrement" })}
      >
        Decrease
      </button>

      <button
        onClick={() => dispatch({ type: "reset" })}
      >
        Reset
      </button>
    </div>
  );
}

How Does It Work?

When a user clicks the Increase button:

The event handler calls dispatch.
React sends the action to the reducer.
The reducer calculates the next state.
React renders the component with the updated state.

useState vs useReducer

Use useState when state updates are relatively simple.

Use useReducer when state transitions involve multiple actions or more centralized logic.

Neither is universally better. Choose based on the complexity of the state.

10. useMemo — Optimizing Expensive Calculations

useMemo allows React to cache the result of a calculation between renders.

It is useful when a calculation is expensive and its inputs don't change on every render.

Basic Syntax

const cachedValue = useMemo(() => {
  return expensiveCalculation();
}, [dependencies]);

Example

import { useMemo, useState } from "react";

function ProductList({ products }) {
  const [search, setSearch] = useState("");

  const filteredProducts = useMemo(() => {
    console.log("Filtering products...");

    return products.filter(product =>
      product.name
        .toLowerCase()
        .includes(search.toLowerCase())
    );
  }, [products, search]);

  return (
    <div>
      <input
        value={search}
        onChange={event => setSearch(event.target.value)}
        placeholder="Search products..."
      />

      <ul>
        {filteredProducts.map(product => (
          <li key={product.id}>
            {product.name}
          </li>
        ))}
      </ul>
    </div>
  );
}

The filtered result can be reused while both products and search remain unchanged.

Important Notes

useMemo is a performance optimization, not a requirement for correct code.

Don't wrap every calculation in useMemo.

For simple operations, normal JavaScript is usually clearer:

const fullName = firstName + " " + lastName;

There is no reason to memoize every small calculation.

Also, React may discard memoized values in certain situations. Your code should remain correct even if a calculation runs again.

11. useCallback — Caching Function References

useCallback lets React cache a function definition between renders.

It is useful when function identity matters, particularly when passing callbacks to memoized child components or using functions as dependencies.

Basic Syntax

const cachedFunction = useCallback(() => {
  // Function logic
}, [dependencies]);

Example

import { useCallback, useState } from "react";

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

  const handleClick = useCallback(() => {
    console.log("Button clicked");
  }, []);

  return (
    <div>
      <h2>{count}</h2>

      <button onClick={() => setCount(count + 1)}>
        Increase Count
      </button>

      <Child onClick={handleClick} />
    </div>
  );
}

function Child({ onClick }) {
  console.log("Child rendered");

  return (
    <button onClick={onClick}>
      Child Button
    </button>
  );
}

In this example, handleClick keeps the same function identity between renders.

However, this alone doesn't prevent Child from rendering.

To skip some child renders when its props remain unchanged, you can use memo:

import { memo } from "react";

const Child = memo(function Child({ onClick }) {
  console.log("Child rendered");

  return (
    <button onClick={onClick}>
      Child Button
    </button>
  );
});

Now React can skip rendering the child when its props are unchanged.

useMemo vs useCallback

Hook	What it caches
useMemo	A calculated value
useCallback	A function definition

A useful mental model:

useMemo(() => calculateValue(), [dependency]);

useCallback(() => handleAction(), [dependency]);

Both are optimization tools. Use them when there is a measurable or meaningful reason, not automatically.

In projects using React Compiler, some manual memoization may be handled automatically, depending on the project's configuration and supported features.

12. useId — Generating Unique IDs for Accessibility

useId generates unique IDs that are useful for connecting related accessibility elements.

For example, an input and its label.

import { useId } from "react";

function EmailInput() {
  const id = useId();

  return (
    <div>
      <label htmlFor={id}>
        Email Address
      </label>

      <input
        id={id}
        type="email"
      />
    </div>
  );
}

React generates an ID that can connect the label to the input.

This is particularly useful when a reusable component appears multiple times.

Important: Don't use useId to generate list keys.

List keys should come from stable data identifiers.

13. useTransition — Keeping the UI Responsive

Sometimes an update triggers expensive rendering work.

You may want an interaction, such as typing into an input, to remain responsive while another update happens in the background.

useTransition allows you to mark certain state updates as non-urgent.

Example

import {
  useState,
  useTransition
} from "react";

function SearchPage({ items }) {
  const [query, setQuery] = useState("");
  const [filteredQuery, setFilteredQuery] = useState("");

  const [isPending, startTransition] = useTransition();

  function handleChange(event) {
    const value = event.target.value;

    setQuery(value);

    startTransition(() => {
      setFilteredQuery(value);
    });
  }

  const filteredItems = items.filter(item =>
    item.toLowerCase().includes(filteredQuery.toLowerCase())
  );

  return (
    <div>
      <input
        value={query}
        onChange={handleChange}
        placeholder="Search..."
      />

      {isPending && <p>Updating results...</p>}

      <ul>
        {filteredItems.map(item => (
          <li key={item}>{item}</li>
        ))}
      </ul>
    </div>
  );
}

The input update is urgent, while the filtering-related state update is marked as a transition.

Important Concepts

useTransition returns:

isPending: indicates whether a transition is pending.
startTransition: marks state updates as transitions.

A transition is not a replacement for debouncing, and it doesn't automatically make expensive JavaScript calculations faster.

It helps React prioritize rendering work.

14. useDeferredValue — Deferring Updates

useDeferredValue lets a component defer updating part of its UI.

It is useful when a value changes frequently and rendering everything based on that value is expensive.

Example

import {
  useDeferredValue,
  useState
} from "react";

function Search({ items }) {
  const [query, setQuery] = useState("");

  const deferredQuery = useDeferredValue(query);

  const filteredItems = items.filter(item =>
    item.toLowerCase().includes(
      deferredQuery.toLowerCase()
    )
  );

  return (
    <div>
      <input
        value={query}
        onChange={event => setQuery(event.target.value)}
        placeholder="Search..."
      />

      <ul>
        {filteredItems.map(item => (
          <li key={item}>{item}</li>
        ))}
      </ul>
    </div>
  );
}

The input can update immediately while the result-rendering portion can temporarily use an older value.

This can improve responsiveness when the deferred part is expensive to render.

useTransition vs useDeferredValue

Hook	Main purpose
useTransition	Mark state updates as non-urgent
useDeferredValue	Defer updating a value used by rendering

Use useTransition when you control the state update.

Use useDeferredValue when you receive a value and want to defer how your component uses it.

15. Custom Hooks — Reusing Stateful Logic

One of the most powerful features of Hooks is the ability to create your own Hooks.

A Custom Hook is a JavaScript function whose name starts with use and that can call other Hooks.

Custom Hooks help you extract reusable behavior from components.

Example: useWindowWidth

Imagine several components need to know the browser window width.

Instead of repeating the same Effect everywhere, create a Custom Hook.

import {
  useEffect,
  useState
} from "react";

function useWindowWidth() {
  const [width, setWidth] = useState(window.innerWidth);

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

    window.addEventListener("resize", handleResize);

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

  return width;
}

Now any component can use it:

function ResponsiveLayout() {
  const width = useWindowWidth();

  return (
    <div>
      <h2>Window Width: {width}px</h2>

      {width < 768 ? (
        <p>Mobile Layout</p>
      ) : (
        <p>Desktop Layout</p>
      )}
    </div>
  );
}

Example: useLocalStorage

A reusable Hook can synchronize a state value with browser storage.

import {
  useEffect,
  useState
} from "react";

function useLocalStorage(key, initialValue) {
  const [value, setValue] = useState(() => {
    const storedValue = localStorage.getItem(key);

    return storedValue !== null
      ? JSON.parse(storedValue)
      : initialValue;
  });

  useEffect(() => {
    localStorage.setItem(key, JSON.stringify(value));
  }, [key, value]);

  return [value, setValue];
}

Usage:

function Settings() {
  const [theme, setTheme] = useLocalStorage(
    "theme",
    "light"
  );

  return (
    <div>
      <h2>Current Theme: {theme}</h2>

      <button
        onClick={() =>
          setTheme(theme === "light" ? "dark" : "light")
        }
      >
        Toggle Theme
      </button>
    </div>
  );
}

This is a simplified browser-only implementation. In server-rendered applications, browser APIs such as localStorage must be accessed only in an appropriate client-side environment. Production implementations should also consider invalid stored JSON and storage errors.

Important: Custom Hooks Share Logic, Not State

Consider two components using the same Hook:

function ComponentA() {
  const [count, setCount] = useCounter();
}

function ComponentB() {
  const [count, setCount] = useCounter();
}

Each component gets its own independent state.

Custom Hooks share the logic for managing state, not the actual state instance.

If components need to share the same state, use a shared parent, Context, or an appropriate state-management solution.

16. Other Useful React Hooks

The Hooks covered so far are enough for many everyday applications, but React provides additional Hooks for more specialized situations.

useLayoutEffect

useLayoutEffect is similar to useEffect, but it runs after DOM mutations and before the browser paints.

It is useful when you need to measure or synchronously adjust layout before the user sees the result.

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

function Tooltip() {
  const tooltipRef = useRef(null);
  const [height, setHeight] = useState(0);

  useLayoutEffect(() => {
    if (tooltipRef.current) {
      setHeight(
        tooltipRef.current.getBoundingClientRect().height
      );
    }
  }, []);

  return (
    <div>
      <div ref={tooltipRef}>
        Tooltip content
      </div>

      <p>Tooltip height: {height}px</p>
    </div>
  );
}

Use useLayoutEffect only when necessary. It can block browser painting, so useEffect is generally preferable for ordinary synchronization.

useImperativeHandle

useImperativeHandle allows a component to customize the value exposed through a ref.

It is useful when a parent needs access to a limited imperative API rather than the entire child implementation.

import {
  useImperativeHandle,
  useRef
} from "react";

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

  useImperativeHandle(ref, () => ({
    focus() {
      inputRef.current.focus();
    },

    clear() {
      inputRef.current.value = "";
    }
  }), []);

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

This example uses the React 19 ref-as-prop API. In React 18 and earlier, forwardRef is generally used to receive a ref in a function component.

useSyncExternalStore

This Hook is designed for subscribing to external stores in a way that works correctly with React's rendering model.

It is especially useful for library authors and integrations with external state systems.

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 getSnapshot() {
  return navigator.onLine;
}

function NetworkStatus() {
  const isOnline = useSyncExternalStore(
    subscribe,
    getSnapshot
  );

  return (
    <p>
      {isOnline ? "Online" : "Offline"}
    </p>
  );
}

For server-rendered applications, you may also need to provide a server snapshot function.

17. React 19: The use API Is Different from Traditional Hooks

React 19 introduced the use API, which can read resources such as Promises and Context.

Despite its name, use is not an ordinary Hook.

For example, unlike traditional Hooks, use can be called inside conditions and loops in supported situations.

import { use } from "react";

function Message({ messagePromise }) {
  const message = use(messagePromise);

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

When the Promise is pending, React can suspend rendering. The component should be placed within an appropriate Suspense boundary.

import { Suspense } from "react";

function App({ messagePromise }) {
  return (
    <Suspense fallback={<p>Loading...</p>}>
      <Message messagePromise={messagePromise} />
    </Suspense>
  );
}

This API has specific rules and should not be confused with traditional Hooks such as useState and useEffect.

18. Practical Project: Building a Custom Counter Dashboard

Let's combine several Hooks into a small application.

Our dashboard will include:

Counter state with useReducer.
Theme management with useState.
A document title synchronization Effect.
A ref for focusing an input.
A memoized calculation.
A Custom Hook for reusable counter logic.

Step 1: Create the Custom Hook

import { useReducer } from "react";

const initialState = {
  count: 0
};

function counterReducer(state, action) {
  switch (action.type) {
    case "increment":
      return {
        count: state.count + 1
      };

    case "decrement":
      return {
        count: state.count - 1
      };

    case "reset":
      return initialState;

    default:
      return state;
  }
}

export function useCounter() {
  const [state, dispatch] = useReducer(
    counterReducer,
    initialState
  );

  return {
    count: state.count,
    increment: () => dispatch({ type: "increment" }),
    decrement: () => dispatch({ type: "decrement" }),
    reset: () => dispatch({ type: "reset" })
  };
}

Step 2: Build the Dashboard

import {
  useEffect,
  useMemo,
  useRef,
  useState
} from "react";

import { useCounter } from "./useCounter";

function Dashboard() {
  const {
    count,
    increment,
    decrement,
    reset
  } = useCounter();

  const [theme, setTheme] = useState("light");
  const [name, setName] = useState("");

  const inputRef = useRef(null);

  const squaredCount = useMemo(() => {
    return count * count;
  }, [count]);

  useEffect(() => {
    document.title = `Count: ${count}`;
  }, [count]);

  function focusInput() {
    inputRef.current.focus();
  }

  return (
    <div
      style={{
        padding: "30px",
        background: theme === "dark" ? "#222" : "#fff",
        color: theme === "dark" ? "#fff" : "#222"
      }}
    >
      <h1>React Hooks Dashboard</h1>

      <h2>Counter: {count}</h2>

      <p>Squared Value: {squaredCount}</p>

      <button onClick={increment}>
        Increase
      </button>

      <button onClick={decrement}>
        Decrease
      </button>

      <button onClick={reset}>
        Reset
      </button>

      <hr />

      <h2>Theme Settings</h2>

      <button
        onClick={() =>
          setTheme(theme === "light" ? "dark" : "light")
        }
      >
        Toggle Theme
      </button>

      <hr />

      <h2>User Settings</h2>

      <input
        ref={inputRef}
        value={name}
        onChange={event => setName(event.target.value)}
        placeholder="Enter your name"
      />

      <button onClick={focusInput}>
        Focus Input
      </button>

      <p>
        Hello, {name || "Guest"}!
      </p>
    </div>
  );
}

export default Dashboard;

This small project demonstrates how different Hooks can work together in a single component.

Each Hook has a specific responsibility:

Hook	Responsibility
useReducer	Counter state management
useState	Theme and name state
useEffect	Synchronizing the document title
useRef	Accessing the input element
useMemo	Caching a calculation
useCounter	Reusing counter logic

Notice that useMemo isn't essential for this tiny calculation. It's included to demonstrate the API, not because squaring a number requires optimization.

19. Common React Hooks Mistakes

Let's review some mistakes developers frequently make.

Mistake 1: Calling Hooks Conditionally

Incorrect:

if (isLoggedIn) {
  const [user, setUser] = useState(null);
}

Correct:

const [user, setUser] = useState(null);

if (!isLoggedIn) {
  return <p>Please log in.</p>;
}

Mistake 2: Forgetting Effect Dependencies

Incorrect:

useEffect(() => {
  console.log(userId);
}, []);

If userId changes, this Effect won't re-synchronize.

Correct:

useEffect(() => {
  console.log(userId);
}, [userId]);

Mistake 3: Mutating State Directly

Incorrect:

user.name = "John";
setUser(user);

Correct:

setUser(previousUser => ({
  ...previousUser,
  name: "John"
}));

Mistake 4: Using useEffect for Derived State

Unnecessary:

const [total, setTotal] = useState(0);

useEffect(() => {
  setTotal(price * quantity);
}, [price, quantity]);

Better:

const total = price * quantity;

Mistake 5: Using useRef Instead of State for UI

If a value must trigger a UI update, use state.

Changing ref.current doesn't cause React to render again.

Mistake 6: Overusing useMemo and useCallback

Not every value or function needs to be memoized.

Start with simple code. Optimize when you have a reason.

Mistake 7: Forgetting Effect Cleanup

If an Effect creates a timer or subscription, make sure it releases that resource when appropriate.

Mistake 8: Treating Custom Hooks as Shared State

Two components calling the same Custom Hook normally receive separate state instances.

Use Context or another shared state solution when the actual state must be shared.

20. Which Hook Should You Use?

Here's a practical reference table.

Situation	Hook
Store component state	useState
Manage complex state transitions	useReducer
Synchronize with external systems	useEffect
Access a DOM element	useRef
Store mutable values without rendering	useRef
Share values through a component tree	useContext
Cache expensive calculations	useMemo
Cache function references	useCallback
Generate accessibility IDs	useId
Mark updates as non-urgent	useTransition
Defer a changing value	useDeferredValue
Reuse stateful logic	Custom Hooks
Measure layout before paint	useLayoutEffect
Expose a custom imperative ref API	useImperativeHandle
Subscribe to external stores	useSyncExternalStore

21. Final Thoughts

React Hooks transformed how developers build React applications.

They made functional components powerful enough to manage state, synchronize with external systems, share logic, and handle complex application behavior.

The most important Hooks to master first are:

useState
useEffect
useRef
useContext
useReducer
Custom Hooks

Once you're comfortable with these, learning performance-related and specialized Hooks becomes much easier.

Don't try to use every Hook in every component.

Good React development is about choosing the right tool for the problem, keeping components understandable, and writing code that behaves correctly.

The best way to master Hooks is to build real applications and experiment with them.

What's Next?

In Part 4 of the React Mastery Series, we'll explore:

React Forms & API Integration — Building Real-World Interactive Applications

We'll cover:

Controlled and uncontrolled components.
Handling form submissions.
Form validation.
Managing complex forms.
Fetching data from APIs.
Loading and error states.
Async JavaScript in React.
Building a practical application that communicates with an API.

If you're following this series, keep practicing the examples and try building your own small project using multiple Hooks.

Happy coding! 🚀

React Mastery Series — Part 2: JSX, Props, State & Events

Hamed Farazi — Tue, 03 Nov 2026 07:41:59 +0000

Welcome back to the React Mastery Series!

In Part 1, we explored the fundamentals of React, learned about components, understood declarative programming, and created our first React application.

Now it's time to make our components interactive.

A React application isn't just a collection of static components. It needs to respond to user interactions, display dynamic information, and update its interface whenever data changes.

In this article, we'll explore four fundamental concepts that make this possible:

JSX
Props
State
Events

We'll also cover conditional rendering, lists, keys, and how React handles state updates.

By the end of this article, you'll understand how to build dynamic React components and how data flows through a React application.

Understanding JSX
JSX vs. HTML
JavaScript Expressions Inside JSX
JSX Conditional Rendering
JSX Fragments
Understanding Props
Passing Props to Components
Props Destructuring
The children Prop
Props Are Read-Only
What Is State?
Why Do We Need State?
Understanding useState
How State Updates Work
Updating Objects in State
Updating Arrays in State
Understanding React Re-rendering
Handling Events
Passing Arguments to Event Handlers
Event Objects
Conditional Rendering in Practice
Rendering Lists with map()
Understanding Keys
Props vs. State
Practical Project: Interactive User Dashboard
Common Beginner Mistakes
What We Learned
What's Next?

1. Understanding JSX

JSX stands for JavaScript XML.

It is a syntax extension for JavaScript that allows developers to describe UI using HTML-like syntax.

For example:

const element = <h1>Hello React!</h1>;

At first glance, this looks like HTML.

However, JSX is not HTML.

It is a syntax that gets transformed into JavaScript by tools such as Vite's build pipeline.

Let's look at a component:

function App() {
  return (
    <div>
      <h1>Hello React</h1>
      <p>Welcome to the application.</p>
    </div>
  );
}

The component returns JSX describing the interface.

React uses this description to determine what should appear on the screen.

Why JSX?

Without JSX, you can create React elements using JavaScript:

import { createElement } from "react";

const element = createElement(
  "h1",
  null,
  "Hello React"
);

With JSX:

const element = <h1>Hello React</h1>;

JSX makes component structures easier to read and write.

2. JSX vs. HTML

Although JSX looks similar to HTML, there are important differences.

Difference 1: className instead of class

In HTML:

<div class="container">
  Hello
</div>

In JSX:

<div className="container">
  Hello
</div>

React uses className because class is a reserved JavaScript keyword.

Difference 2: camelCase attributes

Many JSX attributes use camelCase.

HTML:

<button onclick="handleClick()">
  Click
</button>

JSX:

<button onClick={handleClick}>
  Click
</button>

Notice the uppercase C in onClick.

Difference 3: Self-closing tags

In JSX, elements must be properly closed.

<img src="/logo.png" alt="Logo" />

<input type="text" />

Difference 4: Inline styles

In HTML:

<div style="background-color: red;">
  Hello
</div>

In JSX:

<div style={{ backgroundColor: "red" }}>
  Hello
</div>

Why are there two sets of curly braces?

The outer braces indicate a JavaScript expression.
The inner braces define a JavaScript object.

3. JavaScript Expressions Inside JSX

One of the most useful JSX features is the ability to embed JavaScript expressions using curly braces.

function App() {
  const name = "Hamed";
  const age = 25;

  return (
    <div>
      <h1>Hello, {name}</h1>
      <p>Age: {age}</p>
      <p>Next year: {age + 1}</p>
    </div>
  );
}

Output:

Hello, Hamed
Age: 25
Next year: 26

You can use:

Variables
Mathematical expressions
Function calls
Ternary expressions
Array methods
Object properties

For example:

function App() {
  const products = ["Laptop", "Phone", "Tablet"];

  return (
    <div>
      <p>Total products: {products.length}</p>

      <p>{products.join(", ")}</p>
    </div>
  );
}

Expressions vs. Statements

This distinction is important.

JSX curly braces accept JavaScript expressions, not arbitrary statements.

An expression produces a value.

{10 + 20}

A statement performs an action or controls program flow.

For example, you cannot directly write an if statement inside JSX:

// Incorrect
return (
  <div>
    {if (isLoggedIn) {
      "Welcome";
    }}
  </div>
);

Instead, use a ternary expression or calculate the result before returning JSX.

4. JSX Conditional Rendering

Sometimes the UI should change depending on a condition.

For example:

Show a login button if the user is logged out.
Show a dashboard if the user is logged in.
Display an error message if something goes wrong.

React supports several approaches.

Using the ternary operator

function App() {
  const isLoggedIn = true;

  return (
    <div>
      {isLoggedIn ? (
        <h1>Welcome back!</h1>
      ) : (
        <h1>Please log in.</h1>
      )}
    </div>
  );
}

Using logical AND

function App() {
  const hasNotifications = true;

  return (
    <div>
      {hasNotifications && (
        <p>You have new notifications.</p>
      )}
    </div>
  );
}

The expression after && is rendered only when the condition is truthy.

Be careful with numbers:

const count = 0;

return (
  <div>
    {count && <p>You have notifications</p>}
  </div>
);

This can render 0 because JavaScript's && operator returns the first falsy operand.

A safer approach:

{count > 0 && <p>You have notifications</p>}

Using if statements

For more complex conditions, use regular JavaScript before returning JSX.

function Greeting({ isLoggedIn }) {
  if (isLoggedIn) {
    return <h1>Welcome back!</h1>;
  }

  return <h1>Please log in.</h1>;
}

5. JSX Fragments

React components must return a single React element or a fragment.

Consider:

function App() {
  return (
    <h1>Hello</h1>
    <p>Welcome</p>
  );
}

This is invalid because there are two adjacent JSX elements without a parent.

One solution is to use a div:

function App() {
  return (
    <div>
      <h1>Hello</h1>
      <p>Welcome</p>
    </div>
  );
}

But sometimes we don't want an additional DOM element.

That's where Fragments come in.

function App() {
  return (
    <>
      <h1>Hello</h1>
      <p>Welcome</p>
    </>
  );
}

Fragments group elements without adding an extra DOM node.

You can also explicitly import Fragment:

import { Fragment } from "react";

function App() {
  return (
    <Fragment>
      <h1>Hello</h1>
      <p>Welcome</p>
    </Fragment>
  );
}

6. Understanding Props

Props stands for Properties.

Props allow a parent component to pass data to a child component.

Think of props as the inputs of a component.

Imagine a function:

function greet(name) {
  return `Hello, ${name}`;
}

console.log(greet("Hamed"));

The function receives an input and produces an output.

React components work similarly.

function Greeting(props) {
  return <h1>Hello, {props.name}</h1>;
}

Now we can pass data to it:

function App() {
  return <Greeting name="Hamed" />;
}

The output is:

Hello, Hamed

The parent component provides the data.

The child component receives it through props.

Passing multiple props

function UserCard(props) {
  return (
    <div>
      <h2>{props.name}</h2>
      <p>Age: {props.age}</p>
      <p>Role: {props.role}</p>
    </div>
  );
}

function App() {
  return (
    <UserCard
      name="Sarah"
      age={28}
      role="Frontend Developer"
    />
  );
}

Props can contain:

Strings
Numbers
Booleans
Arrays
Objects
Functions
React elements

For example:

<UserCard
  name="Sarah"
  age={28}
  isActive={true}
  skills={["React", "JavaScript", "CSS"]}
/>

7. Props Destructuring

Instead of repeatedly writing props.name, you can use JavaScript destructuring.

Without destructuring:

function UserCard(props) {
  return (
    <div>
      <h2>{props.name}</h2>
      <p>{props.age}</p>
    </div>
  );
}

With destructuring:

function UserCard({ name, age }) {
  return (
    <div>
      <h2>{name}</h2>
      <p>{age}</p>
    </div>
  );
}

This is cleaner and more readable.

You can also provide default values:

function UserCard({
  name = "Anonymous",
  role = "Developer"
}) {
  return (
    <div>
      <h2>{name}</h2>
      <p>{role}</p>
    </div>
  );
}

If a parent doesn't provide these props, the default values are used.

8. The children Prop

React has a special prop called children.

It represents the content placed between a component's opening and closing tags.

function Card({ children }) {
  return (
    <div className="card">
      {children}
    </div>
  );
}

Usage:

function App() {
  return (
    <Card>
      <h2>User Profile</h2>
      <p>Frontend Developer</p>
      <button>View Profile</button>
    </Card>
  );
}

Everything between <Card> and </Card> becomes the children prop.

This is particularly useful for building reusable layouts, modals, cards, and containers.

9. Props Are Read-Only

This is an important React rule.

A child component should never directly modify its props.

Incorrect:

function UserCard(props) {
  props.name = "Updated Name";

  return <h1>{props.name}</h1>;
}

Props should be treated as immutable.

Why?

Because the parent owns the data it passes to the child.

The child receives that data but doesn't own the original value.

If the data needs to change, the parent should update it and pass the new value down.

We'll see how this works with state.

10. What Is State?

State is data that a component remembers between renders.

Unlike ordinary local variables, state is managed by React.

When state changes, React schedules a new render so the UI can reflect the updated value.

Imagine a counter.

Initially:

Count: 0

After clicking a button:

Count: 1

The displayed value changes.

How does React know that it needs to update the interface?

We use a Hook called useState.

11. Why Do We Need State?

Let's try implementing a counter using a normal variable.

function Counter() {
  let count = 0;

  function increment() {
    count++;

    console.log(count);
  }

  return (
    <div>
      <h1>{count}</h1>

      <button onClick={increment}>
        Increment
      </button>
    </div>
  );
}

Click the button.

The console displays:

1
2
3

But the heading still displays:

Why?

Because changing an ordinary JavaScript variable doesn't tell React to render the component again.

Also, whenever the component renders again, its local variables are initialized again.

We need something that:

Stores data between renders.
Notifies React when that data changes.

That's exactly what state provides.

12. Understanding useState

useState is a React Hook that allows function components to manage state.

import { useState } from "react";

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

  return (
    <div>
      <h1>Count: {count}</h1>

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

Let's break this down.

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

There are three important parts:

1. count

The current state value.

2. setCount

The function used to request a state update.

3. useState(0)

The initial state value.

The initial value is used when React initializes that state.

When the user clicks the button:

setCount(count + 1);

React schedules a state update.

The component renders again using the updated state.

The array destructuring

Why do we write:

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

Because useState returns an array containing two values.

Conceptually:

const result = useState(0);

const count = result[0];
const setCount = result[1];

Array destructuring simply makes this easier to read.

13. How State Updates Work

One of the most important things to understand about React is that state is a snapshot for a particular render.

Consider:

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

  function increment() {
    setCount(count + 1);
  }

  return (
    <button onClick={increment}>
      {count}
    </button>
  );
}

When the component renders with count = 0, the event handler created during that render sees that value.

Calling setCount requests an update.

React then renders the component with the new state.

What happens if we update state multiple times?

Consider:

function incrementThreeTimes() {
  setCount(count + 1);
  setCount(count + 1);
  setCount(count + 1);
}

You might expect the count to increase by three.

But if the current value is 0, all three calls use the same render snapshot.

They effectively request:

setCount(1);
setCount(1);
setCount(1);

The final value is 1, not 3.

The functional updater form

To solve this, use a function that receives the previous state.

function incrementThreeTimes() {
  setCount((previousCount) => previousCount + 1);

  setCount((previousCount) => previousCount + 1);

  setCount((previousCount) => previousCount + 1);
}

Now React processes the updates in sequence.

0 → 1 → 2 → 3

This form is especially useful whenever the next state depends on the previous state.

14. Updating Objects in State

State can contain objects.

const [user, setUser] = useState({
  name: "Hamed",
  age: 25,
});

Suppose we want to update the user's name.

A common beginner mistake is:

user.name = "Sarah";

setUser(user);

This directly mutates the existing object.

React state should be treated as immutable.

Instead, create a new object.

setUser((previousUser) => ({
  ...previousUser,
  name: "Sarah",
}));

Let's understand the spread operator.

{
  ...previousUser,
  name: "Sarah"
}

It copies the existing properties into a new object and replaces the name property.

The resulting object is:

{
  name: "Sarah",
  age: 25
}

The original object remains unchanged.

15. Updating Arrays in State

Arrays should also be treated as immutable.

Consider:

const [items, setItems] = useState([
  "Laptop",
  "Phone"
]);

To add an item:

setItems((previousItems) => [
  ...previousItems,
  "Tablet"
]);

To remove an item:

setItems((previousItems) =>
  previousItems.filter((item) => item !== "Phone")
);

To update an item:

setItems((previousItems) =>
  previousItems.map((item) =>
    item === "Laptop" ? "Gaming Laptop" : item
  )
);

Notice how JavaScript array methods work naturally with React state.

Useful methods include:

Method	Common Use
`map()`	Transform or update items
`filter()`	Remove items
`find()`	Find an item
`slice()`	Create a portion of an array
`concat()`	Create a combined array
Spread syntax	Add or copy items

Avoid methods such as push(), pop(), splice(), and sort() directly on arrays stored in state because they mutate the original array.

If you need sorting, copy the array first:

const sortedItems = [...items].sort();

16. Understanding React Re-rendering

Rendering is the process in which React calls your component to calculate the UI for the current props and state.

A component can render again when:

Its state changes.
Its parent renders again.
Its consumed context value changes.

Consider:

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

  console.log("Counter rendered");

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

Every time the state changes, React renders the component again.

But remember:

A React render does not automatically mean that the browser DOM is completely recreated.

React compares the resulting UI with the previous one and commits the necessary changes.

This distinction is fundamental to understanding React performance.

17. Handling Events

React supports event handling through JSX attributes.

For example:

function App() {
  function handleClick() {
    console.log("Button clicked!");
  }

  return (
    <button onClick={handleClick}>
      Click me
    </button>
  );
}

Notice:

onClick={handleClick}

We pass the function itself.

We don't call it immediately.

Incorrect:

<button onClick={handleClick()}>
  Click me
</button>

This executes the function during rendering.

React event handlers are functions that run in response to user interactions.

Common events include:

Event	Purpose
`onClick`	Mouse click
`onChange`	Input value change
`onSubmit`	Form submission
`onMouseEnter`	Mouse enters an element
`onMouseLeave`	Mouse leaves an element
`onKeyDown`	Keyboard key pressed
`onFocus`	Element receives focus
`onBlur`	Element loses focus

18. Passing Arguments to Event Handlers

Sometimes we need to pass additional data to an event handler.

For example:

function App() {
  function greet(name) {
    console.log(`Hello, ${name}`);
  }

  return (
    <button onClick={() => greet("Hamed")}>
      Greet
    </button>
  );
}

Why use an arrow function?

Because we want to execute greet("Hamed") only when the user clicks.

The arrow function acts as a wrapper.

We can also pass an item's ID:

function deleteUser(userId) {
  console.log("Deleting user:", userId);
}

<button onClick={() => deleteUser(42)}>
  Delete
</button>

19. Event Objects

React event handlers receive an event object.

function App() {
  function handleClick(event) {
    console.log(event);

    console.log(event.target);
  }

  return (
    <button onClick={handleClick}>
      Click me
    </button>
  );
}

The event object contains information about the interaction.

For example:

event.target: The element where the event originated.
event.currentTarget: The element whose handler is currently running.
event.preventDefault(): Prevents the browser's default action.
event.stopPropagation(): Stops the event from propagating further.

Preventing default behavior

Consider a form:

function App() {
  function handleSubmit(event) {
    event.preventDefault();

    console.log("Form submitted!");
  }

  return (
    <form onSubmit={handleSubmit}>
      <button type="submit">
        Submit
      </button>
    </form>
  );
}

Without preventDefault(), the browser normally performs its default form submission behavior.

We prevent that behavior when we want to handle submission ourselves.

20. Conditional Rendering in Practice

Let's combine state and conditional rendering.

import { useState } from "react";

function Login() {
  const [isLoggedIn, setIsLoggedIn] = useState(false);

  return (
    <div>
      {isLoggedIn ? (
        <h1>Welcome back!</h1>
      ) : (
        <h1>Please log in.</h1>
      )}

      <button
        onClick={() => setIsLoggedIn(!isLoggedIn)}
      >
        Toggle Login
      </button>
    </div>
  );
}

Now the interface changes depending on the state.

The button toggles between logged-in and logged-out UI.

A safer updater when the next value depends on the previous one is:

setIsLoggedIn((previousValue) => !previousValue);

21. Rendering Lists with map()

React works naturally with JavaScript arrays.

Suppose we have:

const products = [
  "Laptop",
  "Phone",
  "Tablet"
];

We can render them using map():

function ProductList() {
  const products = [
    "Laptop",
    "Phone",
    "Tablet"
  ];

  return (
    <ul>
      {products.map((product) => (
        <li key={product}>
          {product}
        </li>
      ))}
    </ul>
  );
}

The map() method creates a new array containing React elements.

This is one of the most common patterns in React development.

Rendering objects

Real applications usually work with arrays of objects.

const users = [
  { id: 1, name: "John", role: "Developer" },
  { id: 2, name: "Sarah", role: "Designer" },
  { id: 3, name: "Alex", role: "Manager" }
];

Render them:

function UserList() {
  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>
          <h3>{user.name}</h3>
          <p>{user.role}</p>
        </li>
      ))}
    </ul>
  );
}

22. Understanding Keys

When rendering lists, React needs a way to identify individual items.

That's why we use the key prop.

{users.map((user) => (
  <UserCard
    key={user.id}
    name={user.name}
  />
))}

Keys help React understand:

Which items were added.
Which items were removed.
Which items changed.
Which items stayed the same.

Imagine a list:

Before:
A
B
C

After:
A
X
B
C

Stable keys help React recognize that X was inserted rather than treating every item as a completely different item.

Why not use array indexes?

You might see:

{users.map((user, index) => (
  <UserCard key={index} name={user.name} />
))}

This can cause problems when items are reordered, inserted, or deleted.

For example, React may associate existing component state with the wrong item.

Whenever possible, use stable unique identifiers from your data.

Important: key is not a normal prop

<UserCard key={user.id} name={user.name} />

The key helps React identify the element.

It is not automatically available inside UserCard.

If the component needs the ID, pass it separately:

<UserCard
  key={user.id}
  id={user.id}
  name={user.name}
/>

23. Props vs. State

This is one of the most important distinctions in React.

Both props and state influence what a component displays, but they serve different purposes.

Props	State
Passed from a parent	Managed by a component
Read-only from the child's perspective	Updated through state setters
Used to configure components	Used to remember changing data
Parent controls the value	Component manages its state

Consider:

function UserCard({ name }) {
  const [isOnline, setIsOnline] = useState(false);

  return (
    <div>
      <h2>{name}</h2>

      <p>
        {isOnline ? "Online" : "Offline"}
      </p>

      <button
        onClick={() => setIsOnline((value) => !value)}
      >
        Toggle Status
      </button>
    </div>
  );
}

Here:

name is a prop.
isOnline is state.

The parent decides which user name to pass.

The component manages its own online status.

24. Practical Project: Interactive User Dashboard

Now let's combine everything we've learned.

We'll build a small dashboard containing:

A user list
Dynamic user information
Online/offline status
A delete button
Conditional rendering

Step 1: Create the user data

const initialUsers = [
  {
    id: 1,
    name: "Hamed",
    role: "Frontend Developer",
    isOnline: true
  },
  {
    id: 2,
    name: "Sarah",
    role: "UI Designer",
    isOnline: false
  },
  {
    id: 3,
    name: "Alex",
    role: "Backend Developer",
    isOnline: true
  }
];

Step 2: Create the UserCard component

function UserCard({
  user,
  onDelete,
  onToggleStatus
}) {
  return (
    <div className="user-card">
      <h2>{user.name}</h2>

      <p>{user.role}</p>

      <p>
        Status: {user.isOnline ? "Online" : "Offline"}
      </p>

      <button
        onClick={() => onToggleStatus(user.id)}
      >
        Toggle Status
      </button>

      <button
        onClick={() => onDelete(user.id)}
      >
        Delete User
      </button>
    </div>
  );
}

Notice that the component doesn't directly modify the user.

Instead, it receives callback functions from its parent.

Step 3: Create the Dashboard component

import { useState } from "react";

function Dashboard() {
  const [users, setUsers] = useState(initialUsers);

  function deleteUser(userId) {
    setUsers((previousUsers) =>
      previousUsers.filter(
        (user) => user.id !== userId
      )
    );
  }

  function toggleUserStatus(userId) {
    setUsers((previousUsers) =>
      previousUsers.map((user) =>
        user.id === userId
          ? { ...user, isOnline: !user.isOnline }
          : user
      )
    );
  }

  return (
    <div>
      <h1>User Dashboard</h1>

      <p>Total users: {users.length}</p>

      {users.length === 0 ? (
        <p>No users available.</p>
      ) : (
        users.map((user) => (
          <UserCard
            key={user.id}
            user={user}
            onDelete={deleteUser}
            onToggleStatus={toggleUserStatus}
          />
        ))
      )}
    </div>
  );
}

export default Dashboard;

Step 4: Use Dashboard in App

import Dashboard from "./Dashboard";

function App() {
  return <Dashboard />;
}

export default App;

Congratulations!

You've just built an interactive React application using:

JSX
Components
Props
State
Events
Conditional rendering
Array methods
Keys
Component composition

This is the foundation of many real-world React applications.

25. Common Beginner Mistakes

Mistake 1: Calling an event handler during rendering

Incorrect:

<button onClick={handleClick()}>
  Click
</button>

Correct:

<button onClick={handleClick}>
  Click
</button>

Mistake 2: Mutating state directly

Incorrect:

users.push(newUser);
setUsers(users);

Correct:

setUsers((previousUsers) => [
  ...previousUsers,
  newUser
]);

Mistake 3: Forgetting keys

Incorrect:

users.map((user) => (
  <li>{user.name}</li>
))

Correct:

users.map((user) => (
  <li key={user.id}>{user.name}</li>
))

Mistake 4: Expecting state to update immediately

Incorrect mental model:

setCount(count + 1);

console.log(count);

The log still sees the current render's state snapshot.

Mistake 5: Modifying props

Props should be treated as read-only.

If data needs to change, update the owning state and pass the new value down.

Mistake 6: Using normal variables for UI state

Ordinary variables don't trigger React renders.

Use useState when a value needs to affect the rendered UI.

Mistake 7: Using index as a key everywhere

Indexes are not always stable identifiers.

Prefer unique IDs from your data.

26. What We Learned

In this article, we explored the concepts that make React applications dynamic.

We learned that:

JSX describes UI using JavaScript-friendly syntax.
Props allow parent components to pass data to children.
State allows components to remember changing information.
useState manages state in function components.
State updates schedule new renders.
Event handlers respond to user interactions.
Conditional rendering displays UI based on conditions.
map() renders collections of elements.
Keys help React identify list items.
Immutable updates help React manage state correctly.

Most importantly, we learned how props, state, and events work together.

User Interaction
       ↓
Event Handler
       ↓
State Update
       ↓
React Render
       ↓
Updated UI

This is one of the fundamental patterns you'll use throughout your React career.

27. What's Next?

In Part 3: React Hooks — Complete Practical Guide, we'll explore Hooks in much greater depth.

We'll cover:

What Hooks are and why they exist
Rules of Hooks
useState in depth
useEffect and dependency arrays
Effect cleanup
useRef and DOM references
useContext and Context API
useReducer
useMemo
useCallback
useId
useTransition
useDeferredValue
Custom Hooks
Common Hook mistakes
Practical projects

We'll also explore how React handles component rendering and why understanding Hook behavior is essential for writing reliable applications.

Continue the React Mastery Series

Part 1: React Fundamentals — From Zero to Components

Part 2: JSX, Props, State & Events

Part 3: React Hooks — Complete Practical Guide

Part 4: React Forms & API Integration

Part 5: React Architecture & Best Practices

Part 6: React Performance Optimization

Part 7: React Internals — Virtual DOM, Fiber & Reconciliation

Part 8: Modern React 19 Features

Part 9: Routing & State Management

Part 10: Testing React Applications

If you're learning React, don't just read the examples.

Run them, change them, break them, and try to understand why they behave the way they do.

That's how you move from knowing React syntax to actually understanding React.

Happy coding!

React #JavaScript #FrontendDevelopment #WebDevelopment #ReactJS

React Mastery Series — Part 1: React Fundamentals — From Zero to Components

Hamed Farazi — Tue, 03 Nov 2026 04:41:08 +0000

Welcome to the React Mastery Series!

This series is designed to take you from understanding the fundamentals of React to building modern, maintainable, and production-ready applications.

Whether you're a JavaScript developer exploring React for the first time or someone looking to strengthen your frontend fundamentals, this series will help you understand not only how React works, but also why it works the way it does.

In this first article, we'll focus on the foundations:

What React is
Why React was created
The problems React solves
Declarative vs. imperative programming
Understanding the DOM
Single Page Applications
The component-based architecture
Creating your first React application
Building your first components

Let's get started!

What Is React?
Why Was React Created?
The Problem with Traditional DOM Manipulation
Declarative vs. Imperative Programming
What Is the DOM?
What Is a Single Page Application?
React Is a Library, Not a Framework
The Component-Based Architecture
Understanding React's Rendering Process
Setting Up Your React Environment
Creating Your First React Application
Understanding the Project Structure
Your First React Component
Component Composition
Practical Example: Building a User Profile
Understanding React's Mental Model
Common Beginner Mistakes
What We Learned
What's Next?

1. What Is React?

React is a JavaScript library for building user interfaces.

It was originally developed at Facebook, now Meta, and is used to create interactive web applications.

React allows developers to build interfaces using reusable pieces called components.

Instead of manually updating individual DOM elements whenever something changes, React lets us describe what the UI should look like based on the current data.

Consider a simple website:

<h1>Hello World</h1>

This is straightforward HTML.

Now imagine a dashboard containing:

A navigation bar
A sidebar
A profile section
A list of products
Notifications
Search functionality
Interactive filters

Managing all of these elements manually can become difficult.

React helps us organize the interface into smaller, reusable components.

For example:

function App() {
  return (
    <div>
      <Navbar />
      <Sidebar />
      <Dashboard />
    </div>
  );
}

Each component represents a specific part of the interface.

This makes applications easier to maintain, reuse, and scale.

2. Why Was React Created?

To understand React, we first need to understand the problems developers faced when building complex interfaces.

Imagine you're building an online shopping application.

The interface contains:

A product list
A shopping cart
A total price
A checkout button

When a user adds a product to the cart, several things need to change:

The cart contents update.
The number of items changes.
The total price changes.
The UI reflects the new data.

Using traditional DOM manipulation, you might manually update each element.

const cartCount = document.querySelector(".cart-count");

cartCount.textContent = 3;

This works for simple applications.

However, imagine dozens of components depending on the same data.

Now you must carefully coordinate every DOM update.

This creates several problems:

UI logic becomes scattered.
DOM updates become difficult to maintain.
Bugs become harder to track.
Components become tightly coupled.
Reusing UI logic becomes more complicated.

React provides a different approach.

Instead of manually updating every affected element, you update the application state and describe the UI based on that state.

React handles the necessary rendering work.

3. The Problem with Traditional DOM Manipulation

Let's build a small example using plain JavaScript.

<h1 id="count">0</h1>

<button id="increment">
  Increment
</button>

JavaScript:

const countElement = document.getElementById("count");

const button = document.getElementById("increment");

let count = 0;

button.addEventListener("click", () => {
  count++;

  countElement.textContent = count;
});

This is perfectly valid JavaScript.

But notice what we are doing:

Keeping track of the count manually.
Finding the DOM element.
Listening for an event.
Updating the DOM manually.

For a small example, this is fine.

But imagine an application with hundreds of interactive elements.

You would need to manually synchronize:

Application data
DOM elements
Event handlers
UI states

This is where maintaining consistency becomes difficult.

React changes this approach by making the UI a function of data.

Conceptually:

Application State
        ↓
React Components
        ↓
UI

When the state changes, React determines what needs to be updated.

4. Declarative vs. Imperative Programming

This is one of the most important concepts to understand before learning React.

Imperative Programming

Imperative programming describes how to perform a task.

You provide instructions step by step.

Example:

const heading = document.createElement("h1");

heading.textContent = "Hello React";

document.body.appendChild(heading);

We explicitly tell the browser:

Create an element.
Set its text.
Add it to the document.

Declarative Programming

Declarative programming describes what the result should look like.

function App() {
  return <h1>Hello React</h1>;
}

We describe the desired UI.

React handles the underlying DOM operations.

The difference

Imperative	Declarative
Describes how to do something	Describes what should happen
Requires manual DOM operations	React manages DOM updates
UI logic can become scattered	UI is described through components
Developer coordinates updates	React manages rendering

React's declarative model becomes especially powerful when the UI depends on changing data.

5. What Is the DOM?

DOM stands for Document Object Model.

When a browser loads an HTML document, it creates a structured representation of that document.

For example:

<body>
  <div>
    <h1>Hello</h1>
    <p>Welcome to React</p>
  </div>
</body>

The browser represents this document as a tree.

Conceptually:

Document
  |
  └── html
       |
       └── body
            |
            └── div
                 |
                 ├── h1
                 |
                 └── p

This structure allows JavaScript to interact with the document.

For example:

document.querySelector("h1").textContent = "Updated";

This changes the DOM.

React works with the browser DOM through its rendering system.

You usually don't need to manipulate DOM elements manually when building ordinary React interfaces.

6. What Is a Single Page Application?

A Single Page Application, or SPA, is a web application that typically loads an initial HTML document and then updates its interface dynamically as users interact with it.

Traditional multi-page applications often navigate by requesting a new HTML document from the server.

In a typical SPA:

The browser loads the application.
JavaScript initializes the UI.
User interactions update the interface.
Navigation may happen without a full document reload.

For example:

User opens application
        ↓
Initial HTML loads
        ↓
JavaScript initializes
        ↓
React renders the UI
        ↓
User interacts
        ↓
UI updates

React is commonly used to build SPAs.

However, React is not limited to SPAs.

React can also be used with frameworks such as Next.js that support server rendering and other rendering strategies.

7. React Is a Library, Not a Framework

This distinction is important.

React focuses primarily on building user interfaces.

It provides:

Components
Rendering
State
Hooks
UI composition

But React itself doesn't prescribe a complete solution for every application concern.

For example, React doesn't include a complete built-in routing system.

You may use additional tools:

Requirement	Common Solution
UI	React
Routing	React Router
Server rendering	Next.js or another framework
Client state	React state, Zustand, Redux Toolkit
Server state	TanStack Query
Forms	React Hook Form
Styling	CSS, Tailwind CSS, CSS Modules

You don't need all these tools when starting React.

Learn React fundamentals first.

8. The Component-Based Architecture

Components are the foundation of React.

A component is a reusable piece of UI.

For example, a website might contain:

Application
│
├── Navbar
│
├── Sidebar
│
├── Dashboard
│   ├── Statistics
│   ├── Chart
│   └── RecentActivity
│
└── Footer

Each part can be implemented as a separate component.

This approach is called component-based architecture.

Why components?

Components help us:

Reuse UI
Separate responsibilities
Organize code
Maintain applications
Build complex interfaces from smaller pieces

Imagine building a dashboard without components.

You might end up with one enormous function containing hundreds of lines of JSX.

With components, each section can have its own logic and structure.

A component should have a clear responsibility

For example:

function Navbar() {
  return <nav>Navigation</nav>;
}

function Footer() {
  return <footer>Footer</footer>;
}

function App() {
  return (
    <>
      <Navbar />
      <main>Main content</main>
      <Footer />
    </>
  );
}

This is easier to understand than placing everything inside one component.

9. Understanding React's Rendering Process

At a high level, React applications follow this pattern:

State or Props Change
        ↓
React Renders Components
        ↓
React Determines Necessary Updates
        ↓
React Commits Updates
        ↓
Browser Displays the UI

Let's simplify this.

Imagine a counter displaying:

The user clicks a button.

The state changes to:

React renders the component again using the new state.

React then determines what changes are necessary in the browser DOM.

The important idea is:

You describe the UI. React manages the rendering process.

Rendering a component does not necessarily mean that React changes the DOM.

React may render a component and determine that the resulting DOM is unchanged.

We'll explore rendering and reconciliation in more detail later in this series.

10. Setting Up Your React Environment

Before creating a React application, make sure you have Node.js installed.

Node.js allows JavaScript tools to run outside the browser.

Check your versions:

node -v
npm -v

You should see version numbers.

If Node.js is not installed, download it from the official website:

https://nodejs.org

For modern React development, Vite is a common choice.

Vite provides:

A development server
Fast startup
Hot Module Replacement
Build tooling

11. Creating Your First React Application

Let's create a React project using Vite.

Run:

npm create vite@latest react-mastery

Choose:

Framework: React
Variant: JavaScript

If you want TypeScript, choose the TypeScript variant instead.

Then:

cd react-mastery
npm install
npm run dev

Vite will start a development server.

You can open the local URL displayed in your terminal.

Your application should now be running.

What is Hot Module Replacement?

Hot Module Replacement, or HMR, allows Vite to update parts of your application during development without requiring a complete page reload in many situations.

This makes the development experience faster.

For example, when you change a component, Vite can update the application while preserving certain existing state.

12. Understanding the Project Structure

A typical Vite React project looks like this:

react-mastery/
│
├── public/
│
├── src/
│   ├── assets/
│   ├── App.jsx
│   ├── App.css
│   ├── index.css
│   └── main.jsx
│
├── index.html
├── package.json
└── vite.config.js

Let's understand the important files.

App.jsx

This is usually where the main application component lives.

function App() {
  return <h1>Hello React</h1>;
}

export default App;

main.jsx

This is the entry point that connects React to the browser DOM.

import { StrictMode } from "react";
import { createRoot } from "react-dom/client";

import App from "./App.jsx";

createRoot(document.getElementById("root")).render(
  <StrictMode>
    <App />
  </StrictMode>
);

index.html

Vite provides an HTML document containing a root element.

<div id="root"></div>

React renders the application inside this element.

13. Your First React Component

Let's create a simple component.

function Welcome() {
  return <h1>Welcome to React!</h1>;
}

export default Welcome;

This is a React function component.

Let's break it down.

function Welcome()

We define a JavaScript function named Welcome.

return <h1>Welcome to React!</h1>;

The function returns JSX.

React uses this returned description to render the UI.

Now use the component in App.jsx:

import Welcome from "./Welcome";

function App() {
  return (
    <div>
      <Welcome />
    </div>
  );
}

export default App;

Notice the syntax:

<Welcome />

We use the component like a JSX element.

This is one of the fundamental ideas of React.

14. Component Composition

Component composition means combining smaller components to create larger interfaces.

Let's create three components.

function Header() {
  return <header>My Application</header>;
}

function MainContent() {
  return <main>Welcome to the dashboard</main>;
}

function Footer() {
  return <footer>© 2026 My Application</footer>;
}

Now compose them:

function App() {
  return (
    <>
      <Header />
      <MainContent />
      <Footer />
    </>
  );
}

The final interface is created from smaller components.

This approach makes your code easier to read and maintain.

Why not create one giant component?

A giant component often becomes difficult to:

Understand
Debug
Test
Reuse
Maintain

Breaking it into smaller components improves organization.

However, don't create a component for every single HTML element.

Components should represent meaningful pieces of UI or reusable behavior.

15. Practical Example: Building a User Profile

Let's build a small React application using multiple components.

Step 1: Create the Profile component

function Profile() {
  return (
    <div className="profile">
      <img
        src="https://placehold.co/100"
        alt="User avatar"
      />

      <h2>Hamed Farazi</h2>

      <p>Frontend Developer</p>

      <button>View Profile</button>
    </div>
  );
}

export default Profile;

Step 2: Create the App component

import Profile from "./Profile";

function App() {
  return (
    <div className="app">
      <h1>Team Members</h1>

      <Profile />
    </div>
  );
}

export default App;

The App component uses the Profile component.

Step 3: Reuse the component

function App() {
  return (
    <div className="app">
      <h1>Team Members</h1>

      <Profile />
      <Profile />
      <Profile />
    </div>
  );
}

Now we have three profile cards.

This demonstrates component reuse.

However, all three profiles currently display the same information.

In the next part of this series, we'll learn how to make components dynamic using Props.

16. Understanding React's Mental Model

The most important thing to understand when learning React is its mental model.

React applications are built around a few fundamental ideas:

Components describe the UI

function Greeting() {
  return <h1>Hello</h1>;
}

Props provide inputs

function Greeting({ name }) {
  return <h1>Hello, {name}</h1>;
}

State represents changing data

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

React renders the UI based on these inputs

Conceptually:

Props + State
      ↓
React Component
      ↓
UI

When props or state change, React can render the component again.

This is the core mental model behind React.

Instead of manually updating the interface, you describe how it should look for the current data.

17. Common Beginner Mistakes

Mistake 1: Thinking React is HTML

JSX looks like HTML, but it is JavaScript syntax transformed into JavaScript.

const element = <h1>Hello</h1>;

This isn't ordinary HTML.

Mistake 2: Thinking React automatically makes everything faster

React helps manage UI rendering, but it doesn't guarantee that every application will be faster than manually written JavaScript.

Performance depends on architecture, rendering behavior, and implementation.

Mistake 3: Creating one massive component

Break your UI into meaningful components.

Mistake 4: Learning advanced hooks too early

Don't begin with useMemo, useCallback, or complex state management.

First understand:

Components
Props
State
Events
Rendering

Mistake 5: Memorizing syntax without understanding the mental model

The goal isn't to memorize every React API.

The goal is to understand how React describes and updates interfaces.

18. What We Learned

In this article, we covered the fundamentals of React:

React is a JavaScript library for building UIs.
React uses a declarative programming model.
Components are reusable pieces of UI.
React manages rendering and DOM updates.
JSX allows HTML-like syntax inside JavaScript.
React applications can be built using Vite.
Components can be composed to create larger interfaces.
Props and state will help make components dynamic.

These concepts form the foundation of everything else in React.

19. What's Next?

In Part 2: JSX, Props, State & Events, we'll explore the concepts that make React applications interactive.

We'll cover:

JSX in depth
JavaScript expressions inside JSX
Props and destructuring
Passing data between components
State with useState
State updates
Event handling
Conditional rendering
Rendering lists
Keys
Practical examples

By the end of Part 2, you'll understand how to build dynamic React components instead of static interfaces.

Continue the React Mastery Series

Part 1: React Fundamentals — From Zero to Components

Part 2: JSX, Props, State & Events

Part 3: React Hooks — Complete Practical Guide

Part 4: React Forms & API Integration

Part 5: React Architecture & Best Practices

Part 6: React Performance Optimization

Part 7: React Internals — Virtual DOM, Fiber & Reconciliation

Part 8: Modern React 19 Features

Part 9: Routing & State Management

Part 10: Testing React Applications

If you're learning React, share what you're currently working on in the comments.

Let's build better React applications together.

Happy coding!

React #JavaScript #FrontendDevelopment #WebDevelopment #ReactJS

React Explained: The Complete Guide

Hamed Farazi — Mon, 02 Nov 2026 21:23:37 +0000

React is one of the most widely used libraries for building modern user interfaces.

Whether you're building a small interactive website, a dashboard, an e-commerce application, or a complex web platform, React provides a component-based approach that helps you build reusable, maintainable UI.

But learning React isn't just about memorizing hooks or writing JSX.

To understand React properly, you need to understand how components work, how data flows through an application, how state changes the UI, and how React manages rendering.

In this guide, we'll explore the most important React concepts — from the fundamentals to advanced patterns — using practical examples.

This article is designed as a roadmap and reference for developers learning React.

What Is React?
Why React?
Declarative vs. Imperative Programming
Creating a React Application
Understanding JSX
Components
Props
State
Events
Conditional Rendering
Rendering Lists and Keys
Component Composition
State Management and Data Flow
React Hooks
useState
useEffect
useRef
useContext
useReducer
Custom Hooks
Forms in React
API Requests
React Router
State Management Libraries
React Performance
React Internals
Virtual DOM and Reconciliation
React Fiber
React 19
Server Components
Error Boundaries and Suspense
Testing React Applications
React Best Practices
Common React Mistakes
React Learning Roadmap
Final Thoughts

1. What Is React?

React is a JavaScript library for building user interfaces.

It was developed at Facebook, now Meta, and is maintained by Meta and the React community.

React helps developers build interfaces using small, reusable pieces called components.

Instead of manually manipulating the DOM every time something changes, developers describe what the UI should look like based on the current data.

React then manages updating the interface.

For example, imagine a dashboard containing:

A navigation bar
A sidebar
A user profile
A notification panel
A list of products

Each section can be represented by a separate component.

function App() {
  return (
    <div>
      <Navbar />
      <Sidebar />
      <Dashboard />
    </div>
  );
}

This approach makes applications easier to organize, reuse, and maintain.

2. Why React?

Before React, developers often used JavaScript to manipulate the DOM directly.

const button = document.querySelector("button");

button.addEventListener("click", () => {
  document.querySelector("h1").textContent = "Hello!";
});

This works, but as an application grows, manually managing DOM changes can become difficult.

React introduces a different approach.

Instead of telling the browser exactly how to update the DOM, we describe the UI based on the current state.

function App() {
  const [name, setName] = React.useState("John");

  return (
    <div>
      <h1>Hello, {name}</h1>

      <button onClick={() => setName("Sarah")}>
        Change Name
      </button>
    </div>
  );
}

When the state changes, React updates the relevant UI.

Key advantages

Component-based architecture
Reusable UI
Declarative rendering
Efficient updates
Strong ecosystem
Large developer community
Integration with modern frontend tools

React is a library, not a complete framework by itself. Routing, data fetching strategies, and other application-level features may come from additional libraries or frameworks.

3. Declarative vs. Imperative Programming

This is one of the most important concepts in React.

Imperative programming

Imperative programming describes how to perform a task step by step.

const heading = document.createElement("h1");

heading.textContent = "Hello React";

document.body.appendChild(heading);

We explicitly tell the browser:

Create an element.
Set its text.
Add it to the document.

Declarative programming

Declarative programming describes what the UI should look like.

function App() {
  return <h1>Hello React</h1>;
}

React handles the necessary DOM operations.

The difference becomes especially important when data changes.

With React, you generally update the state and let React determine how the UI should change.

4. Creating a React Application

A common way to start a React project is with Vite.

Vite provides a development server and build tooling for modern frontend applications.

Create a project:

npm create vite@latest my-react-app

Choose React and JavaScript or TypeScript.

Then:

cd my-react-app
npm install
npm run dev

For a React + TypeScript project, choose the TypeScript template.

A typical project structure:

my-react-app/
├── public/
├── src/
│   ├── assets/
│   ├── components/
│   ├── App.tsx
│   ├── main.tsx
│   └── index.css
├── package.json
└── vite.config.ts

The exact structure may vary depending on the template.

What is main.tsx?

This is commonly the entry point of a Vite React application.

import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import App from "./App";

createRoot(document.getElementById("root")!).render(
  <StrictMode>
    <App />
  </StrictMode>
);

React renders the App component inside the root DOM element.

5. Understanding JSX

JSX stands for JavaScript XML.

It allows developers to write HTML-like syntax inside JavaScript.

const element = <h1>Hello React</h1>;

JSX is not HTML, even though it looks similar.

It is transformed into JavaScript by the build system.

JSX expressions

You can use JavaScript expressions inside curly braces.

function App() {
  const name = "John";

  return <h1>Hello, {name}</h1>;
}

Output:

Hello, John

You can also use calculations:

<p>{10 + 20}</p>

JSX rules

Return a single parent element

Incorrect:

return (
  <h1>Hello</h1>
  <p>Welcome</p>
);

Correct:

return (
  <div>
    <h1>Hello</h1>
    <p>Welcome</p>
  </div>
);

Or use a Fragment:

return (
  <>
    <h1>Hello</h1>
    <p>Welcome</p>
  </>
);

Use className instead of class

<div className="container">
  Hello
</div>

Close elements

<img src="/logo.png" alt="Logo" />

<input />

Use camelCase for many JSX attributes

<button onClick={handleClick}>
  Click me
</button>

6. Components

Components are the building blocks of React applications.

A component is usually a JavaScript function that returns React elements.

function Welcome() {
  return <h1>Welcome to React</h1>;
}

Use it inside another component:

function App() {
  return (
    <div>
      <Welcome />
      <Welcome />
    </div>
  );
}

The Welcome component can be reused wherever needed.

Component naming

React component names must start with an uppercase letter.

Correct:

function UserCard() {
  return <h2>User Card</h2>;
}

Incorrect:

function userCard() {
  return <h2>User Card</h2>;
}

React treats lowercase JSX names as HTML elements.

Components should be pure

A component should generally return the same UI for the same inputs.

Avoid changing external values directly during rendering.

function Greeting({ name }) {
  return <h1>Hello, {name}</h1>;
}

React components should not perform side effects during render.

7. Props

Props allow components to receive data from their parent.

Think of props as the inputs of a component.

function UserCard({ name, age }) {
  return (
    <div>
      <h2>{name}</h2>
      <p>Age: {age}</p>
    </div>
  );
}

Usage:

function App() {
  return (
    <UserCard
      name="John"
      age={25}
    />
  );
}

The parent passes data to the child.

Important: Props are read-only

A child component should not directly modify its props.

Instead, the parent controls the data and can pass callback functions when the child needs to request a change.

Props with TypeScript

interface UserCardProps {
  name: string;
  age: number;
}

function UserCard({ name, age }: UserCardProps) {
  return (
    <div>
      <h2>{name}</h2>
      <p>{age}</p>
    </div>
  );
}

TypeScript helps ensure the component receives the correct data.

8. State

State is data that a component remembers between renders.

Unlike ordinary local variables, updating state causes React to render the component again.

import { useState } from "react";

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

  return (
    <div>
      <h1>{count}</h1>

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

Here:

count is the current state value.
setCount updates the state.
0 is the initial value.

Why not use a normal variable?

function Counter() {
  let count = 0;

  function increment() {
    count++;
    console.log(count);
  }

  return <button onClick={increment}>{count}</button>;
}

This variable does not persist correctly across renders and does not tell React to update the UI.

State solves that problem.

State updates

React state is a snapshot for a particular render.

When updating state based on its previous value, use the functional updater form:

setCount((previousCount) => previousCount + 1);

This is especially useful when updates depend on the previous state.

9. Events

React supports event handling using JSX props.

function App() {
  function handleClick() {
    console.log("Button clicked");
  }

  return (
    <button onClick={handleClick}>
      Click me
    </button>
  );
}

Notice that we pass the function:

onClick={handleClick}

We don't execute it during render:

// Incorrect
onClick={handleClick()}

The incorrect version calls the function immediately.

Passing arguments

function App() {
  function greet(name) {
    console.log(`Hello, ${name}`);
  }

  return (
    <button onClick={() => greet("John")}>
      Greet
    </button>
  );
}

Event objects

function App() {
  function handleClick(event) {
    console.log(event.target);
  }

  return (
    <button onClick={handleClick}>
      Click me
    </button>
  );
}

React events provide information about the interaction.

In TypeScript, event handlers can be typed with React event types.

10. Conditional Rendering

React allows you to render different UI depending on a condition.

Using if

function Greeting({ isLoggedIn }) {
  if (isLoggedIn) {
    return <h1>Welcome back!</h1>;
  }

  return <h1>Please log in.</h1>;
}

Using the ternary operator

function Greeting({ isLoggedIn }) {
  return (
    <h1>
      {isLoggedIn ? "Welcome back!" : "Please log in."}
    </h1>
  );
}

Using logical AND

function Notifications({ count }) {
  return (
    <div>
      {count > 0 && <p>You have notifications.</p>}
    </div>
  );
}

Be careful when using && with numbers:

{count && <p>Notifications</p>}

If count is 0, React may render 0.

A safer expression:

{count > 0 && <p>Notifications</p>}

11. Rendering Lists and Keys

React can render arrays of data using JavaScript's map() method.

function App() {
  const users = ["John", "Sarah", "Alex"];

  return (
    <ul>
      {users.map((user) => (
        <li key={user}>
          {user}
        </li>
      ))}
    </ul>
  );
}

Why do keys matter?

Keys help React identify which items changed, were added, or were removed.

Use stable, unique identifiers whenever possible.

const users = [
  { id: 1, name: "John" },
  { id: 2, name: "Sarah" },
];

{users.map((user) => (
  <UserCard
    key={user.id}
    name={user.name}
  />
))}

Avoid using array indexes as keys when the list can be reordered, inserted into, or deleted from.

Keys are not passed to the component as props.

12. Component Composition

Composition means building complex UI by combining smaller components.

Instead of creating one huge component, break the interface into reusable pieces.

function Header() {
  return <header>My Website</header>;
}

function Sidebar() {
  return <aside>Navigation</aside>;
}

function Content() {
  return <main>Main Content</main>;
}

function App() {
  return (
    <>
      <Header />

      <div className="layout">
        <Sidebar />
        <Content />
      </div>
    </>
  );
}

Composition is one of React's most important architectural ideas.

The children prop

function Card({ children }) {
  return (
    <div className="card">
      {children}
    </div>
  );
}

Usage:

<Card>
  <h2>Profile</h2>
  <p>User information</p>
</Card>

This makes components flexible and reusable.

13. State Management and Data Flow

React follows a pattern commonly called one-way data flow.

Data usually flows from parent components to child components through props.

Parent
  ↓ Props
Child
  ↓ Props
Grandchild

When a child needs to request a change, the parent can pass a callback.

function Parent() {
  const [message, setMessage] = useState("Hello");

  return (
    <Child
      message={message}
      onChangeMessage={setMessage}
    />
  );
}

function Child({ message, onChangeMessage }) {
  return (
    <div>
      <p>{message}</p>

      <button onClick={() => onChangeMessage("Updated!")}>
        Update
      </button>
    </div>
  );
}

Lifting state up

When multiple components need the same state, move it to their nearest common parent.

This is called lifting state up.

It helps keep shared data consistent.

14. React Hooks

Hooks allow function components to use React features such as state, context, refs, and effects.

Common hooks include:

Hook	Purpose
`useState`	Local component state
`useEffect`	Synchronization with external systems
`useRef`	Persistent values and DOM references
`useContext`	Access shared context
`useReducer`	Complex state logic
`useMemo`	Cache a calculation
`useCallback`	Cache a function definition
`useId`	Generate IDs for accessibility
`useTransition`	Mark updates as non-blocking
`useDeferredValue`	Defer a non-urgent value
`useSyncExternalStore`	Subscribe to external stores

Rules of Hooks

Hooks must follow specific rules:

Call hooks only at the top level.
Don't call hooks inside conditions or loops.
Call hooks from React components or custom hooks.
Don't call hooks from ordinary JavaScript functions.

Incorrect:

if (isLoggedIn) {
  useState(true);
}

Correct:

const [isLoggedIn, setIsLoggedIn] = useState(false);

Hooks must be called in the same order on every render.

15. useState

useState allows a component to store and update state.

import { useState } from "react";

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

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

Updating objects

State should be treated as immutable.

Incorrect:

user.name = "Sarah";
setUser(user);

Correct:

setUser((previousUser) => ({
  ...previousUser,
  name: "Sarah",
}));

Updating arrays

Incorrect:

items.push(newItem);
setItems(items);

Correct:

setItems((previousItems) => [
  ...previousItems,
  newItem,
]);

React relies on state updates to determine when to render again. Creating new objects and arrays helps make changes detectable.

16. useEffect

useEffect allows a component to synchronize with external systems.

Examples include:

Browser APIs
Subscriptions
Timers
External widgets
Network requests

import { useEffect } from "react";

function Example() {
  useEffect(() => {
    console.log("Effect executed");

    return () => {
      console.log("Cleanup");
    };
  }, []);

  return <p>Hello</p>;
}

The cleanup function runs when the effect needs to clean up, such as before re-running with changed dependencies or when the component unmounts.

Dependency array

useEffect(() => {
  console.log(count);
}, [count]);

This effect synchronizes with the current count value.

Important: Don't use Effects for everything

Effects are not a general-purpose way to calculate values.

For example, avoid:

useEffect(() => {
  setFullName(`${firstName} ${lastName}`);
}, [firstName, lastName]);

Instead, calculate derived data during rendering:

const fullName = `${firstName} ${lastName}`;

If something can be calculated from existing props or state, it usually doesn't need another state variable or effect.

17. useRef

useRef stores a value between renders without causing a re-render when that value changes.

It is commonly used for DOM access.

import { useRef } from "react";

function SearchInput() {
  const inputRef = useRef(null);

  function handleFocus() {
    inputRef.current?.focus();
  }

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

      <button onClick={handleFocus}>
        Focus
      </button>
    </>
  );
}

Unlike state, changing a ref doesn't automatically update the UI.

Use refs when you need to:

Access DOM elements
Store timer IDs
Keep mutable values between renders
Interact with browser APIs

Don't use refs as a replacement for state when the value should affect what the user sees.

18. useContext

Context allows data to be shared across a component tree without passing props through every intermediate component.

It is useful for:

Theme
Authentication information
Locale
Shared application settings

import { createContext, useContext } from "react";

const ThemeContext = createContext("light");

function Button() {
  const theme = useContext(ThemeContext);

  return (
    <button className={theme}>
      Click me
    </button>
  );
}

A provider supplies the value:

function App() {
  return (
    <ThemeContext.Provider value="dark">
      <Button />
    </ThemeContext.Provider>
  );
}

Context can reduce prop drilling, but it doesn't automatically replace every state management solution.

19. useReducer

useReducer is useful when state transitions are more complex.

import { useReducer } from "react";

function reducer(state, action) {
  switch (action.type) {
    case "increment":
      return { count: state.count + 1 };

    case "decrement":
      return { count: state.count - 1 };

    default:
      return state;
  }
}

function Counter() {
  const [state, dispatch] = useReducer(reducer, {
    count: 0,
  });

  return (
    <div>
      <h1>{state.count}</h1>

      <button onClick={() => dispatch({ type: "increment" })}>
        Increment
      </button>
    </div>
  );
}

useReducer separates state transition logic from the component UI.

It can be helpful for:

Complex forms
Multi-step workflows
State with many related actions
State transitions that are easier to describe explicitly

20. Custom Hooks

Custom hooks allow developers to reuse stateful logic.

A custom hook is a function whose name starts with use.

import { useState } from "react";

function useToggle(initialValue = false) {
  const [value, setValue] = useState(initialValue);

  function toggle() {
    setValue((previousValue) => !previousValue);
  }

  return {
    value,
    toggle,
  };
}

Usage:

function App() {
  const { value, toggle } = useToggle();

  return (
    <button onClick={toggle}>
      {value ? "ON" : "OFF"}
    </button>
  );
}

Custom hooks help organize logic and avoid duplication.

They share logic, not automatically the same state instance. Each component calling a custom hook normally gets its own hook state.

21. Forms in React

React forms can be controlled or uncontrolled.

Controlled components

A controlled input receives its value from React state.

import { useState } from "react";

function LoginForm() {
  const [email, setEmail] = useState("");

  return (
    <input
      value={email}
      onChange={(event) => setEmail(event.target.value)}
    />
  );
}

React controls the input value.

Uncontrolled components

An uncontrolled input stores its value in the DOM.

function Form() {
  return (
    <form>
      <input name="email" defaultValue="" />
    </form>
  );
}

Refs or FormData can be used to access the input values.

Controlled components are useful when the UI needs to respond to input changes immediately.

Uncontrolled components can be simpler for certain forms.

22. API Requests

React applications frequently communicate with APIs.

The browser's fetch API can be used to request data.

import { useEffect, useState } from "react";

function Users() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    async function fetchUsers() {
      try {
        const response = await fetch("/api/users");

        if (!response.ok) {
          throw new Error("Failed to fetch users");
        }

        const data = await response.json();

        setUsers(data);
      } catch (error) {
        setError(error.message);
      } finally {
        setLoading(false);
      }
    }

    fetchUsers();
  }, []);

  if (loading) {
    return <p>Loading...</p>;
  }

  if (error) {
    return <p>{error}</p>;
  }

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

A real application should also consider cancellation, stale requests, caching, and error handling.

For more complex server-state management, tools such as TanStack Query can help.

23. React Router

React itself doesn't provide a complete routing system.

React Router is a popular library for handling navigation in React applications.

Install it:

npm install react-router

Example:

import {
  BrowserRouter,
  Routes,
  Route,
  Link,
} from "react-router";

function Home() {
  return <h1>Home Page</h1>;
}

function About() {
  return <h1>About Page</h1>;
}

function App() {
  return (
    <BrowserRouter>
      <nav>
        <Link to="/">Home</Link>
        <Link to="/about">About</Link>
      </nav>

      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
      </Routes>
    </BrowserRouter>
  );
}

Routing allows applications to display different pages based on the URL.

Check the current React Router documentation for the setup appropriate to your chosen version and mode.

24. State Management Libraries

As applications grow, managing state across many components can become difficult.

React provides built-in tools such as:

useState
useReducer
useContext

External libraries can help with more complex use cases.

Redux Toolkit

Redux Toolkit is the recommended modern approach for Redux applications.

It provides:

Centralized state management
Predictable state updates
Developer tools
Reducers and actions
Integration with Redux DevTools

Zustand

Zustand is a lightweight state management library.

It provides a simple store-based API.

TanStack Query

TanStack Query is designed primarily for server state.

It helps with:

Fetching data
Caching
Refetching
Loading states
Error handling
Synchronizing server data

Client state vs. server state

Client state includes:

Theme
Modal visibility
Selected tab
Local form values

Server state includes:

Users fetched from an API
Product lists
Orders
Remote application data

These two categories often require different approaches.

25. React Performance

React applications can become slow when unnecessary work occurs.

However, optimization should be based on actual performance problems rather than assumptions.

React.memo

React.memo can skip re-rendering a component when its props are unchanged.

import { memo } from "react";

const UserCard = memo(function UserCard({ name }) {
  return <h2>{name}</h2>;
});

useMemo

useMemo caches the result of a calculation.

const filteredUsers = useMemo(() => {
  return users.filter((user) =>
    user.name.includes(search)
  );
}, [users, search]);

useCallback

useCallback caches a function definition.

const handleClick = useCallback(() => {
  console.log("Clicked");
}, []);

These tools are useful in specific situations.

They are not required for every component.

Performance guidelines

Keep component responsibilities clear.
Avoid unnecessary state.
Use stable keys.
Avoid expensive calculations during rendering when they become a real bottleneck.
Profile before optimizing.
Consider code splitting for large applications.

React Compiler can also automate certain memoization optimizations in supported configurations. It doesn't eliminate the need to understand component behavior and performance.

26. React Internals

Understanding React internals helps developers reason about performance and rendering.

At a high level, React performs work in stages.

A simplified model:

State or props change
        ↓
React renders components
        ↓
React determines necessary updates
        ↓
React commits updates
        ↓
Browser displays the UI

Rendering means React calls components and calculates what the UI should look like.

The commit phase applies necessary changes to the host environment, such as the browser DOM.

Not every render results in DOM changes.

React may render a component and determine that the resulting DOM is unchanged.

27. Virtual DOM and Reconciliation

The Virtual DOM is a common term used when discussing React.

Conceptually, React creates an in-memory representation of the UI.

When state changes, React calculates the new UI representation and compares it with the previous one.

This process is commonly described as reconciliation.

React determines which updates are necessary and commits them.

Important clarification

The Virtual DOM is not simply a magical faster version of the DOM.

React's performance depends on many factors:

Component structure
Rendering behavior
Reconciliation
Browser DOM operations
Application complexity
Developer implementation

React's main benefit is often its declarative programming model and predictable UI architecture, not a guarantee that every operation will be faster than manual DOM manipulation.

28. React Fiber

Fiber is React's internal reconciliation architecture.

It was introduced to help React organize rendering work more flexibly.

At a high level, Fiber allows React to:

Represent work associated with components
Organize rendering tasks
Prioritize certain updates
Pause and resume work in supported situations
Support concurrent rendering capabilities

Fiber is an implementation detail.

Most React developers don't need to interact with Fiber directly.

However, understanding its purpose helps explain why React can support features such as transitions and interruptible rendering.

29. React 19

React 19 introduced several important features.

Some of the most notable include:

Actions
useActionState
useOptimistic
use
Form Actions
useFormStatus
Improved support for custom elements
Ref as a prop for function components

Actions

Actions help manage asynchronous operations such as form submissions and data mutations.

They can integrate pending states, errors, and optimistic updates.

useActionState

useActionState manages the result and pending status of an action.

import { useActionState } from "react";

async function updateName(previousState, formData) {
  const name = formData.get("name");

  await saveName(name);

  return name;
}

function NameForm() {
  const [name, action, isPending] = useActionState(
    updateName,
    ""
  );

  return (
    <form action={action}>
      <input name="name" />

      <button disabled={isPending}>
        {isPending ? "Saving..." : "Save"}
      </button>

      <p>{name}</p>
    </form>
  );
}

This is a simplified example. A production implementation should also handle validation and errors.

useOptimistic

useOptimistic helps display an optimistic UI update while an asynchronous operation is in progress.

For example, a user may see a comment appear immediately while the server request is still pending.

use

React 19 introduces the use API, which can read resources such as promises or context in supported situations.

When reading a promise, React can suspend rendering until the promise resolves.

These features are particularly relevant to modern React applications and framework integrations.

30. Server Components

React Server Components allow certain components to render on the server.

They can help reduce client-side JavaScript and allow server-side access to resources.

Server Components are different from traditional Client Components.

In frameworks such as Next.js, components may run in different environments.

Server Components

Render on the server.
Can access server-side resources.
Don't use client-only hooks such as useState.
Don't directly handle browser interactions.

Client Components

Support state and event handlers.
Can use browser APIs.
Are interactive in the browser.

In Next.js App Router, a file marked with:

"use client";

creates a Client Component boundary.

This directive is specific to frameworks and environments that support React Server Components.

Important: React Server Components are not the same thing as server-side rendering.

Server-side rendering produces HTML on the server.

Server Components define a component model that can execute on the server and integrate with a framework's rendering and data-loading system.

31. Error Boundaries and Suspense

React provides mechanisms for handling rendering errors and asynchronous UI.

Error Boundaries

Error Boundaries catch certain errors during rendering and display fallback UI.

They can prevent a component failure from crashing the entire interface.

Traditionally, Error Boundaries are implemented using class components or framework/library-specific abstractions.

Suspense

Suspense allows React to display fallback UI while a supported child is waiting.

import { Suspense } from "react";

function App() {
  return (
    <Suspense fallback={<p>Loading...</p>}>
      <SomeComponent />
    </Suspense>
  );
}

Suspense works with supported data-loading integrations and lazy-loaded components.

It does not automatically detect every asynchronous operation in an ordinary component.

32. Testing React Applications

Testing helps ensure components behave correctly.

Common testing tools include:

Vitest
Jest
React Testing Library

Example:

import { render, screen } from "@testing-library/react";
import { describe, expect, it } from "vitest";

function Greeting() {
  return <h1>Hello React</h1>;
}

describe("Greeting", () => {
  it("renders the greeting", () => {
    render(<Greeting />);

    expect(
      screen.getByRole("heading", {
        name: "Hello React",
      })
    ).toBeInTheDocument();
  });
});

React Testing Library encourages testing components from the user's perspective.

Instead of testing internal implementation details, focus on what users can see and interact with.

33. React Best Practices

Keep components focused

A component should have a clear responsibility.

If a component becomes too large, consider extracting smaller components.

Don't mutate props or state

Treat them as immutable.

Use new objects and arrays when updating state.

Use meaningful names

function ProductCard() {}

is clearer than:

function Box() {}

Avoid unnecessary effects

Use effects for synchronization with external systems.

Don't use them for every calculation or state update.

Use stable keys

key={user.id}

is usually better than using the array index.

Avoid unnecessary state

If a value can be calculated from existing state or props, consider calculating it instead.

Keep logic reusable

Extract reusable logic into custom hooks or utility functions when appropriate.

Use TypeScript

TypeScript helps document component contracts and catch mistakes during development.

Don't optimize prematurely

Use React's profiling tools to identify actual bottlenecks.

Follow accessibility practices

Use semantic HTML, accessible labels, keyboard support, and appropriate ARIA attributes when necessary.

34. Common React Mistakes

Mistake 1: Calling a component as a normal function

Incorrect:

UserCard();

Correct:

<UserCard />

React should manage component invocation.

Mistake 2: Mutating state

Incorrect:

items.push(newItem);
setItems(items);

Correct:

setItems((previousItems) => [
  ...previousItems,
  newItem,
]);

Mistake 3: Using state for every value

Not every value belongs in state.

If a value doesn't affect rendering and doesn't need to persist between renders, a normal variable or ref may be more appropriate.

Mistake 4: Using useEffect for derived data

Avoid storing values that can be calculated from existing props or state.

Mistake 5: Ignoring keys

Lists should have stable keys.

Mistake 6: Overusing memoization

useMemo, useCallback, and React.memo are optimization tools, not mandatory syntax.

Mistake 7: Treating React as a complete framework

React focuses on UI.

Production applications may need routing, data management, server rendering, authentication, and other infrastructure.

35. React Learning Roadmap

If you're learning React, here's a practical order.

Phase 1: JavaScript Fundamentals

Before React, understand:

Variables
Functions
Arrow functions
Arrays
Objects
Destructuring
Spread syntax
map
filter
reduce
Modules
Promises
Async/await
Closures
Scope
DOM fundamentals

Phase 2: React Fundamentals

Learn:

JSX
Components
Props
State
Events
Conditional rendering
Lists and keys
Component composition
State lifting

Phase 3: React Hooks

Learn:

useState
useEffect
useRef
useContext
useReducer
Custom hooks

Phase 4: TypeScript

Learn:

Basic types
Objects and arrays
Interfaces and type aliases
Union types
Generics
Component props
Event types
Hook typing

Phase 5: Real-World React

Build projects involving:

API requests
Forms
Routing
Authentication flows
Loading and error states
Responsive UI
Reusable components

Phase 6: Advanced React

Learn:

Performance profiling
Memoization
Suspense
Error boundaries
React internals
React 19 features
Server Components

Phase 7: Ecosystem

Explore:

Next.js
React Router
Redux Toolkit
Zustand
TanStack Query
React Hook Form
Testing Library

36. Final Thoughts

React is more than a library for writing UI components.

It introduces a different way of thinking about application development.

Instead of manually changing the DOM, you describe the interface based on the current state.

Instead of building one massive application component, you compose smaller reusable components.

Instead of manually synchronizing every UI update, you let React manage rendering.

The most important concepts to master are:

Components
Props
State
JSX
Events
Hooks
Component composition
One-way data flow
Rendering
State management
React performance

You don't need to understand every advanced feature before building your first application.

Start with the fundamentals, build projects, make mistakes, and gradually explore the deeper parts of React.

The best way to learn React is not to memorize every hook.

It's to understand why React works the way it does and how to use that knowledge to build real applications.

What's Next?

This guide is the starting point for a deeper React learning journey.

In future articles, we'll explore:

React Components, Props, and State in depth
React Hooks: The Complete Practical Guide
Understanding React Rendering and Reconciliation
React Performance Optimization
React 19: Actions, useOptimistic, and useActionState
Building Production-Ready React Applications
React Architecture and Best Practices

If you're learning React, save this guide as a reference and follow along with the series.

Happy coding!

React #JavaScript #TypeScript #FrontendDevelopment #WebDevelopment