Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

reactjs.org

Post reply on HN
Print view View original

151–160 of 181 posts

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

#151

Post by Vinnl »

baddox wrote: post #134
Vinnl wrote: post #106

Earlier quoted context omitted.

There's nothing wrong with `setState`, in my opinion. However, it does do magic. Although it might feel like it immediately sets the state to be what you provide it as argument, it actually schedules a state update to be performed later when React feels like it. That's why it's best practice to provide an updated function rather than a plain object: if the new state depends on the previous one, and you read the previ…

I think the more relevant analogy between hooks and setState is that setState uses essentially the exact same technique as hooks to keep track of which component is calling it, namely, React keeps track of which component it’s rendering, and setState mutates some “global” state. A lot of people seem to think that setState stores state in the instance of the React component class, but that’s not the case (and that wou…

Ah yes, that is a more relevant analogy.

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

#152

Post by rhacker »

Everyone is calling this "magic" yet under the hood it's the same "magic" behind a react component class setState function. It's literally the same thing, but lets you pass these functions to descendents. It essentially decouples that "feature" from being tied to the class component. That's just excellent.

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

#153

Post by jakelazaroff »

linkmotif wrote: post #149
jakelazaroff wrote: post #141

Earlier quoted context omitted.

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.

Fun approach! But I don’t think that’s it? Just not the same kind of zero-effort awesomeness right? Also uses the context API for something it’s not intended for.

I'm not sure what you mean — the context API is specifically for moving data around the component tree without prop drilling. What are you talking about with regard to recompose?

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

#154

Post by WorldMaker »

sudhirj wrote: post #36
devit wrote: post #25

Are hooks being accepted as a good design by the community? It seems to me that the lack of a parameter explicitly indicating the component and the reliance on hook ordering to match them across calls of the component function make them a bad design, but I might very well wrong and would be happy to be convinced otherwise.

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

It shouldn't feel that unintuitive, it's not actually that uncommon in JS and/or any other programming language that the order of calls matter. It's basically a fundamental quirk of all (side effect full) imperative code. It's the languages where call order doesn't matter than are much more rare, and are more generally considered unintuitive (for instance, Haskell pure functions).

The cannot be called in conditionals and/or loops need is certainly more rare, but it's also not necessarily an exotic thing: so much of debugging and performance work in the average imperative language is often finding things called conditionally or in loops that shouldn't be and moving them up/out. Some things like setInterval or certain types of awaiting large expensive computations you almost wish you had lint errors in place to forbid them in loops (or even sometimes to forbid them from conditionals in cases where they don't happen cause subtle bugs).

I don't think this is contrary to JS at all. It's different and may take some time getting used to, but "call order matters" isn't unusual for JS (especially in the world of DOM manipulation).

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

#155

Post by dvlsg »

danabramov wrote: post #116
palerdot wrote: post #107

Earlier quoted context omitted.

One thing that looks 'magical' is how does the setWhatever function lets React know that state has changed and has to re-render? Is there any info/writeup on this anywhere?

Pretty much the same way as this.setState in a class does. React knows which component is rendering at any point in time — so it knows which component useState() call corresponds to. I think this explanation is quite accessible: https://medium.com/@ryardley/react-hooks-not-magic-just-arra...

> React knows which component is rendering at any point in time — so it knows which component useState() call corresponds to.

Personally, I think that may be the piece that makes it feel a bit magical. With `this.setState()`, usage of `this` makes me feel like I know how the component and the state are linked.

With hooks, however, there's no obvious link to the component in the code. I'm grabbing `useState` off of the shared react module, `useState` is not passed into the component, and I don't have to reference the component itself at any point while using hooks. The new sets of rules you have to follow to make things line up correctly play a part, as well.

Of course that may be how `this.setState()` does it anyways - you know better than I do, obviously. Maybe the usage of `this.setState()` made me feel confident in something I didn't actually understand under the hood. But at least for me, that's why `useState()` feels a bit magical at first glance compared to `this.setState()`. Not _too_ magical, and not enough to scare me away from using hooks, but still a bit.

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

#156

Post by WorldMaker »

Vinnl wrote: post #59
aurbano wrote: post #51

Earlier quoted context omitted.

I follow this sometimes but having a wide range of patterns in the same project feels so dirty in a way... Although it makes sense, refactor only when you need to.

I understand. I feel like the consideration to make is: will the benefits of hooks outweigh the benefits of mixing different patterns? If your estimate is that it won't, I'd stick to the current patterns for a while, rather than rewriting them now - because I'm quite sure the benefits of hooks aren't going to be worth the rewrite.

I feel like most production React I've seen already has a mixture of components written as classes versus ones written as functions versus functions and classes written to be HOCs. Adding Hooks in most codebases won't make most of them feel anymore "mixed" than they already were.

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

#158

Post by beaconstudios »

WorldMaker wrote: post #145
beaconstudios wrote: post #54

Earlier quoted context omitted.

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.

The syntax isn't even that weird? It's just function calls. The only "weird" bit is using array destructuring for multi-return and that's been in ES/JS for some time now, and definitely shouldn't look that weird to anyone that has worked in Python, as one example (and C# now supports destructuring even).

The weirdness is because the state or context seemingly comes from thin air - there's no explicit location for the data.

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

#159

Post by basil-rash »

sephoric wrote: post #138

Now we can finally have completely clean data loaders: Create a data loader hook that loads your data in a one-shot effect (you pass it the identities array), and which returns either a valid view (an error or loading view) and no data, or no view and valid data of type T. Then you can just do: const loader = useDataLoader(async () => { const a = await getDataA(); const b = await getDataB(a); return b.data; }); retur…

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 (
      
        {data.dogs.map(dog => (
          {dog.breed}
        ))}
      
    );
  };
https://github.com/trojanowski/react-apollo-hooks

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

#160

Post by james_s_tayler »

danabramov wrote: post #57
BilalBudhani wrote: post #44

Hooks seem to be a drastic change in how we're going to write React components in the future. I'm quite satisfied with the current way of writing components which is to me is very explicit (with no magic). With Hooks React is taking a different direction from their original motto of explicit design patterns. From the looks of it, Hooks seems like a counter-intuitive design pattern but traditionally that's how most of…

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

"on a single page" - I see what you did there.
Post reply on HN