CohortX
Блог

React: state and passing data, with examples

2 августа 2026 г. · 3 мин чтения · Читать по-русски · Антон Молотило

What state is

Data that belongs to a component and changes over time. Text typed in, whether a list is open, whether data is loading, what the user selected.

The difference from props is simple:

  • Props arrive from above and aren't changed by the component.
  • State lives inside the component and is changed by it.

Declaring it

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

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

Reading that: declare state with an initial value of zero, receive the current value and a function to change it. On change, the component re-renders itself.

The key thing to accept: you cannot change state directly. Only through the setter. Assignment won't work — the library simply won't learn about the change.

Updating from the previous value

A subtlety people trip on: when the new value depends on the old, pass a function.

setCount((prev) => prev + 1);

The reason: updates may be batched, and reading the variable directly sometimes yields a stale value. Through a function you always get the current one.

State with objects and arrays

Here's the main beginner's trap: you must create a new object rather than modify the existing one.

Wrong:

notes.push(newNote);
setNotes(notes);

Right:

setNotes([...notes, newNote]);

The reason: the library compares references. If the reference is unchanged, it concludes nothing changed and doesn't re-render. The person sees stale data and can't work out why.

The same applies to objects: build a new one from the old rather than mutating fields.

Lifting state up

A frequent situation: two sibling components need the same data. A search field and a results list, for instance.

The solution: move the state into their common parent and pass it down — the value to one, the setter to the other.

This is called lifting state up and is the primary technique for organising data. The rule is simple: state lives in the nearest common parent of everyone who needs it.

When there's a lot of state

If data is needed in ten places at varying depths, threading it manually through every level becomes tiring. Then people use the built-in context mechanism or dedicated state libraries.

But don't start there. First learn to manage with ordinary state and lifting: most learning projects don't need more, and the habit of dragging heavy tools into simple problems is a bad one.

Mistakes everyone makes

Mutating state directly. Covered above. The most common.

Storing what could be computed. If a value derives from other data, store the source and compute it at render time. Otherwise it will eventually go out of sync.

Forgetting that state updates aren't instantaneous. Immediately after calling the setter, the variable still holds the old value.

Putting everything in one large state object. Then any change re-renders everything. Split it by meaning.

Checking that you understood

Build a to-do list: adding, marking complete, deleting, filtering by status. All on ordinary state, with no extra libraries.

If it works and nothing goes out of sync, the topic is covered.

Хватит читать — пора делать

На CohortX можно найти команду под пет-проект и получить тот самый опыт, о котором спрашивают на собеседовании.

Похожие статьи