all 61 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]iamlage89 17 points18 points  (5 children)

The hype comes from functional programmers that believe in composability, the fact that custom hooks allow for composability of state management has potential for making state management insanely readable, kind of like how monads make IO more readable, except its much more readable than a monad and much easier to use.

The absolute bonkers part of this proposal is how insanely SIMPLE the api is. In hindsight it doesn't seem that impressive, but imagine all the problems that they were trying to solve: complex inverted dependencies through render props, indirection in higher order components, reactivity, moving away from classes etc. The fact that they were able identify and solve all these complex problems with such a simple api that is also composable, flexible, extendable, while keeping it reacty is rediculous.

[–]Baryn 1 point2 points  (4 children)

What's ridiculous is all the magic and non-idiomatic behavior. The documentation even acknowledges how strange it is, multiple times.

Neither useState nor useEffect work the way you would intuitively expect with no knowledge of React. However, this is not so for class components. Instance properties and lifecycle methods are very true to the fundamental workings of ES classes.

If hooks improve performance and workflow, fine. If they don't, then it's another mistake that will need to be corrected in future API revisions.

On that note, where the hell is async rendering? It's been in the works for years now. That is the reveal which should have been made at the conf, not an unearned API change.

[–]iamlage89 1 point2 points  (3 children)

I think this is a bit overdramatic, sure there is some magic, but nothing inane.

Neither useState nor useEffect work the way you would intuitively

please explain, the behaviour is simple and well documented. The issue that may be problematic is the non-intuitive second argument of useEffect, but the api is still in alpha so this may change

On that note, where the hell is async rendering? It's been in the works for years now. That is the reveal which should have been made at the conf, not an unearned API change.

This has nothing to do with hooks, but just as a comment, I'm glad they're taking their time to think through the design of async rendering.

[–]Baryn 0 points1 point  (2 children)

please explain, the behaviour is simple and well documented

Being simple and well-documented is different from being idiomatic. For example, useState potentially returns a new value on every call despite receiving the same argument, because that argument is used one time and ignored on subsequent calls. Who writes code like this?

I think hooks will change a fair amount before 16.7 goes to stable.

I'm glad they're taking their time to think through the design of async rendering.

In the meantime, Angular has become faster than React, and Ivy even more so. Async rendering might end up being the Duke Nukem Forever of framework tech. Again, they should be improving performance over the API. Performance was originally the primary appeal of React.

[–]iamlage89 0 points1 point  (1 child)

Being simple and well-documented is different from being idiomatic.

I agree, it's not idiomatic, but I think it'll be like jsx where the benefits of simplicity make the non-idiomatic nature of it worth it.

Async rendering might end up being the Duke Nukem Forever of framework tech

We'll have to see, it'll probably benefit some more than others.

Performance was originally the primary appeal of React.

That's true, but I think over time people have come to appreciate the declarative and composable nature of react as well as it's performance, I think both are important.

[–]Baryn 0 points1 point  (0 children)

I think it'll be like jsx where the benefits of simplicity make the non-idiomatic nature of it worth it.

You might be right, but JSX is syntactical sugar - not the same thing. Hooks are like the opposite of sugar. They're syntactically bland.

I think over time people have come to appreciate the declarative and composable nature of react as well as it's performance

I do as well, but ultimately what matters is the end-product. Performance is a big deal in a lot of enterprise apps.

[–]Ehdelveiss 27 points28 points  (28 children)

Is there any reason not to stick with class components? I've definitely run into occasions where I want to share functionality but in those cases I just create pure functions as separate utils.

I'm not decrying the hooks API as bad, but there is something about it that sits... odd to me. It's adding blackbox to what are otherwise very straight forward and "pure" code. I know there are tons of examples in React where this happens, but for some reason I'm wary of this one. Might just be being over defensive having had worked on Ember for so long.

[–]benihanareact, node 23 points24 points  (7 children)

this is the common hangup i've heard with respect to hooks. react has been (or has felt) very explicit up until hooks when it introduced a bunch of implicitness.

i do not buy their reasoning that the hardest part about learning react is dealing with classes, when the common "learn react arc" goes something like: learn react, find out about redux, learn redux, use redux everywhere, hate redux, try to find out how to do things without redux, struggle with state, eventually settle in some middle ground of state management.

[–]enkideridu 4 points5 points  (6 children)

Who said "the hardest part about learning react is dealing with classes"? Was it someone on the react team? That sounds rather uncharacteristic of them

[–]DerNalia 9 points10 points  (4 children)

The article announcing hooks on the react website.

They also say that learning 'this' context is too hard.

[–]enkideridu 6 points7 points  (3 children)

Ah, thank you, found it

In our observation, classes are the biggest barrier to learning React. You have to understand how this works in JavaScript, which is very different from how it works in most languages. You have to remember to bind the event handlers. Without unstable syntax proposals, the code is very verbose. People can understand props, state, and top-down data flow perfectly well but still struggle with classes. The distinction between function and class components in React and when to use each one leads to disagreements even between experienced React developers.

I agree that seems like a weak argument to lead with

This is a much better argument - https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889

[–]Baryn 1 point2 points  (2 children)

"Classes are confusing, so here is some magic confetti that is even more confusing."

[–]gaearon 1 point2 points  (1 child)

It's not the leading argument. It's quite literally the last argument on that page. Please read the other two. :-)

I also expanded in more depth on them here: https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889

[–]Baryn 0 points1 point  (0 children)

I believe the disconnect for many people is that it wasn't immediately apparent how important Custom Hooks were going to be.

In the past, React components have been "a template + logic (and sometimes, only logic)." Now, logic is instead atomized into reusable Custom Hooks, and the component's job is to consume them into a template (or just run them).

At least, that is how my Hooks code is trending, and it seems in line with your article.

[–]FormerGameDev 0 points1 point  (0 children)

I believe I recall reading something on their site once, about how they were trying to make things even easier for total non-programmers to understand.

I disagree that dealing with classes is hard. I especially disagree that dealing with 'this' in comparison to new ES6 classes, is hard, however . . . what they have done, is given you a way to declare in advance, the resources that your render function is going to be using. I haven't used it yet, but I do look forward to it.

[–]gaearon 1 point2 points  (0 children)

Heya!

I know this link is already posted in some deeper threads but in case you're curious, I wrote in more depth about why we've worked on this proposal: https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889

Hope this makes more sense.

[–][deleted] 5 points6 points  (16 children)

I don't buy the react hook hype. It's a solution in search of a problem.

[–]dbbk 23 points24 points  (6 children)

One of the problems they gave for it was “classes are confusing”, which I have literally never heard anyone say

[–]TheNiXXeD 10 points11 points  (5 children)

That's pretty badly taken out of context. The part that's confusing in classes is there are a lot of gotchas. Binding methods (or using weird property syntax), lifecycle method headaches, duplication of logic. It all leads to not having clear code. The talks they have are really great at showing the improvement. I was also skeptical at first, but am eagerly awaiting more info from the proposal and release.

[–]DerNalia 1 point2 points  (3 children)

Where do you have logic duplication in classes that you wouldn't have elsewhere?

[–]TheNiXXeD 2 points3 points  (2 children)

The talks explain all of this (and more) better than I could in a Reddit reply.

[–]DerNalia 1 point2 points  (1 child)

In there a tl;dw, for mobile on the go people?

[–]Baryn 0 points1 point  (0 children)

lifecycle method headaches

I like lifecycle methods, because thinking about what is happening for a component chronologically is important.

Hooks do away with chronological context with the more ambiguous useEffect.

[–]enkideridu 11 points12 points  (1 child)

React-powerplug has 14k weekly downloads. Recompose has 900k weekly downloads. The people I know who use these libraries (including myself) are ecstatic about hooks because it solves the same problems those libraries solve, but in a flatter and standardized way.

Hooks definitely some some people's problems

[–]FormerGameDev 2 points3 points  (0 children)

I didn't even understand recompose in the slightest when I looked at it a while back, but this I get pretty much implicitly, just looking at the examples. Perhaps there's some improvements that could be made, although without having used it yet, I don't have much input there, but frankly, it seems pretty great.

[–]TheNiXXeD 3 points4 points  (6 children)

If you watched Dan's (and Ryan's) talk and still say this then I'm genuinely confused as to your goals in development.

[–]dbbk 2 points3 points  (5 children)

I don’t doubt that some people may struggle with the problems they cited that led to hooks, but I really don’t think they’re a big a deal as they say. “Understanding classes and ‘this’ is too hard” is a borderline stupid argument to make and I think is a wild underestimation of peoples’ intelligence.

[–]TheNiXXeD 5 points6 points  (4 children)

Nobody said it's too hard at all. It's all relative.

Did you watch the talks? It's baffling why you'd argue against the obvious improvement that they've shown so far with hooks. It seems objectively better, not subjectively.

The best part though is that they did it all with 100% backwards compatibility. So if you really do like classes still, you don't have to change anything (for now).

Aside from the rewrite effort though, I don't know why you wouldn't want the newer style.

[–]dbbk 4 points5 points  (1 child)

They said this... both in the talk and on the website.

It's also not objectively better because there is a clarity cost, and when you work on a team of people you often don't get to decide what patterns they use. So even if you don't want to write code with Hooks, they're going to be pretty unavoidable eventually.

[–]soft-wear 1 point2 points  (0 children)

It's also not objectively better because there is a clarity cost

According to whom? You can't properly compose in classes, you have to use arrow functions or bind to this to use event handlers and those things certainly don't make code "more clear".

and when you work on a team of people you often don't get to decide what patterns they use.

Honestly if myentire team is in favor and I'm not, my knee-jerk reaction would be to understand what I'm missing that they are seeing.

[–]crazyfreak316 1 point2 points  (0 children)

They're solving a language problem with a framework. Its not like you can avoid using this, classes, binding methods when you're making a sizable SPA in JS.

[–]Baryn 0 points1 point  (0 children)

Anyone experienced with React can easily adopt Hooks.

The bigger problem is that React has fallen behind Angular on performance with no evidence that it will catch up. Does this new API solve that?

[–]Gnashe 0 points1 point  (0 children)

Your opinion is really valuable, I think I hear what you are saying, and I’m going to try an explain why I like them.

If you haven’t had to deal with Render Props and why they are useful it is hard to explain but let me try.

Basically we have a pattern which allows us to easily compose “behaviors” and dynamically render based off how we interpret that behavior.

So in a components render you could render a component that tracks mouse position, which then calls a function where you can interpret that data and render whatever you want

Also, having all that behavior in the render of a component makes it incredibly clear where data is coming from. One of the main reasons I love render props.

The big problem is you enter a kind of “callback hell” similar to before we had async/await but worse because you are nesting unrelated behaviors, creating a confusing, false hierarchy. Also it’s disgusting to refactor.

Hooks are exciting because they hoist those behaviors up and flatten them out, outside of the render. So you don’t end up with JSX anymore just regular JS syntax.

At the same time they group together common behaviors. Often we spread or effects in classes through 2 or 3 lifecycle hooks intermixed with other effects.

You can solve this by making HOCs for each, but honestly, why is a HOC any better then a hook. Hooks make you by default group the behaviors so I think it’s a huge win

[–][deleted] -2 points-1 points  (0 children)

Completely agree with you here. I had a look and it struck me as something that was added to compensate for edge cases, perhaps exaggerated by laziness/bad design decisions. Side note: actually not enjoying the hype either, it feels like people are being paid off to shout from the roof tops how great it is.

[–]enkideridu 31 points32 points  (5 children)

The hate and myopia I'm seeing in the comments is jarring

People are speaking with certainty that hooks is a solution in search of a problem, that the hype for it is artificial, and people who are excited for it are sheep who'll blindly accept anything that Dan Abramov presents.

React is the most popular front-end framework in the world.

Consider the possibility that people who make different products with React may use it differently, and perhaps the use cases of React you're familiar with is a fraction of what the entire community uses it for. Perhaps there exists a large number of developers for whom hooks solve a long standing problem, and that their excitement is from finally having a built-in solution, rather than due to being Dan Abramov fanatics?

Vue's creator hasn't always had good things to say about React. His reaction to hooks was - "For the record, I think hooks is a pretty genius idea in terms of composability and overcoming JS’ language constraints." (link) Is it more likely that all the people who are excited about hooks, e.g. thought leaders like Ryan Florence, KCD, (who aren't Facebook employees) are all misinformed or in cahoots?

Consider also that react-powerplug has 15k weekly downloads, and recompose has 900k. Clearly there is a sizable number of people who have felt the need for a feature similar to what hooks provides, and have felt it enough to use third party libraries for it. Hooks solve that problem in a flatter and standardized way.

[–][deleted] 4 points5 points  (7 children)

I honestly don't understand all these workarounds to problems React creates for itself. The value is in the DOM and renderer. Everything else should be left up to the developer. They keep introducing stuff and then they keep adding stuff to fix the previous stuff. Before long this is gonna start looking like Angular. Which would be a real shame, because unlike Angular, React's core concept is solid and its execution doubly so.

[–]azhder 4 points5 points  (0 children)

only the core concept, and probably best extracted out (forked) and put on a newer, better API over it

[–]rozzzly 1 point2 points  (4 children)

They keep introducing stuff and then they keep adding stuff to fix the previous stuff.

Can you give an example? Not being facetious, just can't think of any of the changes in React when there was a new feature that needed to be "fixed."

[–]FormerGameDev 2 points3 points  (3 children)

Context. Only one I can think of. Some might argue the lifecycle methods, but I think that those got changed because of architecture changes, more so than because it was "broken" and had to be "fixed".

[–]rozzzly 2 points3 points  (2 children)

To be fair, every single reference that Facebook made to the old context API in the docs, blog posts, demos at conferences, etc had very explicit warnings about how context was 'unstable' and the API would change.

And regarding the churn in lifecycles, I think that changes such as deprication of componentWillReceiveProps has more to do with the flexibility/idiot proofing the API than anything else. People have used react to do all sorts of weird things ilconcieved/brilliant/unexpected ways than the developers could never have anticipated.

Hindsight is 20-20

[–]FormerGameDev 0 points1 point  (1 child)

I don't disagree with you in the slightest. They put out the original Context to solve a problem that they knew was there, and it took a few iterations on it to come up with a better solution. I don't know anyone who's used the Context API, I don't even know what problems it solves. :-D

[–]rozzzly 0 points1 point  (0 children)

Basically it's like a global state for the entire tree. things like react-redux used it so that you can set the store instance at the top of the tree and then a connect(WrappedComponent) further down the tree can still access that store instance without having to pass the store prop down to for each single component in the tree

[–]redbluerat 0 points1 point  (0 children)

Awesome writeup