Yes. `useState` is essentially the "two way binding" of React at the component level. You may also enforce two way binding via an external state manager, and pass it to your React components via props.

This is the beauty of React, it's reactive style, that essentially means your UI is always bound to your state.

In Backbone, you do not get this for free, as the problem is that two-way binding in Backbone requires manual re-renders (via jQuery) which are direct DOM manipulations. This is expensive, meaning, it is not performant as your DOM grows.

React solves the problem via it's virtual DOM, which keeps an optimized DOM engine in memory, batching expensive updates onto the real DOM.

This means you get the convenience of your UI always representing your state, which means your code can become more declarative (what you want), and less imperative (what you need to do in order to get it). The author calls this "magic," but as somebody who was a Backbone main turned React main, I call this "sanity."

More than batching updates, what it advertised back when React was new, was the virtual dom's diffing with lightweight nodes - it finds what changed in the tree and only alters the heavyweight DOM nodes where necessary to get the end result. At the time it was common to just swap a whole subtree when anything inside it changed, to guarantee you got everything.

They had them from day one.

Class component:

  class Counter extends Component {
    state = { age: 42 };

    handleAgeChange = () => {
      this.setState({ age: this.state.age + 1 });
    };

    render() {
      return (
        <>
          <button onClick={this.handleAgeChange}>Increment age</button>
          <p>You are {this.state.age}.</p>
        </>
      );
    }
  }

Functional component:

  function Counter() {
    const [age, setAge] = useState(42);

    const handleAgeChange = () => setAge(age + 1);

    return (
      <>
        <button onClick={handleAgeChange}>Increment age</button>
        <p>You are {age}.</p>
      </>
    );
  }

You can actually further simplify the functional component by using setState's callback form. You don't always need to do this, but it makes setting state from within a useEffect much safer in that it won't need the current state value in its dependency array.

  const handleAgeChange = setAge((prevAge) => prevAge + 1);

That's wrong, it's calling setAge immediately and not making a callback. You'll get an infinite render loop from that. It should be:

  const handleAgeChange = () => setAge((prevAge) => prevAge + 1);

https://react.dev/reference/react/useState#updating-state-ba...

The callback version is really only needed if there's a risk of setAge being called multiple times between renders and you do actually want all the mutations, vs only wanting it based on what's currently rendered.

Ah this is what I get for trying to write code on my phone. I'm specifically thinking of cases within useEffects, where the state setter is constant between renders but the state itself is not, so you can wind up with an infinite re-render once the state has changed once, unless you check the state inside the useEffect before calling setState.

useState is the built-in way to manage state in React today. There were also similar mechanisms in class components before hooks came along. This is pretty integral to how React works.

People do add state managers to store state outside the component tree, but a lot of components don't need that.