[Azeralthefallen]

Honestly i struggle when people argue that 'this' and class components are complicated, and that hooks remove that complexity. Yet then i see people composing together dozens of various hooks and HoC's to achieve the same balance is beyond confusing.

Recently i was assigned a PR for a component (a login form) i wrote about a two years ago which was a whole 300 lines. The person who wrote the PR also took the time to make it "functional", which has now resulted in it being split into almost a dozen different files. I don't find this cleaner or easier to understand at all.

Current team i am on uses MobX, and Typescript for our app and frankly it is painfully simple, and yet people keep arguing that we should drop mobx, and switch to hooks and i don't see any benefit.

[kabes]

One part of the functional promise seems to be that if every piece of functionality is small, isolated and easy to understand that the whole of the application becomes easy to understand. However, I would agree that I often find the opposite to be true when everything is scattered around in mini functions over hundreds of files.

[arkh]

> One part of the functional promise seems to be that if every piece of functionality is small, isolated and easy to understand that the whole of the application becomes easy to understand.

This part is wrong. Your huge components are made of what? Small things. Isolating all those small things just let you add more boilerplate and mental load when trying to debug. To reduce complexity you have to remove code, not move it around.

[danabramov]

I don’t think we promote isolating every little thing. That would indeed be counterproductive.

It’s more about being able to reuse some stateful logic between components. That’s the point of custom Hooks. There are pretty cool libraries existing already. For example React Spring takes advantage of that programming model for animations: https://www.react-spring.io/docs/hooks/use-spring

I tried to explain the motivation for Hooks here:

https://medium.com/@dan_abramov/making-sense-of-react-hooks-...

Hope it helps.

[lugg]

This whole thread is wrong. Nobody said you had to split the functions off into a bazillion files that's just stupid. Youre taking the worst part of enterprisey OO culture and ruining the best part of functional.

And no, you do not need to remove code to reduce complexity you're mistaking correlation for causation.

Boilerplate may occur in the short term during a refactor to pure functions but that can eventually be refactored out once things are unshackled enough to be refactored.

[underwater]

Are you using Storybook or a similar system? I've got a lot of value in defining my application in decoupled components when I can verify the implementation of each part in isolation.

[Azeralthefallen]

We write tests to verify if things are working correctly using Cypress + Mocha. We have simple unit tests for validating basic functionality and extensive integration tests. We typically have a set of tests per feature.

The problem i have noticed is that people say "well it works in isolation", but on integration with other components it doesn't work properly. Unfortunately this is a huge problem i find, and frankly the idea of numerous shared hooks and ensuring they are side affect free is very painful.

[onion2k]

Honestly i struggle when people argue that 'this' and class components are complicated, and that hooks remove that complexity.

I'm surprised you find it so hard to comprehend what other people think considering how trivial I think it is to understand them.

Maybe there's a lesson here.

[d357r0y3r]

mobx-react-lite (supported by the main mobx team) uses hooks under the hood, but extends mobx-react behavior to SFCs. I don't think it creates any additional boilerplate and it aligns with the direction React is going.

[Azeralthefallen]

Unfortunately to me examples like this looks like you are trying to fit a square peg into a round hole and are twisting something to fit reacts new functional direction.: https://github.com/mobxjs/mobx-react-lite#useobservabletinit...

[Rapzid]

I'm a bit dumbfounded about the "this" and "class" confusion concern as well. I'm not surprised to hear people have trouble with that per say.. I am surprised a company like Facebook cares about those people. Isn't this the same company that wouldn't hire the homebrew author? I get the sense the only UI people who really know programming work on the React team.

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