Learning React: 5 Important Principles About Hooks You Have to Know | Hacker News Reader

Learning React: 5 Important Principles About Hooks You Have to Know

code.likeagirl.io

12 pointsamalinovic11 comments

React extended JavaScript syntax with JSX to make it easier to create elements. Why not do the same for hooks?

It's clear that the existing rules are confusing: hooks look like functions but follow special rules, you need to manually manage hook dependencies with crutches like useCallback / useMemo, etc.

Just adding a few keywords like "hook" and "use" could make it clearer and allow the build tool to automatically generate some of the boilerplate like useCallback.

The example in the article might look something like this (leaving out the TypeScript annotations):

  hook boolean(initialValue) {
    use [value, setValue] from hook state(initialValue);
    return [
      value, {
        setFalse: () => setValue(false),
        setTrue:  () => setValue(true),
        toggle:   () => setValue(!value)
      }
    ];
  }

Behind the scenes this would generate a useBoolean() hook that can be called directly from plain JS if needed, just like JSX generates createElement() calls.

At this stage, I think it’s more likely that React will rely on its compiler to support a less annoying but still JavaScript syntax for hooks, signals etc…

But if you’re using a compiler to support a syntax that looks like plain JavaScript but actually has different semantics, that seems objectively worse than adding a few keywords.

IMO that was a major lesson from C++ — it wasn’t all that clever to allow code that looks like C and would pass a C compiler but does something completely else.

The compiler looks like JavaScript and behaves like JavaScript but it’s optimized; to me asking for React to add more random non-JS keywords to their compiler JS syntax is like asking that you add more keywords to C functions to allow you to build with -O3

Correct use of hooks isn’t an optimization, it’s a necessity to make your programs work.

Your position is more like saying:

“Why does C++ need special syntax for initializers? Surely you can just use alloca() to grab a variable-sized blob of bytes from the stack and cast it to whatever types you’re initializing.”

Vue has done this with macros generally focused on reducing boilerplate and improving DX.

The `defineModel` macro from release 3.4[0] is a prime example where a really simple macro completely changes my workflow and makes refactoring complex components a breeze.

[0] https://chrlschn.dev/blog/2024/01/a-conceptual-model-of-stat...

Genuine question... but is the DevEx of modern React actually better than what it was back in ye-olden-days?

I don't use React (I main Vue), so I can't speak authoritatively. But as an outside observer it feels like React gets progressively more and more "mind-bendy" with every passing year, and when I look at some high-complexity React apps my mind nearly explodes with the amount of crazy complexity that needs be managed to keep the things behaving the way they're meant to.

Echoing this, the approach Vue takes is SO much simpler and yet it still manages to accomplish the same end results. With each new release React becomes increasingly reliant on wonky React-specific abstractions that feel more like a sunk-cost fallacy than actually meaningful solutions to building a reactive SPA.

I personally believe a lot of React developers are experiencing the framework equivalent of Stockholm Syndrome. I would encourage any React devs reading this to go look at the Vue composition API and then try to explain why all of these increasingly convoluted abstractions are necessary.

Could you go into detail? To me it seems like the same concepts exist in Vue:

useState -> ref

useEffect -> watchers

useRef -> template-refs

The only difference I see, is that Vue rerenders nothing by default whereas React rerenders everything by default. And I admittedly agree with Vue on this one, but it's not enough to make me give up the superior ecosystem and JSX.

The boilerplate for creating computed's is comparable to setting up useMemo calls. And oh look: the justification for computed is exactly the same as useMemo/useCallback: https://vuejs.org/guide/essentials/computed.html#computed-ca...

All these frameworks are converging into one. Svelte, Vue, React, Solid.

Most of this is solid advice, but I disagree with some of the `useRef` stuff. Refs are an escape hatch for things that can't be modeled with React's existing reactivity features. As a rule of thumb: only use them when interacting with the DOM or the runtime directly (ie stuff such as browser APIs). Don't use them to store callbacks (prefer `useCallback, but in some rare cases it's acceptable to store them in `useState`).

Also, the the counter and the input field example is useless and contrived. And I realise they tried to keep the code simple to illustrate usage, but the author managed to make the example homeopathic. They should come up with a better example (ie the one in the React documentation is pretty good at illustrating why refs are useful).

Reply on news.ycombinator.com