[tshaddox]

> I do not exaggerate when I claim that I find a dozen of hooks-related problems every single week while reviewing code.

I’m curious if the author sees dozens of problems every week in code review due to, say, unexpected null/undefined values, mistyping variable or attribute names, using the wrong number of equal signs, failing to catch errors and handle rejected promises, etc.

[acidbaseextract]

I'll give you my answers to your questions as someone writing production JS/TS. Answering your questions is precisely illustrative of why hooks issues are hard to catch.

unexpected null/undefined values

This is an issue and has led to bugs. Switching to TS and making the compiler flag them fixed it.

mistyping variable or attribute names

Not an issue. Code obviously breaks if you have incorrect names.

using the wrong number of equal signs

This is an issue but causes few bugs. Linting generally catches it, though cute boolean punning still bites us.

failing to catch errors and handle rejected promises, etc.

This is an issue and has led to bugs.

Pretty much anything where there's some implicit details that the compiler or linters can't reason about programmers find a way to get wrong. One thing I like about the hooks linter setup is that what it encourages you to do by default will prevent most bugs, only lead to potential performance issues, unnecessary rerenders, unnecessary refetches.

[bilalq]

>> failing to catch errors and handle rejected promises, etc.

> This is an issue and has led to bugs.

> Pretty much anything where there's some implicit details that the compiler or linters can't reason about programmers find a way to get wrong. One thing I like about the hooks linter setup is that what it encourages you to do by default will prevent most bugs, only lead to potential performance issues, unnecessary rerenders, unnecessary refetches.

This is something that can be mitigated via the no-floating-promises linter rule if you're using TypeScript[0]. For the cases where you actually want to just swallow errors, you can just add a `.catch(noop)`. This makes such situations explicit. You can get even stricter with the no-misued-promises rule[1].

[0]: https://github.com/typescript-eslint/typescript-eslint/blob/...

[1]: https://github.com/typescript-eslint/typescript-eslint/blob/...

[silverhydradev]

Thanks for those references, I've recently been handed an overwhelmingly "JavaScript" project and this'll be a great way to expose some overlooked code paths.

[rileyphone]

> Pretty much anything where there's some implicit details that the compiler or linters can't reason about programmers find a way to get wrong.

touching on an immortal truth!