feat: add rule 'no-direct-set-state-in-use-effect', closes #628

[Rel1cx]

What kind of change does this PR introduce?

• Bugfix
• Feature
• Docs
• New Binding issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change?

• Yes, and the changes were approved in issue #___
• No

Checklist

• When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
• I have added a convincing reason for adding this feature, if necessary

Other information

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
eslint-react	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 14, 2024 10:36am

[SukkaW]

The rule name is a bit unclear. The rule doesn't forbid any set state in the useEffect, it only forbids set state in the top scope of the useEffect.

Maybe no-direct-set-state-in-use-effect?

[Rel1cx]

The rule name is a bit unclear. The rule doesn't forbid any set state in the useEffect, it only forbids set state in the top scope of the useEffect.

Maybe no-direct-set-state-in-use-effect?

I understand, but that's the format we use in the no-set-state-in-component-did-update rule name (which in eslint-plugin-react is called no-did-update-set-state), and also disables only setState calls in the same scope, I'm following the naming convention that we already have in our projects. We can explain the "directly" bit in the rule description and error messages.

[Rel1cx]

Maybe no-direct-set-state-in-use-effect?

no-direct-set-state-in-use-effect sounds good, I'll consider switching to this.