[lugg]

Sounds more like a bunch of excuses.

Why do I, a framework user, need hooks?

What problem do they solve for me?

If you can't answer that without talking about what react broke first I don't think we we need whatever you're selling.

Added responses there too.

I feel like hooks are a solution to shit code that just needs a refactor.

This happens a lot in frameworks that try to please everyone all the time. You give people of all experience levels the same feature set. It's no wonder at least half your user base goes out back and shoots themselves in the foot.

If you want to fix this problem you need to remove flexibility. Not give them yet another method to hurt themselves.

I'd start by splitting component concerns. MVC might be a good candidate. React.fragment components tend to smell like fat models. Pure functions basically views and connect code/prop/state mapping looks a lot like controllers.

Fwiw this small UI component thing is originally what the MVC pattern was intended for. The big laravel style classes we have today are a misappropriation of the patterns name onto something that it shouldn't have.

[danabramov]

They give you the ability to reuse stateful logic between components. You’ll need to be more specific about why it’s an “excuse” to you. Lots of people seem to find this ability useful.

[lugg]

They're excuses because none of them involve explaining when, where and how they are useful to a user.

They all basically say "framework needs it" or "we heard you like functions, so now we're getting rid of classes and making everything functions, but you still actually need classes and state and all that stuff so we're shoving state into globally accessible static functions that you have to call in the same order every time or things just won't work."

Like this whole thing is just absurd.

> They give you the ability to reuse stateful logic between components.

Stateful logic a code smell, we do not want this.

Redux actually gets this stuff correct - binding logic and effects to props and state should be done outside of the presentation layer.

I would have just fixed the redux API so people stop shooting themselves in the foot with it.

--- In any case, thanks for your comments, this has given me a lot to think about, I'm now wondering about how to replace useState with a prop named state. I'm also wondering if bi-directional prop mutation would solve all this cleanly - i.e. bind props instead of passing them, I think KnockoutJS did something like this.