[feat] New Rule `react-x/no-unnecessary-use-effect`

[Rel1cx]

Describe the problem

A rule for detecting unnecessary useEffect(s) hooks, the successor of react-hooks-extra/no-direct-set-state-in-use-effect inspired by NickvanDyke/eslint-plugin-react-you-might-not-need-an-effect, differs in that the granularity of the error message of the new rule is precisely aligned with each scenario described in https://react.dev/learn/you-might-not-need-an-effect.

Describe the solution you'd like

No response

Alternatives considered

Update the react-hooks-extra/no-direct-set-state-in-use-effect rule to adapt to the new behavior.

Not adopted because the new enforce scope and error messages do not fully compatible with the scope indicated by the rule name. It is a better choice to keep the rule's current behavior and continue focusing on flagging setState, which also enables it to capture more edge cases in this specific scenario. We have already implemented the capture of some very marginal scenarios under this rule.

Additional context

We used the name no-unnecessary-use-effect because we already have a naming convention similar to no-unnecessary-use-memo and no-unnecessary-use-callback

Here are no plans to deprecate react-hooks-extra/no-direct-set-state-in-use-effect. It will continue to be updated and maintained, but the focus will be on setState.

[NickvanDyke]

I have a few more ideas to refine and improve https://github.com/NickvanDyke/eslint-plugin-react-you-might-not-need-an-effect, but then I will look into PRing its functionality!

[Rel1cx]

I just created the template file and put together the setState detection part of the rule, based on no-direct-set-state-in-use-effect. We were able to do this because earlier we turned the main logic of that rule into reusable hooks.

[Rel1cx]

Before going any further, I am to re-evaluate the proposal put forward by NickvanDyke/eslint-plugin-react-you-might-not-need-an-effect#15

[NickvanDyke]

After the discussion in NickvanDyke/eslint-plugin-react-you-might-not-need-an-effect#15, may I ask your motivation to re-implement it in this plugin? If you have different ideas for the rule(s), I'm more than willing to consider and integrate them to save you the duplicative work. Especially given you have more experience writing idiomatic ESLint plugins.

So far I appreciate and agree with all the ideas put forth. I just need the time to catch up with its unexpected growth from an experimental side-project 😄

[Rel1cx]

@NickvanDyke Thanks! The original intention was to find a successor of no-direct-set-state-in-use-effect which can include its inspection.

The context:
We have done similar rules iterations before. Our hooks-extra/ensure-use-memo-has-non-empty-deps and hooks-extra/ensure-use-callback-has-non-empty-deps have been replaced by the newly introduced no-unnecessary-use-memo and no-necessary-use-callback. "Direct setState call" is like an hidden "convergence point" between various cases mentioned on that react doc page. The rule chooses this as an entry point to implement the inspection of (not all but) various cases, which is very feasible at the rule implementation side but it also brings some limitations to the "human interaction" side of the rule. An issue was raised by @karlhorky in #745, which I think is related to this too.

And react-x/no-unnecessary-use-effect or react-you-might-not-need-an-effect/you-might-not-need-an-effect is one of the solutions for that. We are also considering whether building a community-driven version of rules-of-effect or rules-of-react is feasible.