3 ms·

React added "hooks" which are basically methods and properties implemented as FIFO queues instead of lookup tables, with terrible syntax that requires you to de

React added "hooks" which are basically methods and properties implemented as FIFO queues instead of lookup tables, with terrible syntax that requires you to declare them inside their constructor (the "functional" component's... well, function). No, I'm not kidding. Unless something's fundamentally changed about the code since release, they even end up attached to an object representing the UI component, by the time the heart of React's runtime code considers them. It's some real Rube-Goldberg shit. I read the code because I read the announcement docs and was like "wait, it looks like they... but no, surely they didn't" but yeah, turns out, they did.

nobleach 4y ago
What's worse, they have interesting "rules" that one really needs to use a linter so their IDE/Text editor gives them friendly reminders. One cannot conditionally call useEffect. One needs to add all dependencies to useEffect's dependency array - BUT that has potential to cause infinite re-renders (especially when using a getter/setter pattern with useState). They encourage DEFINING functions inside of other functions. Years of CS education and practice go right out the window because some popular JS person on Twitter says, "it's fine". When pressed about it, be ready to be hit with, "You don't understand hooks".
- skydhash 4y ago
  I agree with the others. I've started using hooks since they were introduced and I've only hit the re-render issue only a few times, which I promptly fixed as they were caused by carelessness. My strategy is to not use a single useEffect, but multiple ones for each (which reduce greatly the dependencies). Also, avoiding dependency circles between useState and useEffect. I've used class components and I think hooks are much better than the monstrosity that the lifecycle methods would usually become. Also defining functions inside other functions is very much the staple of functional programming.
  - imbnwa 4y ago
    >Also defining functions inside other functions is very much the staple of functional programming. Isn't the difference that JavaScript runtimes don't compile them away unlike functional runtimes?

nobleach 4y ago

What's worse, they have interesting "rules" that one really needs to use a linter so their IDE/Text editor gives them friendly reminders. One cannot conditionally call useEffect. One needs to add all dependencies to useEffect's dependency array - BUT that has potential to cause infinite re-renders (especially when using a getter/setter pattern with useState). They encourage DEFINING functions inside of other functions. Years of CS education and practice go right out the window because some popular JS person on Twitter says, "it's fine". When pressed about it, be ready to be hit with, "You don't understand hooks".

skydhash 4y ago
I agree with the others. I've started using hooks since they were introduced and I've only hit the re-render issue only a few times, which I promptly fixed as they were caused by carelessness. My strategy is to not use a single useEffect, but multiple ones for each (which reduce greatly the dependencies). Also, avoiding dependency circles between useState and useEffect. I've used class components and I think hooks are much better than the monstrosity that the lifecycle methods would usually become. Also defining functions inside other functions is very much the staple of functional programming.
- imbnwa 4y ago
  >Also defining functions inside other functions is very much the staple of functional programming. Isn't the difference that JavaScript runtimes don't compile them away unlike functional runtimes?