4 ms·

I think about React vs Backbone from time to time, too, but have drawn different conclusions. Backbone was one of my first "JS frameworks". I thought it was ne

• thedelanyo 1y ago
  Does React have built-in state management?
  • sothatsit 1y ago
    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.
  • maxloh 1y ago
    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> </> ); }
    • ascagnel_ 1y ago
      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);
      • Izkata 1y ago
        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-based-on-the-previous-state 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.
        • ascagnel_ 1y ago
          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.
    • deleted 1y ago
      [deleted]
  • gravity13 1y ago
    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."
    • Izkata 1y ago
      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.
• thomasfromcdnjs 1y ago
  A little nostalgic for me, I wrote a bunch of backbone tutorials back in the day. https://news.ycombinator.com/item?id=3110025 https://news.ycombinator.com/item?id=3110025 https://web.archive.org/web/20111015073638/https://backbonetutorials.com/organizing-backbone-using-modules/?a https://web.archive.org/web/20111015073638/https://backbonet... Other than the lack of imports, 15 years later I don't hate it. Due to LLM's my thinking about coding has changed quite a bit, I'm far more interested in what is the best way a language can be written such that LLM's can most effectively write it. JSX/declarative is seemingly solid. I think the React community from useEffect onwards is starting to get a bit wishy washy, probably not a great way for LLM's to "think". (something about expressiveness, explicitness and parse-ability)
• cluckindan 1y ago
  Marionette took away much of the Backbone boilerplate, though.