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.
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.
/* 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