I love React Hooks

https://vijayt.com/post/react-nugget-2-why-do-i-love-react-hooks/

by vijayst • 7 years ago

104 118 7 years ago

How is it that React gets celebrated for “solving” problems that React created in the first place?

The entire paradigm of React keeps changing as each pervious iteration proves to be “messy” or “over complicated.” createClass? Nah that’s obsolete. Mixins and HOC - oh wait, bad idea, hooks to the rescue!

At what point do people start to call BS and say you shouldn’t build around a framework that needs to be reinvented every year or two?

sophiebits3• 7 years ago

(I worked on React.) Many people have adopted React and are happy with it, evidently because they believe the problems it creates are minor compared to the problems it fixes.

It’s rather reasonable for them to be excited about a new version that keeps (or improves!) the good parts while having fewer tradeoffs.

jen729w• 7 years ago

React is amazing. I'm teaching myself JS — started October '17 — and I've gone through a few iterations of my little project as I learn more.

- Vanilla JS: it works, but holy moly it looks bad and the amount of code I have to write to do even basic stuff really really hurts my brain. (Actually what am I talking about, it never got close to "working" before I moved on to...)

- jQuery/Node: ooh, this is better. But still, doing stuff takes ages.

- React: OH MY GOD WHAT IS THIS HEAVEN.

People will say that "people like me" shouldn't be writing web apps if we don't know what we're doing. To them I say, screw you. These tools enable us to do things that would never have been possible.

Thank you from the bottom of my heart for doing whatever it is that you did. :-)

ilovecaching• 7 years ago

Thanks for all your great work sophiebits. React is perhaps the most important milestone in bringing functional concepts to the mainstream to date, and the project has been really well managed. It makes backend people like me actually enjoy writing JavaScript! Excited to see what you do next.

hesarenu• 7 years ago

That is just state management. The basic premise of reactjs has stayed the same.

hombre_fatal2• 7 years ago

Without trying new things, you get stuck with, say, UIKit + CoreData which make me miss React every second I'm building an iOS app. All the KVO stuff that make it hard to actually reason about state changes.

Of course React, like any library/framework, is going to have its own idiosyncrasies. That isn't the question. The question is if it's still better than alternatives, and people clearly seem to think so. My first React app I ever made years ago still works on the latest React, seems pretty stable as far as the web client ecosystem goes.

Client development isn't trivial on any platform, btw. But I think we have it pretty damn good on the web, relatively.

pjmlp2• 7 years ago

We will only have it damn good on the web when it is as easy as doing RAD apps in Delphi, or using Blend to design UI layouts.

I see a good possibility with WebComponents, which React seems to be the only framework not going for them.

emilsedgh• 7 years ago

React resolved very big problems.

These pattern changes are tiny improvements. Basically they are improving the syntax a bit.

sutantog• 7 years ago

no other framework lets you do so much by learning so little. React has the best learning curve to value ratio

johnfn• 7 years ago

This seems pretty disingenuous to me. React didn’t create the problem of class methods not binding this correctly. That’s purely a javascript problem, which react now provides a way to solve.

hombre_fatal2• 7 years ago

React's original createClass() even tried to solve that problem with autobound methods but they decided it wasn't worth it: https://reactjs.org/blog/2015/01/27/react-v0.13.0-beta-1.htm...

mpweiher2• 7 years ago

This is a question that’s been puzzling me for quite a while.

For one, react is a fairly competently done, roughly MVC UI framework. The components are views, render() is drawRect. Being in the browser, render() doesn’t draw into a bitmap, but rather returns structured objects.

That also means painting optimization is diff-based rather than damage-rect based.

Which brings us to what appears to be the biggest difference: traditional MVC GUI toolkits such as Cocoa clearly separate creating a UI from updating the UI with data. For updating the UI from the model (and the model from the UI), you follow MVC, which specifies how the Views map the model to the display and vice versa.

The actual views stay the same during that time, the data changes.

React combines these two steps into one, conceptually recreating the entire UI at each step like a game.

While this solves some issues that have crept into toolkit programming due to a shift towards handling dynamic aspects via changes in the view/widget hierarchy, it is conceptually rather muddled[1].

This conceptual muddle, claiming that the UI is a “pure” function of the state when it is clearly not, seems to the major source of those problems that keep needing to be solved.

To me it would seem that looking dispassionately at the problems react solves without the conceptually troublesome baggage might be useful, but that’s just my € 0.02.

[1] https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...

jasim3• 7 years ago

The linked post is a great comparison of functional and object-oriented approaches to building UIs. Thanks.

I think the crux of the issue is here: > "So if we don't make the incorrect assumption that UIs are unstable (pure functions of model), then we don't have to expend additional and fragile effort to re-create that necessary stability."

In Cocoa, and generally in desktop UIs, your assumption is true. A UI is a set of "slots" into which dynamic data is displayed. But on the web this is a lot more fluid. You can have visibility toggles across the application, and the UI can vary drastically between one state to another. I think this is the fundamental mismatch between the object-oriented approach to UI and the functional approach to UI.

Also, in the "Lists" section, the functional approach would not be to create a persistent Map, which then has to be invalidated as its source data changes. Instead, the mental model in the functional approach is to always re-compute everything; memoization is an optimization that should be transparent.

alangpierce• 7 years ago

Part of the point of solutions #1 and #3 is that they pass in exactly the same function on each render, so it's possible to avoid unnecessary rendering further down by knowing that the props are the same as before. The hooks solution will make a new handleChange closure each time, so it'll be a different function. Is there are way with hooks to pass the same function each time?

sophiebits3• 7 years ago

useCallback is designed for this. useMemo also helps solve the problem from another angle that previously wasn’t as accessible.

Additional reading: https://reactjs.org/docs/hooks-faq.html#are-hooks-slow-becau....

wereHamster• 7 years ago

Perhaps the `setText` function remains always the same. I have not checked though.

ronilan• 7 years ago

With React Hooks, I do not need to deal with the messy “this” coding pattern of class components. And there are no three ways to write this code.

Yep. Now there are four.

I have no specific opinion about React hooks (or about love for that matter), but “languages” with a simpler vocabulary do tend to have an advantage in the long run.

vmware505• 7 years ago

I actually like classes and using "this". Maybe I just like Object Oriented style. :)

sophiebits3• 7 years ago

OO style definitely feels more familiar to many people.

You may find Dan’s thread on this subject interesting though — he tries to explain why neither plain classes nor plain functions are the best fit for React: https://twitter.com/dan_abramov/status/1093694465917751298.

hitekker2• 7 years ago

Truth be told, that twitter thread sounds more like a justification than an explanation.

pier252• 7 years ago

Same here. Also with Mobx all the setState problems go away.

Rapzid3• 7 years ago

I feel like a Mobx style Hook-killer is just over the horizon TBH.

Vanit2• 7 years ago

Hooks seem great for simple usecases but I can't see how you'd not end up with a mess once you have 3+, and since most components inevitably gain complexity, why use hooks to start with?

jrowley• 7 years ago

They allow you to abstract certain kinds of logic in really convenient ways.

If you haven’t seen usehooks.com check it out.

Here is a compelling example of combining a few hooks together for an elegant solution:

https://usehooks.com/useDarkMode/

Vanit2• 7 years ago

I think hooks are just not for me because I don't think those examples look elegant.

fdim• 7 years ago

Oh my, so much code for document.body.classList.toggle('dark-mode', !!locaStorage.darkMode)

Matthias247• 7 years ago

Calling classes messy isn’t really a strong argument. classes are one of the valuable tools in a programmers toolbox. Emulating them via a bunch of closures that act on shared state isn’t necessarily better.

dmitriid• 7 years ago

Problem is, they are very messy in JS. They are a bad thin non-fitting abstraction over JS prototypes.

People keep trying to fix them: https://github.com/andreypopp/autobind-decorator

exogen2• 7 years ago

Not only that, but classes are at odds with advanced render scheduling like React is moving towards (concurrency, prioritized rendering, context switching, bailing out of renders, etc.).

With a class instance, what happens if you need to bail out of a render and potentially restart it again later? The developer could have done literally anything to their class instance the first time through. They could be inheriting from anything and doing whatever they want to `this`. You can't easily "restart" it from its original state, unless you made a perfect snapshot, which is not easy with class instances – you'd need to perfectly deep clone the prototype chain and such.

With functions and hooks on the other hand, there is no class instance or prototype chain to worry about. All state (whether stored via useRef or useState) is controlled by React – the actual object it gets stored on is hidden from the developer. If React wants to ditch the "instance" it was updating on the previous attempt and reuse the one it started with, it can do that without worry.

It's the same reason "time travel" features are easier with more functional approaches. Adhering to functional programming ideas pays off in the long run.

danabramov15• 7 years ago

Note we don’t agree classes are “messy”. That has nothing to do with motivation for Hooks.

Longer comment: https://news.ycombinator.com/item?id=19206401

lioeters4• 7 years ago

After reading numerous articles (starting with the docs), I'm still not convinced, and will not be using React Hooks any time soon. Some of the things I do not love:

- Magic, in the unfavorable sense: if hooks were implemented in an indepedent library, just hearing that they "must be called in the same order every time" and "cannot be used inside conditional statements" should make anyone wary.

- Scope creep: if anything, I wish React focused on reducing its size and API surface.

- Entanglement: related to the point above, the goals of hooks would have been better served with a separate, tiny library that doesn't need to know anything about React, and usable anywhere else, with plain functions that can be tested or reused independently.

Well, the topic deserves a deeper criticism than "it feels wrong", so I hope someone can write a worthy article called "Why I Do Not Love React Hooks", with an example of a better, alternative solution.

I hesitate to bring up a cliché, but it's starting to feel like React is the new jQuery. I'm already trying to anticipate what comes after React, in which case I want my code to depend on the smallest possible API surface area.

But then again, maybe it's my wishful thinking that we would move towards "universal components" (using dependency injection to pass in React or other view renderers like Web Components). Since much of the JS ecosystem seems to be going "all in" on React, perhaps I should surrender to its current. As long as I continue to use React, it looks like there's no escape from its hooks..

EDIT: I should add that the above is just my opinion at the moment, and I'm open to changing my mind. Who knows, I may unwillingly start using them (since everyone else seems to be), and come to love hooks after all.

xrd• 7 years ago

1. Isn't React sort-of magic to begin with?

2. Don't hooks remove the need for redux, etc.? Meaning, don't hooks radically reduce the amount of libraries you need to know about?

3. I prefer to use pure React and not have to choose between Redux, Flux, Mobx etc. And, then do I need to use redux-thunk, etc?

I actually really like the progression towards hooks. I think the articles from the core team (like Dan Abramov) have been well written, explaining not just the how but the why, and it feels like hooks serve to make things simpler and more readable. Yes, you have to throw away a lot of things you spent time learning, but I'm not sad to see anything go away that hooks now handles.

rtpg• 7 years ago

React's core isn't magical insofar as its core functionality (virtual DOM + "update everything on any change") could fit on a 3x5 index card. Implementing it is definitely hard though...

baddox3• 7 years ago

Yes. You need “magic” to be able to write and Reason about your programs in a functional style, while still having side effects and state that changes over time. All functional programming environments have this.

Axnyff• 7 years ago

I feel like if hooks remove the need for redux for you, you actually never needed redux in the first place.

lioeters4• 7 years ago

Isn't React sort-of magic to begin with?

That's true, especially JSX caused an uproar in the beginning as "too much magic", and then was gradually accepted as a vast improvement to previous/other ways of templating.

Don't hooks radically reduce the amount of libraries you need to know?

I'm really hoping so! If they do indeed "serve to make things simpler and more readable", it would be a net positive, regardless of any initial misgivings and possible effort to migrate.

andrewstuart• 7 years ago

I'm all for an advancement that simplifies things, and from the sound of it, hooks enables writing of simpler code.

Two things stand out about hooks to me (from what I have read, have not used them yet):

1: well suited to writing functions rather than classes - this is appealing because there is a line of thinking that values function composition over object orientation.

2: it sounds this finally solves one of the major challenges in react which is simple cross cutting. Cross cutting was always painful and I'll be very happy if this is cleanly solved.

I'm hesitant about new functionality that increases complexity, or is harder to understand and grasp. I'm very enthused about anything that goes the other way.... the industry must constantly strive for simpler ways to do everything.

omeid22• 7 years ago

I think the crux of the issue is agreeing on what is 'simpler code'. I think using lines of code as a measure of simplicity is flawed.

For me simplicity is the three C:

Clarity, in terms of how many concepts do I need to know to understand given some lines of code. The fewer the better.

Coherence, how similar is the expressions I write to what I want to say in terms of the given language. The more similar the better.

Confound, how surprising is the behavior of the code? the less the better.

The issue with hooks I think is that they're trying to treat symptoms rather than solve the problem, if you read the original motivation document by Dan, it talks about State Logic Reuse, Complex Components and People Don't Understand Classes; I think these problems can be tackled much better by their own without trying to add more APIs to React or taking drastic measures like completely change the way people think about React components.

hitekker2• 7 years ago

I think I agree, but we'll see. Personally, I'd like to read about the politics that lead to this kind of feature, rather than just the feature by itself.

danabramov15• 7 years ago

Not sure what you mean by politics in this context, but I explain the motivation here: https://news.ycombinator.com/item?id=19206401

Happy to elaborate on specific points. (This is a very condensed summary.)

A slightly longer version that requires less context: https://medium.com/@dan_abramov/making-sense-of-react-hooks-...

debaserab2• 7 years ago

I hesitate to bring up a cliché, but it's starting to feel like React is the new jQuery

I don't understand this comparison. jQuery extended the existing DOM API to make it more user friendly and made it cross browser compatible (an incredible thing in it's age). React does nothing like this - it brings a completely different concept to designing user interfaces that has nothing to do with the DOM api.

If anything, I see hooks as a response to the community that was installing React+Redux(mobx/whatever global state manager library is flavor of the week) by default. This feature makes it possible to use React as more of a one stop solution, which I definitely welcome.

I'm already trying to anticipate what comes after React, in which case I want my code to depend on the smallest possible API surface area.

That's a fools errand. The code I wrote 10 years ago that relies on jQuery still relies on jQuery (and guess what -- it still works the same as it did when I wrote it!). And the code I wrote 5 years ago that relies on angular1 is still in production (and guess what -- it's fast and incredibly bug free because it's had so long to work out the kinks). Despite these frameworks no longer being fashionable, they still serve in production environments fantastically.

You don't have to rewrite your user interface code just because something else came along. You can embrace the positives of the library or framework that was being used at the time you wrote that code and create a rock solid application. Your goal shouldn't be to write code that depends on the smallest API surface because good code that correctly uses a well written API (which both jQuery and react are) will not be hard to maintain down the road regardless.

danabramov15• 7 years ago

Magic, in the unfavorable sense

This is a common first criticism. There isn’t much magic going on implementation-wise (you could probably implement a simple version of Hooks yourself in <200 lines).

The static call order is controversial. But I strongly encourage you to play with it before forming a final opinion. Pretty much everyone who loves it now hated it at first. (I’m not an exception to that.)

It’s not even as much a technical limitation (we could make arbitrary order work) as confusing semantics if you remove it (how can state be conditional?).

So static call order seems like something you’d enforce with a linter anyway. At that point the cost of allowing dynamic call order becomes not worth it. (Both in API and runtime overhead.) I wrote about it here: https://overreacted.io/react-as-a-ui-runtime/#static-use-ord...

Magic is bad when it’s confusing to use or debug. There are some challenging aspects in using Hooks (like in any programming model, there are cases made easier and cases made harder) but the static call order is not one of them in practice.

Scope creep: if anything, I wish React focused on reducing its size and API surface.

Regarding file size, ironically, Hooks can decrease the overall app file size because function calls minify better (more things can be mangled). The implementation itself makes up for less than 4% of React.

We’re working on making it smaller — but there’s a balance between size, runtime performance and providing abstractions that help remove application and other library code (usually much more impactful). Numerous libraries that migrated to Hooks reported savings in size.

the goals of hooks would have been better served with a separate, tiny library that doesn't need to know anything about React, and usable anywhere else, with plain functions that can be tested or reused independently.

Regarding API surface and the notion of what should and shouldn’t be in React, you might think about it differently if you think about React API from first principles.

Here’s a longread you might find interesting that talks through 90% of React on one page, including Hooks. https://overreacted.io/react-as-a-ui-runtime/

Cheers.

lioeters4• 7 years ago

Thank you for the thoughtful reply. I'm a fan of your work and writings, they've been valuable for the whole JS/React ecosystem.

you could probably implement a simple version of Hooks yourself in <200 lines

It reminds me of the Egghead video course in which you described "how to write your own Redux". That was a great explanation of the paradigm, and transformed how I think about state management in an application.

What I love about the concepts behind the paradigm, is that they can be implemented (as they are in Redux and elsewhere) as a handful of tiny functions that work with or without React, for composable and reusable state and actions.

I think my hesitation about Hooks as they're implemented, is that it seems to go against the ideal of de-coupled, pure functions. Although it does encourage that for the users of hooks, its own implementation feels coupled and impure.

For example, people are applying the Flux/Redux paradigm outside of React components and the UI/views layer, like server-side or independent features that need to manage their own states. I wish that Hooks had taken a similar approach to Redux, as a canonical approach to a generic and generally applicable paradigm, where one could "write your own Hooks".

I strongly encourage you to play with it before forming a final opinion. Pretty much everyone who loves it now hated it at first. (I’m not an exception to that.)

Yes, I'll keep an open mind and study it more.

I read "React as a UI Runtime" when it was published, and it was insightful (will read it again to really digest it). I do love the concepts and principles on which React has been built, so I'll try to understand the reasonings behind how/why Hooks were implemented the way they are.

pgrizzay• 7 years ago

FWIW, I wrote up an alternative proposal for hooks that was based on pure functional programming patterns.

It's more complex but doesn't resort to the impure functions like hooks which cause the same order/conditionals rules.

https://paulgray.net/an-alternative-design-for-hooks/

I think the next big framework will build on top of the declarative jsx-style rendering from react, while also providing pure abstractions of the side-effecting browser APIs

lioeters4• 7 years ago

Interesting! Please do submit it on HN, I'd be curious to see what people think.

_hardwaregeek• 7 years ago

While I do like the idea of more functional components, I don't think hooks are the answer. The reason I like more functional components is because I want to keep components small, stateless and dumb. Hooks encourage people to write more functional components, but I'm not sure that they'll encourage people to write functional components properly. Instead they'll just transfer the anti-patterns they're writing in class components to anti-patterns in functional components. For instance, I could see people writing large functional components with big globs of state and side effects.

The real issue which I want to see solved is getting people to remove business logic from React. I see components loaded to the gills with data fetching and overly complicated async rendering schemes. Personally I try to keep my React components extremely dumb. Instead I try to keep most of the business logic on the server side when possible, and in Redux otherwise. But even that's not great. Redux is fundamentally a data store, not a business logic library. Trying to do complicated logic with selectors/actions is a nightmare. I suppose that's why front end frameworks like Angular and Ember are popular. React ultimately is a view library and yet it provides no good option for the business logic.

underwater2• 7 years ago

Fighting advancements because they could be misused is a battle you cannot win. If your team is going to misuse features because they simply exist then you need to address the root cause — your team — not the library.

Swizec• 7 years ago

The real issue which I want to see solved is getting people to remove business logic from React. I see components loaded to the gills with data fetching and overly complicated async rendering schemes. Personally I try to keep my React components extremely dumb.

Hooks are great for this. You extract all business logic into custom hooks and your components are left as dumb renderers calling other functions to get values. It’s great.

kristiandupont• 7 years ago

Contrary to some commenters here, I think React is just about the best thing that has happened to UI programming in recent memory.

Everything I tried before it (jQuery, Backbone, Knockout, Angular, Meteor (with Handlebars)) felt like it fell short or, in the case of the databinding-oriented ones, like a broken abstraction. I get a similar feeling when looking at Vue though I have no experience so I might be wrong.

I too am a bit skeptical about hooks making what looks like pure functions act like stateful ones. I am not using hooks yet but besides from Dan Abramovs excellent articles about their rationale, I think I will look at them like a new paradigm, only using a syntax that we know from something else. In fact, I wouldn't be surprised if I some time in the future will be using React to write state machines for something that doesn't have anything to do with UI, where "rendering" composes state related to something else entirely. I could see hooks being a game changer here.

baddox3• 7 years ago

I too am a bit skeptical about hooks making what looks like pure functions act like stateful ones.

What’s wrong with that? Any conceivable application needs to actually have state that changes over time. That’s true of all software written in a purely functional style.

Silhouette4• 7 years ago

That’s true of all software written in a purely functional style.

By definition, any software that is purely functional does not have explicit mutable state. In practice, it is often useful to have parts of a system written in a pure functional style but other parts that do use mutable state, either explicitly or via some mechanism that simulates it in a functional context.

shubhamjain2• 7 years ago

One reason I love Vue over React is how beginner friendly it is. You can't make a "Hello World" app in React without getting bombarded with concepts and terms—states, props, JSX, stateful components. Just look that the "Getting Started" example of Vue [1] and compare it React's [2]. You don't need anything more than a notepad to get the first example running.

Progressing down Vue, you realize how they have tried to prioritize convenience. For example, using "v-on:keyup.enter" you can map an action to "Enter" key without writing code for handling that key.

I liked the React's approach but it seems its focus is on purity of abstractions than convenience. Don't even get me started on Redux which is epitome of needless complexity—containers, reducers, event emitters? Was all that really needed?

Note: I have no idea how Vue fares when code base is huge, but my intial impression makes me feel it's far better choice than React.

[1] https://vuejs.org/v2/guide/#Declarative-Rendering [2]: https://reactjs.org/tutorial/tutorial.html

danabramov15• 7 years ago

Just look that the "Getting Started" example of Vue [1] and compare it React's [2].

Thanks for feedback!

The linked React guide is intended to be a pretty comprehensive tutorial — not a getting started guide in the same sense. I wouldn’t say they’re comparable in how much about either of them teaches you about using a library. Maybe it’s not obvious from the wording.

If you do want a simple “getting started” guide that doesn’t require any tools, it’s right here:

https://reactjs.org/docs/add-react-to-a-website.html

And you can progressively learn all important concepts starting from here:

https://reactjs.org/docs/hello-world.html

Another common destination is this guide, which matches the Vue one in purpose a bit more closely: https://reactjs.org/docs/thinking-in-react.html

The “get started” link on the React page links to resources for people with different experience levels:

https://reactjs.org/docs/getting-started.html

Hope that helps!

Longwelwind2• 7 years ago

If your project grows big, you will at some point need to use a state management library like VueX which has similar concepts than Redux, so I'm not sure this argument holds.

My biggest problem with Vue is the template syntax. Since JSX is a thin layer over Javascript, few modifications have to be done over Javascript (or Typescript) tools to make them work with JSX (or TSX). Vue templates are a totally new language which requires more complex tools. I've never had any problem using refactoring tools (renaming variables, go to declaration, find usages, ...) with React, while in my last Vue project, renaming a variable broke code.

Vue has Vuetify, which has been a breeze to use, though. I don't know if there is a React equivalent.

woah• 7 years ago

I can’t go back to a hobbled templating pseudolang after jsx

dkersten• 7 years ago

I think React is just about the best thing that has happened to UI programming in recent memory.

I completely agree that it’s the best thing that has happened to web UI programming in recent memory, but for me, personally, I think Qt’s QML is the best thing that has happened to UI programming in general in recentish years. I like using react, especially from clojurescript using re-frame and I’m very thankful that it exists, but QML has been some of the most pleasant complex UI development I’ve done in the last few years. Now, if only Qt were more like re-frame, then I’d be super happy, but I love the declarative nature of QML and the anchor-based layouts.

olavgg2• 7 years ago

You mention a lot of frameworks and libraries that abstract frontend development into its own "kind". I feel like you're already colored with the "crap" they come with. They all abstract something very simple into something that doesn't scale well for solving many of the common challenges for frontend development. They are all leaky abstractions.

Of all these I have used jQuery and React, but I prefer plain vanilla over these. No breaking changes, no hype cycle, excellent documentation and with good old design patterns any complex problem is easily solvable. Believe it or not, but managing state is dead simple with just vanilla javascript.

Vinnl• 7 years ago

Believe it or not, but managing state is dead simple with just vanilla javascript.

Keeping state and the view in sync, however, is not. For example, if you have a list of TODO's that the user can edit in the browser, and that you want to be able to send to the back-end, every time the user adds a TODO, you'll have to remember to update both the model and the DOM. Likewise after an edit or deletion.

These tools really do solve a problem.

Bahamut• 7 years ago

Devs beware, hooks are not quite there yet it turns out.

You get warnings in jest about needing to use act from react-test-renderer if you use async code to trigger state updates - the solution being recommended currently is mock every promise with a synchronous version, which then litters your app code with conditionals in many places for whether to use the mock or real promises. At that point, you're much better off using Angular for writing decent component/unit tests, where you don't have to fight with any async DOM or JS api in order to write working tests, or pollute app code with test specific branching logic since that is all handled at a single injection point via the IoC container.

If you have promises, you're forced to bleed a isMounted type of flag into the cleanup function scope in order to guard against promises attempting to trigger state changes after the promise is complete with its async function (i.e. data fetching).

These are two frustratingly painful dev ergnomoics situations that are unsolved with hooks. Otherwise, I am happy with them, but these are major pain points I have encountered with them so far, and given FB doesn't use promises in their internal apps for the most part, I don't see them likely to put in much work solving these problems unfortunately.

Disclaimer: I would love to put in some effort to solve these pain points with design discussions & code, but unfortunately I cannot put in that work without going through approval processes with 5+ people.

danabramov15• 7 years ago

given FB doesn't use promises in their internal apps for the most part, I don't see them likely to put in much work solving these problems unfortunately.

This is inaccurate.

The first problem has an issue tracking it (https://github.com/facebook/react/issues/14769) and even a pull request (https://github.com/facebook/react/pull/14853). It’s barely been two weeks since the first release and we’ve been focusing on fixing actual bugs as soon as possible. As I hope you can understand, warnings in tests are a bit less critical and can wait behind production bugs. But we’ll get back to fixing the warnings as soon as possible — maybe even this week.

As for isMounted-like flag. This has nothing to do with Hooks. Classes need exactly the same thing. If you forget it, you’ll likely have both the same kind of warning, and possible race conditions from requests arriving out of order. In longer term we’ll offer a much simpler data fetching integration (read about Suspense) which doesn’t involve effects or lifecycles at all. I think you’ll like it.

littlecranky672• 7 years ago

Hooks are a big deal if you use TypeScript with React. Explicitly typing the state is gone (it will be inferred by what you pass as initial value to useState()). So is weird Partial<TState> typings when setting the initial class state in the constructor or via this.setState().

And if you ever had to deal with correctly typing HOCs or render props you had to dig very deep into conditional/mapped types in TS. With hooks this is basically gone.

machiaweliczny• 7 years ago

With classes you also don't have type state when using 'state = { ... }'.

I think hooks might be nice for data fetching when it comes to TS as it will super easy to get typing.

I'm still not convinced by hooks though.

littlecranky672• 7 years ago

Yes you do, you have to give the type of the state in the 'extends' clause: 'class MyComponent extends React.Component<TProps, TState> { ... }'. If you omit TState, an empty object {} is assumed for state. And you have to specify the type when updating the state via .setState(), because setState() auto-patches/merges the state. So its fine to pass a Partial<TState> to setState.

With Hooks, the auto-patching goes away, so your call to setMyCustomState() always requires an argument of type TState.

There are similar issues if you use the 'static defaultProps = { ... }' on a class - you have to manually specify the type of defaultProps - often it is Partial<TProps>

_robbywashere• 7 years ago

Call me crazy... but how neat would it be if browsers had native JSX and React support - and even some optimizations for it/them?

_pdp_• 7 years ago

As a developer of a extremely large code-base written in Rect (https://launchpad.secapps.com for reference of the kind of apps we are talking about), I am not convinced that "Hooks" solves anything in particular that it is not already solved through decorators. We use decorators quite extensively, from assigning styles in a way that does not force the component to re-render due to props changes, to controlling the props themselves with onChange events and so on.

In my professional opinion, which is based on years spending time with react, the typical gotchas in this framework are down to experience. Experienced react, and more importantly js, developers will write better, more performant code. This is applicable across the board regardless of the framework/language. Hooks will not particularly remove this need nor will make you a better programmer.

While hooks look functionally ok what worries me is that they will be subject to a number of problems. For example, complex hooks/components might be subject to memory leaks. With hooks, we are defining closures inside the functional component which will be subject to having access to proceeding scopes. This is an anti-pattern that we removed from our code-base by using classes. The second problem is that your component will needlessly re-render in those cases where the component is not entirely functional. This may not seem like a problem in the simple examples seen thus far, but it will be with more complex components as I've seen in my experience.

React is one of the best frameworks we have seen around so I am happy that we keep pushing the boundaries but what worries is me is that the React team seems to declare that they are moving towards components written with hooks (not removing classes) which in my opinion is not based on solid evidence that will amount to anything useful in particular.

Again, as far as I am concerned, hooks does not contribute to anything that we are not solving in much better way and I doubt they will ever be used at all as far as our code-based is concerned.

kilburn• 7 years ago

While I don't disagree with you generally, this part

The second problem is that your component will needlessly re-render in those cases where the component is not entirely functional.

is addressed by the react developers in the FAQ [1].

The answer wasn't obvious to me, so I made a toy example in CodeSandbox [2]. There are 3 counters that can be updated using 3 corresponding buttons. Each counter uses a different approach:

1. The "handler" counter uses "useState" + "inner function in the parent's body". The corresponding button rerenders every time the parent rerenders (i.e.: the problem you are highlighting)

2. The "callback" counter uses "useState" + "useCallback" to memoize over the counter's value. The button rerenders only when it is clicked (and hence the counter it controls is updated).

3. The "reducer" counter uses a react context to inject a "dispatch" function that calls an out-of-parent reducer. The button never rerenders. The docs are clearly pushing the reader towards this solution (albeit it is contrived for very simple examples such as this one, I can see the benefits surpassing the boilerplate overhead of reducers in more complex situations).

[1] https://reactjs.org/docs/hooks-faq.html#are-hooks-slow-becau...

[2] https://codesandbox.io/s/r584lz2pom

Azeralthefallen3• 7 years ago

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.

d357r0y3r• 7 years ago

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.

Azeralthefallen3• 7 years ago

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

underwater2• 7 years ago

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.

Azeralthefallen3• 7 years ago

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.

kabes• 7 years ago

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• 7 years ago

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.

Rapzid3• 7 years ago

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.

danabramov15• 7 years ago

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

onion2k• 7 years ago

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.

fastbmk• 7 years ago

TL;DR

People who wish that progress would stop on jQuery & Rails - won't like React Hooks either.

coldtea• 7 years ago

This coding pattern also requires more babel transforms. Not a big problem but something that developers should be aware of.

This sounds like a totally BS reason in the context where it is said.

tekkk• 7 years ago

So can someone explain what the author means by the problem of #3:

However, there are times when we need to pass an extra parameter. In those cases, we cannot use bind because we cannot use bind with arrow functions.

But you can pass the extra argument to the arrow function directly: `onChange={handleChange('name')}`. And use it as:

  handleChange = (field) => (e) => {
    this.setState({ [field]: e.target.value });
  }

Sure it still has the problems of arrow functions I think the arguments against it were worded poorly.

I love React Hooks

Related Stories