React Hooks

A collection of general purpose, side-effect free, hooks that can be used in React apps. It is tested with React and React Native.

This targets React 18 to make it work with Expo 47.

Origin

Originally this was React Hook Tests which is a bunch of hooks I wrote to learn how to use React hooks and have associated jest tests with it and attempt to get a good test coverage.

Explicit linting rules

These are fixable using --fix

• arrow-body-style
• curly
• eqeqeq
• logical-assignment-operators
• multiline-comment-style
• no-floating-decimal
• prefer-arrow-callback since the naming is done automatically by babel
  • https://stackoverflow.com/questions/49306148/why-is-arrow-syntax-preferred-over-function-declaration-for-functional-react-com
  • https://stackoverflow.com/questions/32828698/difference-between-anonymous-function-vs-named-function-as-value-for-an-object-k/32830772#32830772
• prefer-const
• "prefer-numeric-literals": "error",
• "prefer-object-spread": "error",
• "prefer-template": "error",
• "yoda": "error",
• @typescript-eslint/ban-types is ignored becaues React uses {} as the prop type default.

Why lodash?

Instead of Ramda and Rambda? debounce is only implemented in Lodash.

Why npm?

This project used Yarn earlier. However, it has changed to npm again. Reasons:

• Facebook still uses Yarn 1 over Yarn Berry so seems like a contention there.
• Since this this a stand alone project, I'd rather reduce the complexity of the setup. For my monorepo that is using this Yarn works with it.
• npm is installed with NodeJS
• npm has workspace support as well.
• npm has stricter semver checks.

The 2020 article on Yarn 1 vs Yarn 2 vs NPM gives a bit of insights and priorities though my order is slightly different

1. Broad support — needs to work with React Native, Node CLIs, web — anything we do. We work with a number of clients over a range of technologies and having a package manager that can be used for all our JavaScript TypeScript technologies is a must-have
2. Predictability — will install the same packages every time. Having different versions on different machines makes debugging quite difficult
3. Reliability — it’s not flaky nor does it fail randomly. Nothing seems to frustrate developers as fast as flaky tools
4. Speed — lowered the priority because I prefer predictability and reliability over speed.
5. Caching — local installs wherever possible. We all work remotely and so less network traffic/bandwidth is critical
6. Community adoption
7. Cost of change
8. Key value-added features