Day 11 of #100DaysOfCode — Understanding State Management in React

#programming #webdev #100daysofcode #react

At this point, I had covered almost every essential React topic: state, hooks, list rendering, conditional rendering, and more. So for Day 11 of my #100DaysOfCode, the goal was to finally introduce myself to state management in React.

At first glance, state management may look like some completely new React topic, but in reality, it's all about how you structure your app and how you handle states across different components. Chances are, if you're building a React app, you’re already using some kind of state management technique, whether you realize it or not.

Let’s take a closer look at the basics.

🧠 What Is State Management in React?

In a React app, you generally deal with two categories of state:

1. Local State

A state that only one component needs, and no other part of the app depends on it.

2. Global State

A state that multiple components or even the entire React app needs.

📌 Example: Todo List App

Suppose you're building a todo list app. The user types into an input to add items.

Instead of creating the search/input state inside App.jsx, it's better to create a dedicated Search.jsx component and use:

const [search, setSearch] = useState("");

This stays as local state, because only the search bar needs it.

But the list of todo items is something the entire app interacts with. So creating:

const [items, setItems] = useState([]);

inside App.jsx makes sense, because it's global state for your app.

🔼 Lifting State (But Not Always Global)

If several components rely on the same piece of state, you move that state into a common parent component and pass it down as props. This is called lifting state up.

But remember:

Lifting state ≠ making it global.
It just means you moved it to the nearest shared parent.

🛒 Example: Shopping Website

In a shopping app, you might have many different states such as search, items, filters, cart, wish list, etc. Structuring these states properly is the core of state management.

Place state where it logically belongs
Keep related logic close to the component that needs it
Avoid unnecessary states in App.jsx
If passing props down multiple layers becomes “too much,” use the Context API to avoid prop drilling

All of this is state management.

📦 External Libraries: Zustand, Redux, Jotai, etc.

External state management libraries like Zustand, Redux, or Jotai exist to solve problems that appear in larger, more complex apps.

Use them when:

The app becomes difficult to manage with just useState or useReducer
Context API becomes messy or too nested (“Context Hell”)
You begin facing performance bottlenecks from unnecessary re-renders

For many apps:

Context + useState is enough.
You don’t need Redux or Zustand unless your app truly needs them.

❓ Should I Care Where I Create State?

For small apps, you don’t need to stress too much.
But it is best practice to separate local and global state properly.

Care about where you create state if:

You find duplicate states
You notice prop drilling
You see confusion about where a state “lives”
Components depend on data they shouldn’t have to know about

❓ Should I Use the Context API?

Use it when:

There is too much prop drilling
Multiple unrelated components need the same global state

If your app doesn’t suffer from this, you don’t need Context.

❓ So If These Techniques Work, Why Use Zustand or Redux?

Honestly?
For many apps, you don’t need external libraries.

But when your React app grows, you may face:

Performance issues
Deeply nested context providers
Re-renders caused by large global states
Difficulty scaling or organizing state logic

That’s when Zustand or Redux becomes helpful.

🎯 Final Thoughts

The idea is not to bloat your React app with Context, Zustand, Redux, React Router, and whatnot. Keep your React app simple first, and only scale the state management system when your app actually demands it.

Day 11 was all about observing how to manage a React app properly, and as it grows.

Happy coding!