[danabramov]

>Isn't this the same company that wouldn't hire the homebrew author?

I think you’re confusing it with Google.

>I get the sense the only UI people who really know programming work on the React team

I haven’t worked in many companies before, but I find my colleagues across the company to be very good UI engineers. Not sure where you got that impression.

>I'm a bit dumbfounded about the "this" and "class" confusion concern as well

In the grand scheme of things it’s a pretty minor concern (although people do tend to overfocus on it because it’s easiest to explain and discuss).

The motivation for Hooks is:

* Share reusable stateful and effectful logic between components. Like mixins but without name clashes or the diamond problem. Hooks can be applied more than once, and are instantiated per call.

* Colocate related logic instead of artificially splitting it into lifecycle methods.

* Accurately model component as being in multiple states at the same time for concurrency. (Important for future React features.) Closures can do that because they capture specific props and state.

Finally there are some difficulties related to optimizing class code at compilation time. Such as inlining and fusing classes together. Functions make this simpler and they also minify better due to safer mangling.

All of these motivations can be challenging to explain. So people tend to overfocus on “this”.

I also wrote this, let me know if it helps: https://medium.com/@dan_abramov/making-sense-of-react-hooks-...

[Rapzid]

> I think you’re confusing it with Google.

Indeed!

> All of these motivations can be challenging to explain. So people tend to overfocus on “this”.

> I haven’t worked in many companies before, but I find my colleagues across the company to be very good UI engineers. Not sure where you got that impression.

It has its own section on the Introducing Hooks page :) https://reactjs.org/docs/hooks-intro.html#classes-confuse-bo... .

I can't recall if I've seen it brought up in other "official" channels, but it does certainly get talked about a lot in discussions such as this and I believe that's because of information sources such as the link. I will defer to you on the real situation, but I think hearing about classes and "this" being confusing, coming from React, is where people might wonder what's going on. Mentioning it at all may have caused a large distraction as people latch onto it as you say, and find the situation a bit incredulous.

[danabramov]

It is unfortunately the only point that we can clearly explain to beginners, designers, and other people who aren’t deeply familiar with programming principles. We still care about them and want to emphasize we’re not ignoring them with some new paradigm. When you have such a vast audience as React does, someone will get upset anyway.

[lugg]

> * Share reusable stateful and effectful logic between components. Like mixins but without name clashes or the diamond problem. Hooks can be applied more than once, and are instantiated per call.

In the mixins are considered harmful blog the point is made that sharing logic between components is a mistake and you should be using composition to achieve the desired outcome. Why do I need hooks? Is composition considered harmful now?

> * Colocate related logic instead of artificially splitting it into lifecycle methods.

Nope, all this did was make a mess. If splitting your logic into lifecycle methods was too disjoint there was way more going on in that component than their should have been. All useEffect and useState does is turn pure functions into mud that reads like a class but drops all the syntactic sugar that makes it readible.

> * Accurately model component as being in multiple states at the same time for concurrency. (Important for future React features.) Closures can do that because they capture specific props and state.

Besides this not making any fucking sense, why don't you call new and leave me out of it?

As a user, Why do I need hooks today?

> Finally there are some difficulties related to optimizing class code at compilation time. Such as inlining and fusing classes together. Functions make this simpler and they also minify better due to safer mangling.

Why do I need hooks?

[danabramov]

>In the mixins are considered harmful blog the point is made that sharing logic between components is a mistake and you should be using composition to achieve the desired outcome. Why do I need hooks? Is composition considered harmful now?

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

Consider that reading everything with a cynical mindset might be obscuring the design. I encourage you to play with it a little bit to get a feel for it.

>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. 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-...

Dismissing them as unnecessary doesn't really point to any concrete solutions so it's hard to debate.

>Besides this not making any fucking sense, why don't you call new and leave me out of it?

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

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

I'd be happy to continue this discussion but I'd appreciate if you could tone down the aggression and snark a little bit. You seem to be very annoyed by our conversation, in which case I'm not sure why you talk to me at all. Answering comments like this isn't a part of my job, and I'd appreciate if you could at least talk respectfully even when you disagree. Thanks.

[lugg]

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.

[asark]

> All useEffect and useState does is turn pure functions into mud that reads like a class but drops all the syntactic sugar that makes it readible.

You've nailed it. Their solution to the issues with certain JS OO features was to re-implement Objects minus the features that were a problem, with new syntax. The code's worth a read for anyone who's read how the feature works and is still thinking "no, surely they didn't, it must work some other, magical way".