Comment by AlexErrant

Comment by AlexErrant 10 hours ago

14 replies

View on Hacker News

React DX is hot garbage. Words cannot express how much I LOATHE hook rules. Coming from a Solid JS background, where reactive primitives are just Javascript functions... I groan every single time I run into (yet another) hook rule.

I have to conditionally render empty fragments because React can't handle conditional hooks. It's the stupidest thing ever. "Oh hey let me allocate memory for this hook that will almost certainly never be used except under edge conditions! Sure, React can do conditional components, but conditional hooks are just too much for us!"

nosefurhairdo 6 hours ago

> I groan every single time I run into (yet another) hook rule.

There are only two rules:

1. Only call Hooks at the top level

2. Only call Hooks from React functions

Per https://react.dev/reference/rules/rules-of-hooks

Not sure I understand the conditional beef, perhaps you can give example? I would assume if you want `if condition, useEffect(...)` you could simply replace with `useEffect(() => if condition...)`, no?

Reply View 3 replies
  • AlexErrant 5 hours ago

    Fair. My bitching would've been better expressed as "I groan every single time I attempt to violate a hook rule." Which is a lot, because I'm new to React. It's almost certainly a "skill issue", but hooks are NOT just "JavaScript functions", contrary to React marketing PR.

    My conditional beef: in my app, users can choose between using the built-in mic for speech recognition or a 3rd party service (LiveKit). If the user chooses the built-in mic, I still must allocate memory for LiveKit's services because it's exposed as a hook, even if the user will never use it. This problem compounds - every option that I expose that uses a hook requires that I allocate memory for an option that may never be used. Also TTS - users can choose to use the phone's TTS, or a remote service, etc. Every option I offer, if the library exposes it as a hook (and they virtually always do), if I naively implement the feature, allocates memory for a hook that might never be used.

    Fuck. React. Hooks.

    My workaround is to conditionally render empty fragments. These fragments wrap hooks, which I then inject into the context. This makes it so I can conditionally run hooks. This is why I complained that React can handle conditional components, but not hooks. Concretely: https://pastebin.com/sjc3vXTd I'm using Zustand because god I need a lifecycle outside of React.

    Y'know how people complain about how Async "colors" functions? Hooks are also a type of function coloring. And they don't compose with Async.

    Reply View 2 replies
    • nosefurhairdo 2 hours ago

      You don't have to use their hooks! Looking at your pastebin link, I would probably opt for something like a factory pattern instead: https://pastebin.com/PbnBqX4a

      Just because you're in React land doesn't mean you can't still write regular old js/ts and hook in only when you need it. I imagine you'd do something quite similar in any other framework.

      Reply View 0 replies
    • DangitBobby 4 hours ago

      Yeah, this is a really annoying thing about how hooks work. For whatever reason (I'm sure they have a great reason) React can't do hook state book-keeping correctly without tying it to a function component lifecycle.

      I think you actually can conditionally render a hook but that choice has to last for the entire rendered lifetime of the component. But that doesn't really help you when your user can switch between them.

      Reply View 0 replies
b_e_n_t_o_n 7 hours ago

Hooks are also just JavaScript functions...?

Reply View 7 replies
  • slmjkdbtl 6 hours ago

    Based on how they are run they are completely not just ordinary JavaScript functions, hook era components are also not just JavaScript functions, it's a very complicated system. React calling them "just functions" is untrue, just marketing buzz words, and it leads developers into traps.

    Reply View 3 replies
    • b_e_n_t_o_n 5 hours ago

      Many functions can only be called in a certain context. Calling them "not functions" is misleading imo because it implies those functions are compiled out or something, like `$state()` in Svelte.

      Reply View 2 replies
      • slmjkdbtl 5 hours ago

        Yeah they themselves are functions but how they're called are managed by a complicated system, I think treating them as a separate new concept is less misleading than calling them plain functions

        Reply View 1 reply
        • b_e_n_t_o_n 4 hours ago

          Well they aren't plain functions, they're like lifecycle methods for the component with an implicit `this`. Perhaps that's how they should be described.

          Reply View 0 replies
  • thomasfromcdnjs 7 hours ago

    They kind of are not though, you can't call them out of order and other things which is checked at runtime by the React "engine" and will stop script execution. If they were regular functions you could call them anytime.

    Reply View 2 replies
    • b_e_n_t_o_n 5 hours ago

      Many "regular" functions are context dependent.

      Reply View 1 reply
      • DangitBobby 4 hours ago

        They are context dependent, must execute in the same order every time, and must be called every time the component re-renders (i.e., they do not support conditional calls). They have enough gremlin rules that calling them "just functions" is unhelpful for reasoning about using them.

        Reply View 0 replies
dgfitz 9 hours ago

I read things like this and think “I am so glad I don’t write JavaScript/ web-anything for a living”

Reply View 1 reply