3 ms·

The dependency array is a huge footgun. Engineers, experienced and newbie alike, get it wrong all the time (either causing infinite render loops, or skipping ne

The dependency array is a huge footgun. Engineers, experienced and newbie alike, get it wrong all the time (either causing infinite render loops, or skipping necessary re-renders). This affects useCallback and useMemo as well. After a while, I stopped thinking "oh the developers just aren't doing it right" and more "the React team can do better than this." > What API would you prefer? Something more like signals? Yes. Or full tree redraws like Mithril.js did 8 years ago.

paulddraper 3y ago
React does full tree redraws (well, unless you use memo). useEffect is for side-effects.
- toastercat 3y ago
  It does not. Child components will only render when their parent component re-renders or for example, its state changes. Either way, this is different than what I mean with Mithril.js (it does full tree re-renders on event handler calls or when a manual redraw function is called).
- Izkata 3y ago
  Class components have "shouldComponentUpdate()" that avoids this entirely.
tshaddox 3y ago
Or you installed the lint rule once 4 years ago and never had a problem again.
- gyanreyer 3y ago
  Agreed, everyone who complains about dependency arrays almost certainly hasn't used the linting rule. That being said, I'm not sure that an API is well-designed if the only way to use it effectively is by forcing you to even know there is an eslint plugin to begin with, and then once you do know that, that means now you're being forced to add eslint to your project whether you like it or not. And sometimes eslint just stops working for who knows what reason, I have a developer on my team who's constantly dealing with issues where his eslint/prettier setup isn't running correctly.
  - tshaddox 3y ago
    > That being said, I'm not sure that an API is well-designed if the only way to use it effectively is by forcing you to even know there is an eslint plugin to begin with I don't really agree with this except to the extent that, sure, it would be ideal for all APIs and indeed the entire syntax of your programming language to be so well-designed that you don't need any lint rules to catch common mistakes. I'd love it if my static type checker could catch most mistakes like this (although the boundary between linting and static type checking is fuzzy). But in practice, you're almost certainly going to either 1) have a linter or 2) have strong resolve that you will not make any easy mistakes that a linter could catch. And if you're in the second boat, it doesn't make sense to single out this particular easy mistake, given that omitting arguments is always an easy mistake to make in JavaScript.
  - toastercat 3y ago
    > Agreed, everyone who complains about dependency arrays almost certainly hasn't used the linting rule. Which linting rule? > That being said, I'm not sure that an API is well-designed if the only way to use it effectively is by forcing you to even know there is an eslint plugin to begin with, and then once you do know that, that means now you're being forced to add eslint to your project whether you like it or not. And sometimes eslint just stops working for who knows what reason, I have a developer on my team who's constantly dealing with issues where his eslint/prettier setup isn't running correctly. Yes, not to mention eslint is slow with large codebases. Fingers crossed for the Rust(?) rewrite.
    - gyanreyer 3y ago
      The linting plugin is eslint-plugin-react-hooks[0], which enforces React's "rules of hooks"; it can detect when you access a value inside a React hook and will warn you that you should add it to your dependency array. It enforces some other rules here and there but that's the big one worth caring about the most. I would consider it essential for working with React hooks. The only downside is that sometimes, the rule can end up being overly aggressive and tell you to add things which you explicitly don't want in your dependency array, but it's helpful probably 95+% of the time and not hard to opt out of or work around as needed. [0] https://www.npmjs.com/package/eslint-plugin-react-hooks https://www.npmjs.com/package/eslint-plugin-react-hooks
- toastercat 3y ago
  Can you be more specific which linting rule you're talking about for the sake of readers who may be unaware, and perhaps mention how this completely solves this problem? Because 1. a linting rule does not absolve this from being a footgun and 2. if you're talking about 'exhaustive-deps' there are many cases where following the linter here has caused infinite render loops among newbies across multiple teams I've worked with. Also see this highly contentious thread: https://github.com/facebook/create-react-app/issues/6880 https://github.com/facebook/create-react-app/issues/6880
- Jcampuzano2 3y ago
  The number of times I still see people not follow the lint rule even when it is installed, or use things like eslint-disable because its not always intuitive how to get around certain scenarios kind of rules this point moot. In my opinion if people have the rule installed and still feel the need to disable it then it shows there may be an issue with the API itself. This is coming as someone who has written React for a living since before even ES6 classes were supported. I see it relatively often, including in production codebases where people just disable the rule because they don't know how to write the sometimes non-intuitive way to get around it.

paulddraper 3y ago

React does full tree redraws (well, unless you use memo). useEffect is for side-effects.

toastercat 3y ago
It does not. Child components will only render when their parent component re-renders or for example, its state changes. Either way, this is different than what I mean with Mithril.js (it does full tree re-renders on event handler calls or when a manual redraw function is called).
Izkata 3y ago
Class components have "shouldComponentUpdate()" that avoids this entirely.

tshaddox 3y ago

Or you installed the lint rule once 4 years ago and never had a problem again.

gyanreyer 3y ago
Agreed, everyone who complains about dependency arrays almost certainly hasn't used the linting rule. That being said, I'm not sure that an API is well-designed if the only way to use it effectively is by forcing you to even know there is an eslint plugin to begin with, and then once you do know that, that means now you're being forced to add eslint to your project whether you like it or not. And sometimes eslint just stops working for who knows what reason, I have a developer on my team who's constantly dealing with issues where his eslint/prettier setup isn't running correctly.
- tshaddox 3y ago
  > That being said, I'm not sure that an API is well-designed if the only way to use it effectively is by forcing you to even know there is an eslint plugin to begin with I don't really agree with this except to the extent that, sure, it would be ideal for all APIs and indeed the entire syntax of your programming language to be so well-designed that you don't need any lint rules to catch common mistakes. I'd love it if my static type checker could catch most mistakes like this (although the boundary between linting and static type checking is fuzzy). But in practice, you're almost certainly going to either 1) have a linter or 2) have strong resolve that you will not make any easy mistakes that a linter could catch. And if you're in the second boat, it doesn't make sense to single out this particular easy mistake, given that omitting arguments is always an easy mistake to make in JavaScript.
- toastercat 3y ago
  > Agreed, everyone who complains about dependency arrays almost certainly hasn't used the linting rule. Which linting rule? > That being said, I'm not sure that an API is well-designed if the only way to use it effectively is by forcing you to even know there is an eslint plugin to begin with, and then once you do know that, that means now you're being forced to add eslint to your project whether you like it or not. And sometimes eslint just stops working for who knows what reason, I have a developer on my team who's constantly dealing with issues where his eslint/prettier setup isn't running correctly. Yes, not to mention eslint is slow with large codebases. Fingers crossed for the Rust(?) rewrite.
  - gyanreyer 3y ago
    The linting plugin is eslint-plugin-react-hooks[0], which enforces React's "rules of hooks"; it can detect when you access a value inside a React hook and will warn you that you should add it to your dependency array. It enforces some other rules here and there but that's the big one worth caring about the most. I would consider it essential for working with React hooks. The only downside is that sometimes, the rule can end up being overly aggressive and tell you to add things which you explicitly don't want in your dependency array, but it's helpful probably 95+% of the time and not hard to opt out of or work around as needed. [0] https://www.npmjs.com/package/eslint-plugin-react-hooks https://www.npmjs.com/package/eslint-plugin-react-hooks
toastercat 3y ago
Can you be more specific which linting rule you're talking about for the sake of readers who may be unaware, and perhaps mention how this completely solves this problem? Because 1. a linting rule does not absolve this from being a footgun and 2. if you're talking about 'exhaustive-deps' there are many cases where following the linter here has caused infinite render loops among newbies across multiple teams I've worked with. Also see this highly contentious thread: https://github.com/facebook/create-react-app/issues/6880 https://github.com/facebook/create-react-app/issues/6880
Jcampuzano2 3y ago
The number of times I still see people not follow the lint rule even when it is installed, or use things like eslint-disable because its not always intuitive how to get around certain scenarios kind of rules this point moot. In my opinion if people have the rule installed and still feel the need to disable it then it shows there may be an issue with the API itself. This is coming as someone who has written React for a living since before even ES6 classes were supported. I see it relatively often, including in production codebases where people just disable the rule because they don't know how to write the sometimes non-intuitive way to get around it.