feat: Disallow a function wrapped in useCallback or a variable wrapped in useMemo yet only used in useEffect and only in one useEffect, closes #1278

[possum-enjoyer]

What kind of change does this PR introduce?

• Bugfix
• Feature
• Docs
• Test
• 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]

@possum-enjoyer is attempting to deploy a commit to the Rel1cx's projects Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
eslint-react	Ready	Preview	Comment	Nov 26, 2025 11:54am

[possum-enjoyer]

I found a problem: currently if the useCallback is double useless (i.e. no dependencies and only inside one useEffect) the rule will show up twice. Should there be a priority?

[Rel1cx]

I found a problem: currently if the useCallback is double useless (i.e. no dependencies and only inside one useEffect) the rule will show up twice. Should there be a priority?

If these two error messages are granular enough to specify a particular "useless" situation, displaying two is reasonable; otherwise, displaying only one is appropriate.

[possum-enjoyer]

I found a problem: currently if the useCallback is double useless (i.e. no dependencies and only inside one useEffect) the rule will show up twice. Should there be a priority?

If these two error messages are granular enough to specify a particular "useless" situation, displaying two is reasonable; otherwise, displaying only one is appropriate.

I would say they are granular enough with a small asterisks that is:
Both error messages showing up can be a good thing for a developer to see that the function be moved outside the component or inside the useEffect. Moving it inside the useEffect may be good for scoping the function with the call but it might be a little bit overwhelming having two error messages at the same time.

[Rel1cx]

I found a problem: currently if the useCallback is double useless (i.e. no dependencies and only inside one useEffect) the rule will show up twice. Should there be a priority?

If these two error messages are granular enough to specify a particular "useless" situation, displaying two is reasonable; otherwise, displaying only one is appropriate.

I would say they are granular enough with a small asterisks that is: Both error messages showing up can be a good thing for a developer to see that the function be moved outside the component or inside the useEffect. Moving it inside the useEffect may be good for scoping the function with the call but it might be a little bit overwhelming having two error messages at the same time.

I found a problem: currently if the useCallback is double useless (i.e. no dependencies and only inside one useEffect) the rule will show up twice. Should there be a priority?

If these two error messages are granular enough to specify a particular "useless" situation, displaying two is reasonable; otherwise, displaying only one is appropriate.

I would say they are granular enough with a small asterisks that is: Both error messages showing up can be a good thing for a developer to see that the function be moved outside the component or inside the useEffect. Moving it inside the useEffect may be good for scoping the function with the call but it might be a little bit overwhelming having two error messages at the same time.

Showing only one message means we're hiding part of the explanation or suggestion for this bad pattern; from this perspective, I prefer to show all error messages.

[Rel1cx]

but it might be a little bit overwhelming having two error messages at the same time.

We also have a solution for this. If users report two error messages too verbose, we can define only one error message and dynamically construct it to best reflect the actual situation without information missing. Similar to the practice in a rule:

eslint-react/packages/plugins/eslint-plugin-react-x/src/rules/no-nested-component-definitions.ts

Lines 130 to 132 in 435e9d1

	suggestion: component.parent.type === T.Property
	? "Move it to the top level or pass it as a prop."
	: "Move it to the top level.",

This approach is more suitable for complex rules.

[Rel1cx]

I think we also need to update the documentation for these two rules to include the newly introduced patterns.

[possum-enjoyer]

I think we also need to update the documentation for these two rules to include the newly introduced patterns.

Yes that's true. Sorry I forgot about this when starting this "addition" it looked smaller and more like an edge case for the rules.
I will add that and look into the construction of a unified error message :)

[possum-enjoyer]

but it might be a little bit overwhelming having two error messages at the same time.

We also have a solution for this. If users report two error messages too verbose, we can define only one error message and dynamically construct it to best reflect the actual situation without information missing. Similar to the practice in a rule:

eslint-react/packages/plugins/eslint-plugin-react-x/src/rules/no-nested-component-definitions.ts

Lines 130 to 132 in 435e9d1

	suggestion: component.parent.type === T.Property
	? "Move it to the top level or pass it as a prop."
	: "Move it to the top level.",

This approach is more suitable for complex rules.

Ok i fixed this but currently i did a different approach where check if the error is reportable, return the report object and report only at specific points where the original error message would not report. So the original error message takes precedence.
I thought this might be clearer than constructing the error message dynamically because both error messages are very different in what they want to convey.

Also the documentation is now updated :)

[Rel1cx]

LGTM.