[ricardobeat]

You're right when it comes to hooks vs classes, that is a major plus. But this is not the aspect I was commenting on, I was specifically addressing the idea of custom hooks as a trivial replacement for Redux:

> One of the problems Redux is used to solve (as a global store) is peace of mind that you won't need to refactor large swathes of component trees to reparent state and callbacks that need to be shared or persisted across different subtrees as new business requirements arise

> Hooks (especially custom hooks, which are just a composition of other hooks packaged together as a single function) make the reparenting/hoisting/anchoring of state and callbacks trivial compared to other mechanisms, providing similar peace of mind that you're not boxing yourself into an inextensible component tree. (This is regardless of context; passing down props isn't a large pain point, and is often misguided to try to solve because it leads to importable components and hidden contracts.)

My earlier example was to show that re-parenting/hoisting when you replace a global store like Redux, with custom hooks using local state, is not straightforward, and unsafe except for very localized components where you shouldn't be using Redux anyway.

So you'll eventually end up doing prop drilling, or resorting to Context, or back to Redux; in the end hooks did not solve those issues as you proposed (other than the increased portability compared to classes, which you already have with redux or context).