Hacker News new | past | comments | ask | show | jobs | submit login

they're a mess. what the react developers really wanted is a DSL[0], but they couldn't sell that as well so they hacked hooks into JS.

The whole things about "rules of hooks" should tip people off that it's sketchy. I mean, have you ever actually thought about how:

    function Component() {
        const [state, setState] = useState(1);

        return <>{state}</>
    }
actually works? How does `useState` know what bit of state to grab? (it's a global store identified by the function you're in, and an index. it's why you can't change the order of hooks nor call them conditionally).

Hooks are literally javascript in the sense that they're functions you can call in javascript, but they don't operate under any of the rules people actually think of when they write javascript. If for any `function x() {}`, `if (condition) { x() }` was a fatal error, people would consider that terrible API design and the function shouldn't need to care whether it's called conditionally.

Sure, react hooks 'compose' better than class components, but they also don't compose *at all* with anyones mental model of how JS works. What they needed was different syntax or a DSL in general (what svelte does is a lot more understandable, imo).

[0]: jsx is a DSL but it's merely one bit of syntax sugar. they needed a hell of a lot more.




I still don't understand what the problem is with class components. They made sense. Now I'm suddenly relying on the behind-the-scenes magic of useState and useEffect.

useEffect in particular really messes up my understanding of the flow. Lots of bits of code that may or may not be executed based on the dependency array, and that means my component function is going to be executed several times, each time just to execute another useEffect. It works, but it's not a programming model I like.


Class components don't scale or compose well. You have a fixed number of lifecycle methods, and each new behavior you add to your component has to be split up across those methods and mixed in with everything else. This means that your components are going to get much harder to debug and maintain as they get larger, and it's very difficult to split out common behavior in a form that's easy to mix in to existing components. That's the advantage of hooks: each hook can be defined by a single function that manages its entire lifecycle in isolation, and can be dropped into any component with a single line.

> that means my component function is going to be executed several times

Who cares? That shouldn't be your concern. All you should think is "this effect will get called every time these values change. Am I okay with that?" React will handle running your component function consistently with the right state, you just have to worry about whether your component is rendering the right thing given that state, and running the right effects. React handles correctness. You don't have to remember "oh whenever I update this state, I have to run this other function to make sure everything is in sync" as with class-based components. Because invariably, another engineer will come along, make some changes, and forget to call that function. Now you have a really tricky bug to find that depends on internal state.

This is why hooks have caught on: you can truly write pure declarative components (most of the time) and not worry about execution order or dependencies at all. The tradeoff is that you have to think very...reactively. It's definitely a different mindset, but it means that there's a whole class of bugs you never have to think about because React handles it.


shouldComponentUpdate() also doesn't exist in the function-based components. Instead there's a few different hacks to get the same effect.


useState is basically a local [observable] variable slot in a closure, but defined at runtime in React. That’s why it cannot be conditional. React is an ugly attempt to pretend you’re in a powerful functional language while it’s javascript and you run its core manually and follow the rules for “…reasons”.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: