What is state? (why your app remembers, and why it forgets)

What it actually is

State is everything your app remembers right now, while it is running. Who is logged in and what is sitting in the cart. Which tab is selected, the half-typed text in the search box. Each of those lives in a variable in memory while the page runs, and together those variables are the app’s state.

The screen you see is drawn from state. When you click “add to cart”, the code updates the cart state, and the UI redraws itself from the new value. Every modern frontend works on that loop: change the state, and the components that read it re-render. When the screen looks wrong, the first question a developer asks is whether the state is wrong or whether the redraw never happened.

Think of it as a whiteboard versus a filing cabinet. In-memory state is the whiteboard in a meeting room: quick to write on, wiped clean when the meeting ends. A database or browser storage is the filing cabinet down the hall: slower to reach, but the notes are still there tomorrow. Refreshing the page ends the meeting, and anything you never filed is gone.

Why your AI just did this

Your agent starts talking about state the moment a page has to react to the user. “I’ll add a state variable to track whether the modal is open” and, in React code, a call to useState mean the same thing: this component now remembers something, and the framework redraws it whenever that something changes.

State also shows up in the agent’s explanations of bugs. When you report “the count on screen didn’t change”, a common answer is stale state: the real value changed, but the screen was drawn from an old copy that nobody refreshed. And once several parts of the page need the same information (a cart badge in the header, the cart page, the checkout button), the agent may propose adding state management, a central store that every component reads from, using a library like Redux or Zustand. That is a reasonable move in a large app and overkill in a small one, so ask what problem it solves before accepting it.

When you’ll run into it

The refresh test finds most state problems. You refresh the page and you are logged out, or the cart you filled is empty. Nothing crashed. The page rebuilt itself from scratch, and everything that lived only in memory was wiped. Data survives a refresh only if it was saved somewhere first: a database on the server, or browser storage like localStorage and cookies on your machine.

“It didn’t update” is the other classic. You add an item and the badge still says 0 until you reload. The update reached the database or another component, but the component on screen kept its stale copy. The seam between frontend and backend makes this common: the frontend keeps its own in-memory copy of server data, and that copy can drift.

You may also meet state in a crash. React’s error Too many re-renders. React limits the number of renders to prevent an infinite loop. means a state update is firing during every redraw, which triggers another redraw, forever. Your agent can usually fix it once you paste the exact message.

What to check

• Ask where each piece of information lives: memory only, browser storage, or the database. Anything that must survive a refresh belongs in the last two.
• Refresh the page in the middle of a flow before you ship it. Whatever disappears was in memory only.
• Pin down which side is stale when data looks wrong: check the database or API response first, then the screen. If the stored value is right, the frontend state is the problem.
• Ask your agent to persist state that matters: the login session in a cookie, the cart in the database.
• Question any new state management library on a small app. Built-in component state often does the job with less code to maintain.

Say it like a dev

Instead of: “the page forgets my login when I refresh” Say: “the auth state only lives in memory. Can you persist the session so it survives a refresh?”

Instead of: “the number on screen is wrong until I reload” Say: “the cart badge is showing stale state. Can you make it re-render when the cart changes instead of only on page load?”

Instead of: “save the cart somewhere” Say: “the cart is frontend state right now. Persist it to the database so it survives refresh and follows the user across devices.”