Why You Probably Don't Need Redux (or Zustand) in Modern Next.js Applications

When people start learning React, one of the first libraries they hear about is Redux. After that, they discover Zustand because it is much smaller and easier to use. Many tutorials still introduce one of these libraries very early, making beginners think every React project needs a global state library. That was often true years ago, but modern Next.js has changed how applications are built.

This article explains in simple words what Redux does, why it became popular, what changed in Next.js, and when you should still choose Redux or Zustand. The goal is not to say these libraries are bad. They are excellent tools. The point is that you should only use them when they solve a real problem.

What is State?

State is simply data that can change while your application is running. A user's name after login, whether a sidebar is open, the items inside a shopping cart, the selected theme, and the value inside an input box are all examples of state. React already provides useState and useReducer for managing this kind of data.

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

If only one component needs this value, there is no reason to store it globally.

Why Redux Became So Popular

Before Next.js had Server Components, almost everything happened in the browser. Components fetched data using useEffect, stored responses in Redux, updated reducers, and read the data back using selectors. This created one central place for application data. It also made debugging easier because every update followed the same flow.

The downside was complexity. Beginners had to learn actions, reducers, middleware, dispatch, selectors, immutable updates, and folder structures before building even simple applications.

Why Zustand Became Popular

Zustand removed most of Redux's boilerplate. Instead of writing multiple files, you could create a small store with just a few lines of code. That made it a favorite for many React developers. Even today it is one of the easiest state libraries available.

What Changed in Modern Next.js?

The biggest change is that data can now stay on the server. Server Components run before the page reaches the browser. Instead of downloading JavaScript, making an API request, waiting for loading states, and then rendering the UI, the server can fetch everything first.

export default async function Page() {
 const posts = await getPosts();
 return <Posts posts={posts} />
}

The browser receives HTML that already contains the data. Since the data never lives in the browser as shared state, there is nothing for Redux to manage.

Server Components Explained

Think of a restaurant. Instead of giving customers raw ingredients and asking them to cook, the kitchen prepares the meal before serving it. Server Components work in a similar way. The server prepares the page first. The browser simply displays it. This reduces JavaScript, improves performance, and removes a lot of unnecessary client-side state.

Server Actions Make Data Updates Easier

Saving data also became simpler. Earlier you usually created an API endpoint, dispatched a Redux action, handled loading states, and updated the store. Now you can write a Server Action.

"use server";
export async function saveProfile(formData){
// save to database
}

Your form calls this function directly. After saving, Next.js can refresh the data automatically. Less code means fewer bugs and easier maintenance.

Local State vs Global State

Ask yourself one question before adding Redux or Zustand: "Who needs this data?" If only one component uses it, keep it local with useState. A modal, dropdown, accordion, search input, password visibility toggle, or tab selection rarely needs a global store.

Global state should only be used when many unrelated client components need the same information at the same time.

Use the URL for Filters

Many developers store filters in Redux.

store.filters.category = "laptop"

A better solution is putting filters into the URL:

/products?category=laptop&page=2

Now users can refresh the page, bookmark it, or share it with someone else without losing their current view.

When Zustand Is the Right Choice

Zustand shines in highly interactive applications where many client components constantly share data. Examples include a music player where different components control playback, a whiteboard application, a drag-and-drop page builder, a Kanban board, or a real-time dashboard. These are genuine global state problems.

When Redux Still Makes Sense

Large enterprise applications often have strict architecture rules, many developers, middleware, logging, auditing, and advanced debugging requirements. Redux still excels in these situations because it offers predictable state updates and a mature ecosystem.

Common Beginner Mistakes

• Adding Redux before writing the first component.
• Putting every API response into a global store.
• Using global state for modal visibility.
• Ignoring Server Components and fetching everything on the client.
• Using global state because a tutorial did it.

Simple Decision Guide

If your data comes from a database, fetch it in a Server Component. If only one component needs the data, use useState. If the state belongs in the URL, use search parameters. If many unrelated client components share interactive state, choose Zustand. If you're working on a very large enterprise codebase with complex workflows, Redux is still a solid choice.

Modern Next.js encourages developers to keep data where it naturally belongs instead of storing everything in one global object. This leads to simpler applications, less code, faster performance, and a better learning experience for beginners.