Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

eslint react-hooks/rulesOfHooks: add rule to check for non-function return from useEffect #26463

Closed
jlbooker opened this issue Mar 22, 2023 · 7 comments
Labels
Resolution: Stale Automatically closed due to inactivity Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug

Comments

@jlbooker
Copy link

Feature request: Could we add an eslint rule to eslint-plugin-react-hooks to show an error when a non-function value is returned from within a useEffect call?

For the function passed to the useEffect hook, valid return statements are:
return; (no value)
return undefined; (unnecessarily verbose, but still valid)
return () => { [...cleanup function... ] }

Returning anything else will cause the error: Uncaught TypeError: destroy is not a function at runtime.

The dev UX of this isn't great, as it can be hard to find the return statement from the backtrace, even with source maps enabled. Particularly in regards to upgrading to React 18 -- It seems React 17 was more tolerant of incorrect return values, but as I'm upgrading a codebase to React 18, these errors are now coming to light.

React version: 18+

@jlbooker jlbooker added the Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug label Mar 22, 2023
@vkurchatkin
Copy link

This has nothing to do with rules of hooks. What you want is type checking, that is what TypeScript is for

@jlbooker
Copy link
Author

@vkurchatkin Yes, a realize a full and complete solution to this requires a type checking system to fully evaluate the return type. However, it seems there are at least a few cases we could check for with lint rules, and that would handle 95% of the basic cases. For example, I came upon uses return "none"; and return null;, which are clearly not allowed and easily caught by a lint rule. Anything other than a bare return, undefined, or an arrow function is probably an error.

@noahtallen
Copy link

I opened a related issue in the DT repo, for reference: DefinitelyTyped/DefinitelyTyped#65890. Unfortunately, the types as they exist aren't strong enough to prevent crashes.

@noahtallen
Copy link

Looks like it is simply impossible to catch this type of issue with TS, which is suuuper unfortunate.

Honestly, I really wish that React didn't crash here. IMO, it's unlikely that most expect a return value to do anything at all. For example, inline callbacks:

// returns whatever `doSomething` returns, or false, but I wouldn't expect the return value to do anything

useEffect( () => checkSomething && doSomething() );

@maximejen
Copy link

Any update on this issue ?
With React 18 it looks like return undefined; or doing a return ; is also crashing, which was not the case in React 17.
We have a huge code base, and there is no way I can do a regexp that complicated, and a global search of all useEffects is not even an option.

Copy link

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

@github-actions github-actions bot added the Resolution: Stale Automatically closed due to inactivity label Apr 22, 2024
Copy link

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Apr 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Stale Automatically closed due to inactivity Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug
Projects
None yet
Development

No branches or pull requests

4 participants