• dependencyinjection@discuss.tchncs.de
    link
    fedilink
    arrow-up
    10
    ·
    2 days ago

    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.

      • Jayjader@jlai.lu
        link
        fedilink
        arrow-up
        3
        ·
        1 day ago

        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?

        • arty@feddit.org
          link
          fedilink
          English
          arrow-up
          3
          ·
          1 day ago

          I guess they still haven’t shipped a better way?

          /* eslint-disable-next-line specific-rule-name */

          Only for multiline comment delimiters

          • Jayjader@jlai.lu
            link
            fedilink
            arrow-up
            4
            ·
            13 hours ago

            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.