With React 16.8, React Hooks are available in a stable release

Hooks fix some of the composition headaches you get from render props, which is the current standard for composition (the heritage being HOCs -> render props -> hooks). They're basically mixins with weird syntax.

I thought the same at first, but Dan Abramov and his blog[1] has changed my mind.

[1]: https://overreacted.io/why-do-hooks-rely-on-call-order/

In case you’re curious, I recently wrote up a deep dive on React from first principles that includes Hooks.

https://overreacted.io/react-as-a-ui-runtime/

Personally I don’t see them as being either “magic” or “implicit”. You might find my post helpful for conceptualizing how they fit into the picture.

(Warning: it is a longread. But it also explains 90% of React on a single page.)

Hooks make a lot more sense from a traditional FRP perspective. The code you write with hooks is basically identical to the code you'd write with early FRP systems. For instance, useState is called newWire in FranTk. The difference is that hooks have various limitations about where you can create them and how you can pass them around, which those FRP systems don't have. That's the result of React using plain old data as state, instead of having a signal abstraction as in FRP. In React the component function gets re-executed every time the state changes, whereas with FRP the component function gets executed once and builds up a dataflow graph that deals with the changes. That makes hooks very natural because they're just nodes in the dataflow graph.

My litmus test for technology is whether it results in a) fewer lines of code b) simpler code and c) does it make me more productive. My experience with using hooks is that I rip out lots of cruft and it is easier for me to get my head around how to write things so I am more productive. The cost is learning a new paradigm, but the benefit for me was very high.

Edit: this is one reason I don’t do the social media thing. I read that in a totally different frame of mind than you wrote it in, probably. I am not one to get all preachy. I personally get caught up in analysis paralysis sometimes because everyone has convincing arguments. It’s because there are many right answers. There’s probably some deeper psychology there... dunno but it’s on me.

No offense, but it would sometimes be good to remember that quote about sufficiently advanced technology being indistinguishable from magic when taking such an authoritative tone.

There are probably some other equally talented developers who do ‘get it’ who might be a little unsure of themselves and continue to hold back and feel like an imposter.

Anyway, that’s not really a call to change or anything. You do you.

But I did want to remind everyone else, especially those unsure of themselves, that those are, like, their opinion... you also do you.

I have the exact opposite perception. Previously, I used to convert a function/stateless component, just because I need one transient state and it felt very verbose to switch to class components, while all it needed was one state and corresponding setState. With Hooks, all of them just become more transparent (you explicitly have to hook all the states, not just use one state and add later add more states to track). Though I admit I felt uncomfortable initially, it just feels right once you start working with them. I really like hooks!!!

Glad to read that as the top comment, because when they came out, I expressed strong doubts about this new features, and I mostly received mad comments in return. The alienated react fans stated that I didn't understand what modern code was, what a great idea those were and how from now on, everything will be better.

Now hooks are certainly a technically interesting pattern. I can see why it can be desirable by some. But I can't shake the feeling it has too of a big potential for misuse and could add a lot of complexity to a react, a tool that already has a big cognitive load with an ecosystem letting easily creep technical debt.

Besides, an important part of the JS community, up to now, has let me inconvinced about its ability to do the right thing, not to mention learning from other's past mistakes or even admitting when something is a problem at all.

Maybe you just don’t understand them yet.

My impression is the community is mostly accepting, but some are taking a wait and see attitude until they can see it in production.

I don't think there's a lot of concern about hook ordering; it's hard to see that being a serious issue in practice. And it has some significant advantages over existing alternatives.

This talk introducing hooks explains it well: https://youtu.be/V-QO-KO90iQ:

I'm using them on my current app, and have no intention of going back to classes.

> lack of a parameter explicitly indicating the component

That's sort of the whole point. That you can write general purpose side effect functions that don't need to care about which component they're being used in. It's super easy to have a toolkit small unit testable functions that do the pretty much all the work in the application. Far easier to work with than inheritance, mixins or traits. Easier than composition, even, because this is just calling functions. If you're familiar with using Underscore or lodash, this model will feel very intuitive.

> reliance on hook ordering

This is a red herring, because we're only talking about execution ordering when the code runs. It doesn't actually matter what order I write any code in, only that when the code runs the order doesn't change between two render frames. This is as simple as don't have conditionals outside the hooks, have them inside. If you think of hooks as accessing the state register by the index of their first access, it works well as a rule of thumb.

The real problem is the impedance mismatch that the line above causes - you need to remember that hooks access the state register by order of their first appearance, not by identity. So if hook no. 3 doesn't execute on the second render for some reason, hook no. 4 will see hook no. 3's data. This goes very contrary to JS or any other programming language / paradigm I know.

It also has repercussions (https://overreacted.io/making-setinterval-declarative-with-r...) that are unintuitive, because the identity of the functions you pass into the hooks is lost as well, so you need to put them into the call-positional state register via a ref.

To be honest, I haven't hit that edge case yet, and it's easily handled once you understand the system for what it is. It is very un-intuitive to program this way, but it's not a problem most of the time.

Just remember that the identity of the state of any hook is represented only by its sequence number of execution during the first render, and you can figure out the remaining gotchas from that.

This post by React dev lead Dan Abramov goes deep into this question (much more detail than is available in the React Hooks FAQ or the ReactConf talks). https://overreacted.io/why-do-hooks-rely-on-call-order/

tl;dr: The primary design goal of hooks is to support the creation of custom hooks, which can eliminate the need for higher-order components in many cases. An ideal alternative implementation would support custom hooks, without relying on call ordering, and without requiring a linter to guarantee safety. Unfortunately, there doesn't appear to be an approach that satisfies all of these requirements. Depending on call order is apparently the least-bad approach to hooks.

Think of series of `useXXX` as declarations, not function calls, then everything will make sense to you.

The declaration parts are always static and in the exact same order for the same component.

When you see a state less function

    ToggleButton = () => {
      const [flag, setFlag] useState(false)
      const [count, setCount] useState(1)
      const useEffect(()=> {....})

      return <button onClick={() => setFlag(!flag)>{flag}</button>
    }

View it as a component with two separate sections, behavior declarations and actual rendering:

    Component ToggleButton
      // declarations
      hasState: "flag" setterName: "setFlag"
      hasState: "count" setterName: "setCount"
      onEffect() { .... }

      render() {
        return <button onClick={() => setFlag(!flag)>{flag}</button>
      }
    }

Then you will see that reliance on hook ordering being the same is what you always do when you write a declarative code anyway.

I think time will tell.

It's basically the magic vs explicit discussion all over again. Like usually in this discussion, the magic approach is really appealing until it doesn't work, and then the pro-explicit people will go all "told you so" on you.

I personally really prefer explicit, having cut my fingers on magic one time too often. Instead, I'll gladly create classes if the thing I'm making has its own state (of any kind).

In fact I pretty much disagree with the current trend of wanting to shoehorn everything into this idea of declarative and/or functional programming. Especially in a language like JS, functional programming and some cherry-picked ideas from OO mesh really well together. For example, if you allow me to drift a little, did you know that you can add methods to the prototype of an Immutable.Record? You can even use class syntax! More to the point, if there's one place where OO ideas shine, it's UI components. A lot of OO ideas were particularly designed and developed for UIs.

Just like "let" and "const" let me communicate to the reader whether a variable is going to change, I like how in React-land "class" and "function" let me communicate to the reader whether a component has mutable state. Hooks feels like a hack to be able to change the value of a "const" without turning it into a "let". Get over yourself, make it a "let" already.

So for me, Hooks is an attempt to throw the baby out with the bath water. I don't experience the problem it's trying to solve. I like classes when they're appropriate.

I get the argument that custom hooks allow for easier reuse than higher order components, but I think the difference is marginal; you have to wrap your mind around the exact same complexity. Plus I think higher order components themselves are overused, but that's another story.

But! The React people strike me as a rather reasonable bunch. I strongly doubt they're going to move React into a direction where you're forced to make your state (slightly more) implicit. There's too varied a community around React now. I think React with classes and React with hooks can perfectly coexist. Also if my favorite open source React tool adopts hooks and forces me to do the same here and there, then sure I might be grumpy for a few minutes but in the end, well, I'll survive.

While HN wasn’t convinced last time I posted this, here’s a few posts or sections that explain the static call order thing:

https://overreacted.io/why-do-hooks-rely-on-call-order/

https://overreacted.io/react-as-a-ui-runtime/#static-use-ord...

https://github.com/reactjs/rfcs/pull/68#issuecomment-4393148... (Persistent Call Index section)

Hope this helps, happy to answer questions. We’ve been using Hooks for several months at FB and haven’t seen confusion caused by the call order reliance.

(Note Hooks don’t rely on specific call order but just on it being static between renders. Which is pretty easy to understand and reasonably enforce in practice.)

Recently wrote a customer dashboard app and hooks were just introduced. I'm glad I went full in with them.

I think they will be the standard going forward.

Hooks future depends on its objective: a replacement or an alternative?

I guess even the React team itself doesn't have an answer for this, that is why they are rolling out Hooks relatively cautiously, not forcing it down to the community like what angular does with its 1.x -> 2.0 push, which I consider as a complete disaster that eventually costed it the victory of last framework revolution.

My bet will be on the later. Hooks will become a preference, and there will be a mix of hooks/classes in real world application, since rewriting using Hooks only isn't what most people see will bring immediate benefits. The React community at large from my observation doesn't have a huge issue going forward with the current API, despite being grumpy from time to time.

Hooks are an alternative to HOCs and RPs.

Their bad part is, they add another concept besides components.

Their good part is, they allow to convert non-display components to hooks, which removes the guessing of where the logic is stored.

A major point of Hooks is that they’re composable — unlike lifecycle methods.

You can separate different reusable pieces of logic into Hooks, and then combine them or pass values between them. You can even call the same Hook more than once.

I’ve wrote about new possibilities they unlock here:

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

Hope this helps.

It's a little harder to wrap your head around for sure.

But the benefit is tighter encapsulation of functionalities. No longer do we have to spread a feature's logic across multiple lifecycle methods that may share that space with logic from other features.

Here is a visual example of how hooks move all the parts of a single concern into a single block of code which, in a class component, would be littered across lifecycle methods: https://twitter.com/threepointone/status/1056594421079261185

Grouping these parts this way means they can be trivially extracted as a Custom Hook[1] (analogous to a 'mixin' or 'trait' in OOP).

By extracting this concern into a Custom Hook it can easily be reused by different components, as well as composed by other Custom Hooks. This was previously possible using Higher Order Components, Render Props and the (really old) React Mixins concept, but Hooks addresses problems with each of these previous approaches.

If you want to know more about how Hooks improves over these previous approaches, see my previous comment: https://news.ycombinator.com/item?id=19074469

[1]: https://reactjs.org/docs/hooks-custom.html

I can't speak for everyone, but the reusability with custom hooks looks really nice and better readability than using say HOCs.

I'd encourage you to read through the Hooks docs [0], which explain the motivations, and Dan Abramov's posts on some of the internals [1] and what problems they're meant to solve [2].

[0] https://reactjs.org/docs/hooks-intro.html

[1] https://overreacted.io/why-do-hooks-rely-on-call-order/

[2] https://dev.to/dan_abramov/making-sense-of-react-hooks-2eib

I've been working with hooks for quite a while now; its main benefit is composability - before hooks up you rely on Higher order components (HOCs, HOFs but in component rendering) to provide composability of component behaviour - this is messy, very messy, and not performant.

By using hooks the logic tidies up massively (so working on it becomes a lot quicker) and several hard to diagnose performance bottlenecks disappear.

The 'not classes' stuff is a side benefit.

To add to the other answers, the type-ability of hooks is so much nicer. useContext means I'm going to be using context a lot more in TypeScript code now that I don't have to add a bunch of type definitions to every component I want to use it in.

You should think about it in is this way - class components do not actually control its state. Using classes is just a convention supported by React that allows components to express their intention about what state they should have and how it should be updated, so it is just a form of interface. And hooks is a different way to interact with same underlying subsystem of the React, but they allow you to abstract, reuse and compose the logical parts of the interaction with the state.

Not specific to React, but with CommonJS modules you can use module scope instead of global scope to get private methods and variables, which the function can access via the closure.

    var foo = 1;
    var bar = x => x++;
    module.exports = function baz() { return bar(foo) }

I find this much more simple then classes. I even consider it an anti-pattern to make a class for something this simple.

For the vast majority of web apps, you’re going to need state that changes over time. Making individual components immutable is a nice architecture choice for several reasons, and hooks doesn’t really change that. Hooks just provide a way to plug state (which can change over time) into your components, which is something you already had to do. Where you were previously using class components, HOCs, or render props, you can now optionally use hooks, which have some well-documented advantages.

It's no longer about function. It's a component that happens to use `function` as an implementation detail.

Closures are poor man's objects and vice versa.

Well, when React first came out no one was convinced by it. It took more than 2 years, I guess, before everybody suddenly got convinced and started claiming it was the best thing and so on.

This also ties in very cleanly with graphQL:

  import gql from 'graphql-tag';
  import { useQuery } from 'react-apollo-hooks';
  
  const GET_DOGS = gql`
  {
    dogs {
      id
      breed
    }
  }`;

  const Dogs = () => {
    const { data, error } = useQuery(GET_DOGS);
    if (error) return `Error! ${error.message}`;
  
    return (
      <ul>
        {data.dogs.map(dog => (
          <li key={dog.id}>{dog.breed}</li>
        ))}
      </ul>
    );
  };

https://github.com/trojanowski/react-apollo-hooks

A variation on Elm? Why not just Elm?

reasonml <3

There is a blogpost from dan abramov about using setInterval with hooks: https://overreacted.io/making-setinterval-declarative-with-r...

How is this different to using a React component installed from npm? You can look inside them if you want to, but don't have to. That is the goal of abstraction.

If you want to have no abstraction and show all state in your component, just don't extract any into Custom Hooks. Then it's really not very different to a class component.

The primary tip is: don't refactor. It's unlikely to solve any problems if you already have working code in which you've already dealt with all the hassles of HoCs and such. You can just start using it in new code to avoid having to deal with it for that.

Do it piece by piece. There's no need to do it all at once, so start incorporating it where it makes sense when opportunity shows itself. By doing a massive rewrite you're just inviting badly structured code.

We’re not refactoring anything at FB and don’t recommend you to either!

We mostly use Hooks in new code.

Why refactoring? It might be marginally better, but it doesnt mean what has been written in the past is wrong. Plus unless you have very robust test coverage, refractoring at this scale is going to introduce more bugs than the marginal benefits it will bring.

Sure, the "magic" bit of hooks that people are talking about doesn't really affect their type signature

See eg, setState: `function useState<S>(initialState: S | (() => S)): [S, Dispatch<SetStateAction<S>>];`

from: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/ab08...

Use the Context API introduced in 16.3: https://reactjs.org/docs/context.html

This is the same API that or anything that "teleports" state around your tree uses internally.

To be fair Svelte does have the word "magical" in its motto.

I personally don't see it as anymore magical than MobX - it's just taking it a step further by taking advantage of the fact that bindings are created at compile time.

This is consistent with how things are generally done in this framework.

Not a fan of that non-JS svelte magic or the direction these frameworks are going. Fewer lines of code, true, but at the expense of understandability. I just want to get my work done, not learn yet another flavor of the day with non-intuitive implicit behaviors.

The crowd is too fatigued to get excited anymore, there is a handful of outspoken people who will cheer any change for the sake of change or saving up a couple of key strokes at the cost of long term API size and maintenance burden. but it is getting tiresome.

I don't know what is there to cheer about the introduction of a feature that offers nothing new.

Nah, HN is jaded as usual but every React dev I've talked to outside HN has been looking forward to this day with excitement ever since hooks landed in alpha.

I've yet to see HN get truly excited about anything JS-related, particularly React. Personally I'm excited but I wouldn't bother elaborating my excitement here because I know I'll just attract the usual crowd making unfound assumptions about my experience or complaining about hooks not following best practices (like, I don't know, JSX?).

How come?

The official tutorial would be a good starting point:

https://reactjs.org/tutorial/tutorial.html

My suggestion to you is to look into web components (e.g. https://github.com/Polymer/lit-element) for theoretically re-usable components.

React is optional for web development.