What does lifting state up mean in React?

What does lifting state up mean in React?

• A. Moving state into a child component to manage it there.
• B. Moving state into the closest common ancestor so multiple components can share it.
• C. Replacing state with props entirely.
• D. Removing state from the app.

Answer: (B)

Lifting state up means keeping the shared data in the closest common ancestor of the components that need it, so they can read and update it from one place. This creates a single source of truth for that data and ensures all dependent components stay in sync. In practice, you put the state in the parent component, pass the current value down to children via props, and give the children a way to request changes by calling a function also provided by the parent. When the parent updates the state, all children that rely on it re-render with the new value. Why this is the best fit: when multiple components rely on the same piece of data, placing it in a common ancestor guarantees they all reflect the same state and stay coordinated as changes occur. Why the other ideas don’t fit: putting state in a child would keep it local to that child and wouldn’t be accessible to siblings, defeating shared access. Replacing state with props isn’t possible because props are read-only from the child’s perspective and you still need mutable data and a way to update it. Removing state eliminates the ability to reflect dynamic, user-driven changes in the UI.

Lifting state up means keeping the shared data in the closest common ancestor of the components that need it, so they can read and update it from one place. This creates a single source of truth for that data and ensures all dependent components stay in sync.

In practice, you put the state in the parent component, pass the current value down to children via props, and give the children a way to request changes by calling a function also provided by the parent. When the parent updates the state, all children that rely on it re-render with the new value.

Why this is the best fit: when multiple components rely on the same piece of data, placing it in a common ancestor guarantees they all reflect the same state and stay coordinated as changes occur.

Why the other ideas don’t fit: putting state in a child would keep it local to that child and wouldn’t be accessible to siblings, defeating shared access. Replacing state with props isn’t possible because props are read-only from the child’s perspective and you still need mutable data and a way to update it. Removing state eliminates the ability to reflect dynamic, user-driven changes in the UI.