First of all I apologize. I wrote that late at night and couldn't really get out what I wanted to say down without the frustration but I also really didn't want to miss the opportunity to pick your brain on this. Its rare you get a chance to speak with the people who build these features.

> Consider that reading everything with a cynical mindset might be obscuring the design.

I was concerned about this, I have pretty strong criticisms about redux. Well, actually, I love redux, I hate that flux dictated its design choices and blurred its abstractions which eventually resulted in the mess you now see in "userspace".

> I encourage you to play with it a little bit to get a feel for it.

I plan to, I'm simply still not convinced they're a solution that has a problem to solve.

> Hooks are composable, unlike mixins. That's pretty much their whole point. Hooks are functions so you can pass values between them.

Hooks are composable, yes, well sorta, at the top level, in a certain order, but if I want composable components I cannot use them.

By definition, calling a hook within a function gives it state. Once it has state, that function is no longer pure.

At that point, you may as well just use a class object and instance, at least then you can separate logic from state in a clear language defined way. This is preferable opposed to in amongst a bunch of useThis and useThat callback hell.

But I'm wasn't really arguing they're not composable, they API is a bit meh but its workable. I'm really just saying they don't have a reason to exist in the first place: Why do I need hooks? or why did/do I need mixins? What is the use case they solve when I have a correctly designed composable implementation of react components?

>> If splitting your logic into lifecycle methods was too disjoint there was way more going on in that component than their should have been.

> I don't find this argument convincing.

What is not convincing? Why does logic need to be colocated further than it is unless there is more than one thing happening in the component confusing things.

> I'd love to see your take on abstractions for subscribing to data, form input, or animations that allow similar expressiveness to Hooks. https://medium.com/@drcmda/hooks-in-react-spring-a-tutorial-....

subscribing to data - why would I want my presentation layer to be subscribed to data? The whole reason for binding data into the presentation layer via props is to avoid that proverbial shitshow.

form input - use browser builtins, if they don't work because react broke them then maybe react should fix them? or, you know, you just do what we all do right now - use a stateful react component class.

or animations - this smells like a jquery sales pitch. We don't need marquee, never did and never will. But see above, if it needs state, its a class.

I guess my confusion is stemming from the fact I don't see classes as a problem, or at least, I don't see pure functions as a sole solution. Pure functions solve a lot of problems by ensuring boundaries are correctly drawn and all state flows through props but that data needs to come from somewhere. Dropping state via hooks into things does the same thing redux does right now. Only hooks violate prop boundaries where as redux (correctly) respect them.

Personally, I would just fix redux if you have a problem with it.

> Sorry, I don't know what you mean by that.

"Accurately model component as being in multiple states at the same time for concurrency." - this is just words and needs a lot of context to unpack correctly.

(Important for future React features.) - As a user, I don't know or care about future React features.

Closures can do that because they capture specific props and state. - You know what else captures specific object state? Instances of objects. Call `new`, don't re-invent OO with pure functions.

All of which is besides the point ant still doesn't answer my question: What developer/user problem do hooks solve? Why should I use them as a developer? - opposed to refactoring into composable stateless components.

> I tried to answer your questions the best I could. It seems clear that you don't find Hooks useful. That's cool.

That's not quite correct I can see they solve the problem they set out to in an elegant, if kludgey, way. I'm just not convinced of their need (which still remains unclear and undefined)

Why do I need hooks? You keep falling back on framework or js reasons, these are not good enough reasons for a user to use, want, or even understand your new feature.