Neo's Blog

Mastering React State: A Modern Strategy for Cleaner, Faster Apps

As React applications grow, managing state can quickly become a complex challenge. You might find yourself juggling useState, useContext, or even a third-party library, wondering if you're doing it "right."

Inspired by an insightful tweet from Cory House (@housecor), this post dives into a pragmatic state management strategy for modern React development. We'll explore various state types, best practices for structuring your components, and how to avoid common pitfalls, all while keeping performance and maintainability top of mind.

Let's demystify React state management!

1. The Eight Pillars of React State Management

State in a React application isn't just about useState. It comes in many forms, each suited for a specific purpose. Understanding these distinctions is the first step towards a robust state management strategy.

Here's a breakdown of the common state types and when to leverage them:

Method	When to use it	Quick Example
URL	Sharable app location, deep linking, filtering	`yourdomain.com/products?category=electronics&sort=price`
Web Storage	Persist data across sessions (localStorage/sessionStorage)	User preferences, authentication tokens
Local State	Only one component needs the state (e.g., a form input)	`const [inputValue, setInputValue] = useState('')`
Lifted State	A few closely related components need the state	Parent component holds state shared by two sibling inputs
Derived State	State can be calculated from existing state/props	`const fullName =` ${firstName} ${lastName}``
Refs	Direct DOM interaction, non-rendered state	Accessing an input field for focus, managing a timer ID
Context	Global or subtree-specific state (e.g., theme, user info)	`ThemeContext` for light/dark mode throughout an app
Third-Party Library	Complex global state, remote data management	Redux, Zustand, React Query for large-scale data needs

Choosing the right method is crucial. Don't reach for a global solution when local state suffices!

2. Why Prefer Function Components (and Hooks)?

If you're still debating between class and function components, let this settle it: Function components with Hooks are the modern standard for React, and for good reason.

Less Code: Hooks significantly reduce boilerplate compared to class components, leading to cleaner and more readable code.
Simpler Mental Model: Function components are just JavaScript functions. No complex this binding issues or lifecycle methods to memorize.
No this Keyword Headaches: A notorious source of bugs in class components is eliminated. You deal directly with variables and function arguments.
Hooks API: useState, useEffect, useContext, useCallback, useMemo – these powerful primitives allow you to "hook into" React features directly from your function components, making stateful logic reusable and composable.
Functions are the Future of React: The React team is heavily invested in Hooks, and new features and optimizations are often built with them in mind.

3. Normalize State by Deriving on Render

This is a powerful concept for simplifying your state and preventing bugs: Don't store state that can be computed from existing state or props. Instead, derive it during the render cycle.

Why derive?

Avoids Out-of-Sync Bugs: When you store redundant state, you risk one piece of state changing without the other updating, leading to inconsistencies. Deriving ensures consistency.
Simplifies Code: Less state to manage means fewer useState calls and fewer useEffect hooks needed to synchronize data.

Example: Validating a Form

Instead of having a separate isValid state that you update whenever form inputs change, derive isValid directly from your errors object:

import React, { useState } from 'react';

const getErrors = (address) => {
  const errors = {};
  if (!address.street) errors.street = 'Street is required';
  if (!address.city) errors.city = 'City is required';
  // ... more validation logic
  return errors;
};

export default function Checkout() {
  const [address, setAddress] = useState({ street: '', city: '' });
  const [touched, setTouched] = useState({});

  // 🔥 Derived State: Calculated on every render
  const errors = getErrors(address);
  const isValid = Object.keys(errors).length === 0; // Check if no errors exist

  // Instead of:
  // const [isValid, setIsValid] = useState(false); // This would often get out of sync

  return (
    <div>
      {/* Your form inputs */}
      <input
        type="text"
        value={address.street}
        onChange={(e) => setAddress({ ...address, street: e.value })}
        onBlur={() => setTouched({ ...touched, street: true })}
      />
      {touched.street && errors.street && <p>{errors.street}</p>}
      <button disabled={!isValid}>Submit Order</button>
    </div>
  );
}

In this example, isValid is always up-to-date with the current address and errors, without any extra state management.

4. Understanding When React Renders (and How to Optimize)

React components re-render when their props or state change, or when their parent components re-render. Understanding this flow is key to preventing unnecessary work.

A component will re-render if:

Its own state changes: You call setCount(count + 1).
Its props change: A parent component passes a new value for a prop.
Its parent component renders: Even if the component's own props haven't changed, if its parent re-renders, it typically re-renders too.
Context changes: If a component consumes a Context value and that value changes, the component will re-render.

How to skip unnecessary renders (for performance):

React.memo (for function components): Memoizes the component based on its props. It will only re-render if its props shallowly change.

const MyMemoizedComponent = React.memo(({ value }) => {
  console.log('Rendering MyMemoizedComponent');
  return <p>{value}</p>;
});

PureComponent (for class components): Similar to React.memo, it performs a shallow comparison of props and state.
shouldComponentUpdate (for class components): Gives you manual control over when a class component re-renders.

Important Note: Don't reach for React.memo or PureComponent prematurely. React is incredibly fast. Optimize only when you identify a performance bottleneck through measurement. More on this later from Kent C. Dodds!

5. Most State is Remote State: Streamline with Data Fetching Libraries

In modern web applications, a significant portion of your "state" often comes from an API. This is known as remote state. Managing loading, error, caching, and re-fetching logic manually can quickly become tedious and error-prone.

This is where libraries like React Query or SWR shine. They simplify remote state management, offering powerful features out of the box:

✅ Caching: Automatically caches fetched data, so subsequent requests for the same data are instant.
✅ Invalidates & Refetches Stale Data: Intelligently re-fetches data in the background when it's considered stale, keeping your UI fresh.
✅ Dedupes Requests: Prevents multiple identical requests from being sent simultaneously.
✅ Auto Retries: Automatically retries failed requests.
✅ Refetch on Focus/Reconnect: Refreshes data when the user re-focuses the window or regains network connection.

The Result: WAY Less Code & Better UX!

Traditional Manual Fetching (more verbose):

import { useState, useEffect } from "react";

export default function ProductsPage() {
  const [products, setProducts] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchProducts = async () => {
      try {
        const response = await fetch("/api/products");
        if (!response.ok) throw new Error('Network response was not ok.');
        const json = await response.json();
        setProducts(json);
      } catch (err) {
        setError(err);
        console.error("Failed to fetch products:", err);
      } finally {
        setLoading(false);
      }
    };
    fetchProducts();
  }, []); // Empty dependency array means fetch once on mount

  if (loading) return <div>Loading products...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return (
    // JSX to display products
    <ul>
      {products.map(product => <li key={product.id}>{product.name}</li>)}
    </ul>
  );
}

Using React Query (much cleaner):

import React from "react";
import { useQuery } from '@tanstack/react-query'; // Or 'swr'

// Simple fetcher function
const fetchProducts = async () => {
  const response = await fetch("/api/products");
  if (!response.ok) throw new Error('Network response was not ok.');
  return response.json();
};

export default function ProductsPage() {
  const { data: products, isLoading, isError, error } = useQuery({
    queryKey: ['products'], // Unique key for this query
    queryFn: fetchProducts, // The function that fetches the data
  });

  if (isLoading) return <div>Loading products...</div>;
  if (isError) return <div>Error: {error.message}</div>;

  return (
    // JSX to display products
    <ul>
      {products.map(product => <li key={product.id}>{product.name}</li>)}
    </ul>
  );
}

The difference is striking. With React Query, you get robust remote state management with significantly less code and better performance by default.

6. Start Local, Then Lift. Global is a Last Resort. Prop Drilling is No Biggie.

This is a fundamental principle for scalable and maintainable React applications: keep state as localized as possible.

Declare State in the Component that Needs It: If only one component uses a piece of state, define it there.
- Example: A simple counter button: const [count, setCount] = useState(0);
Child Components Need the State? Pass State Down via Props: If a child component needs to display or interact with its parent's state, pass it down as a prop.
- Example: A parent UserCard passing user prop to Avatar child.
Non-Child Components Need It? Lift State to a Common Parent: If two sibling components (or components not directly in a parent-child relationship) need to share state, move that state up to their nearest common ancestor.
- Example: Two sibling components ShoppingCart and TotalDisplay both need access to cartItems. Lift cartItems state to their common parent, CheckoutPage.
Passing Props Getting Annoying (Prop Drilling)? Consider Context or a Third-Party Library: This is the point where developers often panic and jump to Redux. But prop drilling is often no biggie. If your component tree is not excessively deep (say, 3-5 levels), passing props down explicitly makes the data flow very clear. You can trace where the data comes from at a glance.

If you find yourself passing the same prop through many layers of components that don't directly use it, that's when you might consider:
- React Context: For global application state (like theme, current user) that doesn't change frequently and is used by many components across different parts of the tree.
- Third-Party Libraries (e.g., Zustand, Redux, Recoil): For complex, frequently updated global state that requires advanced features like middleware, dev tools, or server-side rendering integration.

7. Wrap Each Context in a Single File

For better organization and maintainability, it's a good practice to encapsulate your React Context setup in a dedicated file. This streamlines usage and provides helpful error messages.

Benefits:

✅ Streamlines Call Sites: All logic related to creating the context, providing it, and consuming it is in one place.
✅ Provides Useful Error: You can add checks to ensure consumers are wrapped by the provider, giving clear errors if misused.
Clear Responsibility: A single file is responsible for a specific piece of global state.

Example Structure (ThemeContext.js):

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

// 1. Create the Context
const ThemeContext = createContext(undefined); // undefined as initial value

// 2. Create a Custom Hook to consume the Context
export function useTheme() {
  const context = useContext(ThemeContext);
  if (context === undefined) {
    throw new Error('useTheme must be used within a ThemeProvider');
  }
  return context;
}

// 3. Create the Provider Component
export function ThemeProvider({ children }) {
  const [theme, setTheme] = useState('light'); // Actual state managed here

  const toggleTheme = () => {
    setTheme(prevTheme => (prevTheme === 'light' ? 'dark' : 'light'));
  };

  const value = { theme, toggleTheme };

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

Usage:

// In your App.js or layout file:
import { ThemeProvider } from './ThemeContext';
function App() {
  return (
    <ThemeProvider>
      {/* Your app components */}
    </ThemeProvider>
  );
}

// In any component that needs the theme:
import { useTheme } from './ThemeContext';
function ThemeButton() {
  const { theme, toggleTheme } = useTheme();
  return <button onClick={toggleTheme}>Toggle {theme} mode</button>;
}

8. Embrace Immutable JS Features: You Don't Need LoDash (for data updates)

When working with state in React, especially objects and arrays, immutability is paramount. You should never directly modify state. Instead, create new copies with the desired changes. This makes state changes predictable, helps React detect changes for rendering, and prevents difficult-to-trace bugs.

Modern JavaScript provides powerful built-in features for handling immutable data, often making external libraries like LoDash, Underscore, or Ramda unnecessary for basic data manipulation.

Handling Immutable Data in JS:

Object.assign() or Spread Syntax ({ ...myObj }) for Objects:

const user = { name: 'Alice', age: 30 };
// Update age:
const updatedUser = { ...user, age: 31 }; // RECOMMENDED
// const updatedUser = Object.assign({}, user, { age: 31 }); // Alternative

Immutable Array Methods: These methods return a new array, leaving the original untouched.
- .map(): Transform each element.
```
const numbers = [1, 2, 3];
const doubled = numbers.map(n => n * 2); // [2, 4, 6]
```
- .filter(): Create a new array with elements that pass a test.
```
const evens = numbers.filter(n => n % 2 === 0); // [2]
```
- .find(): Find the first element that matches (returns element, not new array).
- .some(), .every(): Check if elements satisfy a condition.
- .reduce(): Reduce array to a single value.
- Spread Syntax for Arrays: Adding or removing elements.
```
const fruits = ['apple', 'banana'];
const newFruits = [...fruits, 'orange']; // ['apple', 'banana', 'orange']
const removedFruit = fruits.filter(f => f !== 'apple'); // ['banana']
```

9. You Don't Need a Form Library. You Need a Pattern.

While powerful form libraries exist (like Formik or React Hook Form), for many common scenarios, you can build robust forms using a solid pattern with native React state. This often leads to lighter bundles and more control.

The key is to define what state you need to manage a form effectively:

State Type	State	Description
Store as touched	`touched`	What fields have been interacted with?
Store as status	`submitted`	Has the form submission been attempted?
	`isSubmitting`	Is a form submission currently in progress?
	`isValid`	Is the form currently valid based on rules?
Derive	`errors`	What are the validation errors for each field?
	`dirty`	Has the form changed from its initial state?

By explicitly defining these state concerns and deriving others, you create a clear, maintainable form management pattern.

10. Favor "State Enums" Over Separate Booleans

Managing component states with multiple boolean flags can quickly lead to "impossible states" (e.g., isLoading and isError both being true simultaneously) and hard-to-debug logic.

State Enums are 🔥. By using a single state variable representing the current "status" or "phase" of a component, you enforce valid transitions and prevent conflicting states.

The Problem with Separate Booleans (Risk of Out-of-Sync Bugs) 👎:

const [submitting, setSubmitting] = useState(false); // Is a submission in progress?
const [submitted, setSubmitted] = useState(false);   // Was the form submitted (successfully or with errors)?
const [completed, setCompleted] = useState(false);   // Was the process fully completed successfully?
// Imagine the logic to update these correctly in every scenario!

The Solution: Using a Single Status "Enum" Instead 👍:

const STATUS = {
  IDLE: "IDLE", // Initial state, waiting for user input
  SUBMITTING: "SUBMITTING", // Form data is being sent
  SUBMITTED: "SUBMITTED", // Form submission completed (might have errors)
  COMPLETED: "COMPLETED", // Process finished successfully
  ERROR: "ERROR", // An error occurred during submission
};

const [status, setStatus] = useState(STATUS.IDLE);

// Example usage:
if (status === STATUS.SUBMITTING) {
  return <div>Sending your data...</div>;
} else if (status === STATUS.ERROR) {
  return <div>An error occurred. Please try again.</div>;
}
// ...

This pattern makes your component's flow explicit and less error-prone.

Beyond Simple Enums: Finite State Machines (e.g., XState) For very complex state logic with many possible states and strict transition rules (e.g., a multi-step checkout flow with retries, cancellations, and various error states), you might consider Finite State Machines (FSMs) and libraries like XState.

Key benefits of FSMs over simple state enums:

Enforce State Transitions: You declare how and when your app moves between states, actively protecting against invalid or unexpected transitions.
Visual State Charts: FSMs can be visualized with state charts, providing an incredibly clear diagram of your application's behavior. This makes complex logic much easier to understand and debug.

While simple state enums are often enough, FSMs offer a robust solution for when your state logic becomes truly intricate.

Conclusion: The AHA Principle and Measuring Performance

Building performant and maintainable React applications requires a thoughtful approach to state management. By understanding the different types of state, favoring function components, deriving state, and leveraging modern data fetching libraries, you're well on your way.

However, it's crucial to remember Kent C. Dodds' wisdom regarding abstractions and performance optimizations:

"Every abstraction (and performance optimization) comes at a cost. Apply the AHA Programming principle and wait until the abstraction/optimization is screaming at you before applying it and you'll save yourself from incurring the costs without reaping the benefit."

The AHA (Avoid Hasty Abstractions) Programming principle means not over-engineering or over-optimizing too early.

Specifically, for optimizations like useCallback and useMemo (which you might consider for render optimizations):

Complexity Cost: They add complexity to your code for co-workers to understand.
Error Potential: You could make a mistake in the dependencies array, leading to subtle bugs or unnecessary re-renders.
Potential Performance Degradation: These hooks have their own overhead. If the work they prevent is less than their overhead, you could actually make performance worse.

These costs are perfectly fine to incur if you gain the necessary performance benefits, but it's always best to measure first. Don't optimize based on assumptions. Use browser developer tools (like the React Dev Tools profiler) to identify actual bottlenecks before introducing complexity.

Related reading from the experts:

React FAQ: "Are Hooks slow because of creating functions in render?"
Ryan Florence: React, Inline Functions, and Performance

By combining pragmatic state management techniques with a mindful approach to optimization, you'll build React applications that are both powerful and pleasant to work with.