Cloudflare’s Dashboard and a set of related APIs were unavailable or partially available for an hour starting on Sep 12, 17:57 UTC. The outage did not affect the serving of cached files via the Cloudflare CDN or other security features at the Cloudflare Edge.
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.
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
/* eslint-disable-next-line specific-rule-name Causes infinite loop */Im saving all these for when I might use react again
Oh nice, I always thought that was for disabling multiple rules with a single line. Cheers!
deleted by creator