Bug: rules-of-hooks should support hooks inside top-level IIFEs

React version: v16.13.1 eslint-plugin-react-hooks version: v3.0.0

Steps To Reproduce

1. Write something like this:

const Component = () => {
  (() => {
    useState ();
  })()
};

1. Run the rules-of-hooks linter rules on it.

The current behavior

Those linter rules will complain that the useState hook is being called inside a callback.

The expected behavior

Those linter rules should be a little smarter and ignore this kind of top-level IIFE “callback”, since if I’m understanding things correctly it’s completely safe to call hooks this way.

This is a bit of an edge case, but I’m wrapping some hook calls in an IIFE because I don’t want to be able to access the values they return directly, as they may not be the most up to date, rather than via the accessor my IIFE returns.

[gaearon]

This particular case is a rather exotic pattern and in my opinion isn’t worth adding complexity to the (already complex) rule implementation.

As an alternative with similar scoping “benefits”, you can use a block.

const Component = () => {
  let stuff;
  {
    useState();
    stuff = ...
  }
};

[iambryanhaney]

@wereHamster The above example could compose decently with expression chaining…

const categoryId = (GQL.useCategoriesQuery()[0].data?.categories ?? [])
   .find((x) => x.name === nameToCategory(name))?.id

If you need more complexity in a self-contained block, you could mimic the do expression proposal with your named IIFE…

const categoryId = (function Do() {
  const [res] = GQL.useCategoriesQuery()
  const options = res.data?.categories ?? []
  return options.find((x) => x.name === nameToCategory(name))?.id
})() 

I don’t feel like that’s any clunkier than an anonymous IIFE; it’s arguably more self-descriptive.