[rhaway84773]

But it does reflect so much that’s wrong with the React development.

Creating a first class hook whose only purpose is to wrap another first class hook, all so you can pass in a function rather than a function that returns a function.

[jsunderland323]

I hear what you’re saying. I think in the abstract it seems like an unnecessary helper function. But in a historical context it makes sense.

About a year before hooks was introduced it was discovered by multiple teams that inline anonymous JSX functions could create big performance issues. This was particularly felt in react native development. The solution back then was to do the whole .bind(this) to your callback methods in your react classes.

Because of this (my guess) is the react team wanted to make it extremely obvious how you could use closure state as opposed to private method callbacks when they went intro hooks, without teams having to worry about taking a performance penalty with inline callbacks. It was not obvious to me (and I’m sure many others) when hooks came out that you could memoize functions before rendering.

Again, I get the redundancy point and maybe at this point it could be deprecated but I think you have to think about where the community was before hooks.

[WorldMaker]

Memoization is saving things in memory, it's a tradeoff of memory for fewer function calls. It doesn't work with all possible callback functions (because they need to be pure based on their inputs and dependencies for the saved values to still make sense), and also you don't always want to spend the memory on it (some smart memory use is going to be more performant than the function calls, too much memory use is its own performance problem).

The two hooks have different names because they make different trade-offs.