| 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. |
> 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/...