Hacker News Reader

Comment by _bxg1 | Hacker News Reader

This is a very good take. DOM as a function of state has real tradeoffs but also real benefits; state as a function of state just gets out of hand. IMO React Hooks are where React jumped the shark. setState and Redux were already clunky and felt too rooted in unhelpful ideals, but hooks just took the cake.

My company's codebase uses MobX for all state and I highly recommend it. It embraces mutability and imperative code where they make sense: in your actual app state. React is there to do what it's best at: rendering DOM. That's it. Rendering remains functional and real, meaningful state is allowed to be what it is.

View on HN

Glad to see there's a vocal minority who disagree with the way React Hooks are implemented. I raised my objections when it was announced (even got super kind feedback from Dan Abramov himself) - but it was too late, they "jumped the shark", as you put it. I looked up the meaning of the phrase, not sure it's totally suitable for this situation - but I feel that React crossed a threshold with its release.

I started considering alternative view libraries from that point, and continued to resist against using Hooks in my own React-based projects. The thing is, I love how React transformed web development, it's got huge mind share in the community, and there's nothing better out there yet. I just wish it had stayed small and simple, kept other concerns out of it and focused on doing its one thing only.

To add insult to injury it's fairly easy to use hooks wrong - and used wrong they are, which suggests that their learning curve is not as friendly as proponents of this pattern would wish.

Could you share some examples of hooks used wrongly in code?

useCallback used as something else than a provider of callback functions, e.g. for rendering.

Example:

  const renderItem = useCallback(() => <Item />, []);

And then:

  return renderItem();

What should have been used here is useMemo.

Reply on news.ycombinator.com