dependencyinjection@discuss.tchncs.de
on 14 Sep 19:46
nextcollapse
This thing is so common too. Even the linter in my IDE will complain about a missing item in the dependency array and I can see immediately that this will cause an infinite loop. Have to disable the linter for that line.
As someone who started using react about 6 months before they introduced hooks, I remember there was a period where people were really complaining about having to manually reason about what went into every single hook dependency list. Eventually the linting rule was published. I distinctly remember appreciating the rule in situations where a variable that used to be a “plain” variable became a useState hook - it caught some existing uses of the variable in hooks that otherwise were unrelated to the code being changed.
I also distinctly remember being disappointed that there was no specific way to annotate code that needed to disable that rule to prevent infinite loops, just a generic // @eslint-ignore… I guess they still haven’t shipped a better way?
I guess that’s a tad better, though if the rule is named react-hooks/exhaustive-deps then we’re still not explaining why we’re disabling it.
What I’m really looking for is something that explicitly tells the programmer/code reader “this blows up into an infinite loop if we respect exhaustive deps, but here we don’t need exhaustive deps for the code to be sound”.
My own, hair-baked proposal: have the linter recognize [foo, baz /*, @causes-infinite-loop bar */] (or something along those lines) as an explicit, programmer-validated escape hatch for not respecting the exhaustive-deps rule.
threaded - newest
This thing is so common too. Even the linter in my IDE will complain about a missing item in the dependency array and I can see immediately that this will cause an infinite loop. Have to disable the linter for that line.
I never understood that part about the default linting rules for react.
As someone who started using react about 6 months before they introduced hooks, I remember there was a period where people were really complaining about having to manually reason about what went into every single hook dependency list. Eventually the linting rule was published. I distinctly remember appreciating the rule in situations where a variable that used to be a “plain” variable became a useState hook - it caught some existing uses of the variable in hooks that otherwise were unrelated to the code being changed.
I also distinctly remember being disappointed that there was no specific way to annotate code that needed to disable that rule to prevent infinite loops, just a generic
// @eslint-ignore… I guess they still haven’t shipped a better way?/* eslint-disable-next-line specific-rule-name */Only for multiline comment delimiters
I guess that’s a tad better, though if the rule is named
react-hooks/exhaustive-depsthen we’re still not explaining why we’re disabling it.What I’m really looking for is something that explicitly tells the programmer/code reader “this blows up into an infinite loop if we respect exhaustive deps, but here we don’t need exhaustive deps for the code to be sound”.
My own, hair-baked proposal: have the linter recognize
[foo, baz /*, @causes-infinite-loop bar */](or something along those lines) as an explicit, programmer-validated escape hatch for not respecting theexhaustive-depsrule.After the rule name you can add a free text explaining the reasons
.
Oh nice, I always thought that was for disabling multiple rules with a single line. Cheers!
Im saving all these for when I might use react again
<img alt="" src="https://lemmy.world/pictrs/image/99d7a738-de1a-4166-be9f-21845ce20cac.gif">