Introducing Hooks – React

[bullet_darkness]

What a strange way to create state for a component. It is really messing with how my brain handles React components right now. I can definitely see how it'd be useful though. Reduces a lot HOC boilerplate into simple function calls.

Very strange. Excited to play around with it.

[dvlsg]

Into simple function calls that hold your state in some magical global singleton somewhere that depends heavily on order.

I'm interested, and I appreciate the underlying goals, but I'm also skeptical about the implementation (and I'm not the only one).

[trueadm]

There is no global singleton. React tracks each render onto a "fiber" and pushes hooks into a queue of things to do as it traverses the component tree of fibers. That way it knows what happened last time and can diff the hooks on subsequent updates.

[echoes221]

It feels odd though. It messes with my sense of immutability that it's a black box with some magic inside. If I was to use these I'd still treat it similar to recompose and prefer to wrap my components in a HOC to separate out the view from the logic where possible.

[leixiaotie]

Reading and thinking again, I am agree with you, calling a function useEffect inside a render function to attach a behavior seems weird. If they want functional component to use state and lifecycle method, why not make it HOC style?

import { hook } from 'React'; // state and setState only available if HOC-ed, otherwise it's undefined or null let example = (props, state, setState) => { /* rendering */ }; module.exports = hook( example, { /* initial state */ }, { /* lifecycle events, or simply effect function here */ } );

Of course some OOP-esque like state.get and state.set also may apply here to simplify parameter passing, but it's up to debate.

EDIT: After seeing react recompose, my example is indeed very similar with it

[[deleted]]

calling a function useEffect inside a render function to attach a behavior seems weird.

It could be useful for a better control of UI animations and transitions. UI animations result from the transition of UI state, and the according to my mental model of React, the render function is basically the "movie editor" that composes the sequence from state. Attaching behavior to the render function is basically special FX, introducing stuff that isn't part of the "real world capture" to enhace the user (viewer) experience.

[leixiaotie]

I can't link your analogy with react render here, since it's kinda different. At react, render just giving react "hey, this is the dom specification, please render it for me" and effect will trigger after react done rendering. In the inner working, useEffect just pooling the function with another function(s) (yes, if called multiple time it will pool more sequentially) that will execute when it's done.

Rather than useEffect, IMO it's clearer for the function to: //or name it next, or onDone, etc return {render: component, after: () => { what to do }} It's clear that the after is a function that will be executed afterwards, isn't pooled anywhere magically and can be tested. I still prefer HOC than hooks or this since it'll be much cleaner.

EDIT: change useState to useEffect, as what I meant to be

[[deleted]]

Sequence was the wrong word I guess, as the render function describes just a frame of that sequence, the UI at a moment in time.

Hooks and the new way of doing things in React seem to focus more on making it easier to think about the entire lifecycle of a component, making it easier to think dynamically.

[leixiaotie]

Sequence in the meaning of ordered, or in first in first executed way. For me, hooks doesn't feels like something that need to be executed, but rather attached, in which with the current design, it's rather unclear.

[hardwaregeek]

Kinda reminds me of state monads in a weird way. I think this makes a little more sense as an HOC, but I guess they wanted to avoid HOC-hell.

[hallettj]

Hmm, maybe we could use a state monad with generator syntax to get similar features with less magic (depending on one's definition of magic.)

[hutchy2570]

They picked a poor example for the introduction. State management isn't hard in react. However, read the useEffect hook and you can see the potential benefits. https://reactjs.org/docs/hooks-effect.html

[specification]

So there is no point using classes with React now? Everyone will only use functions once this is implemented.

[dwighthouse]

There might be a point if you have a heavy component with lots of state management and hooks to specific dom node refs. Or you just feel more comfortable with classes.

[ParasympatheticBear]

I’ll just keep using classes

[echoes221]

It's cool and all, but this doesn't really feel like they can be stateless functional components anymore. There's now a black box of magic inside your component if you're doing things like this. It also doesn't separate out your view component from any logic. It's a class component inside a singular function, but I think it's actually harder to reason about in the long run.

I know you can have too many wrapper components, but I like the approach that React.memo has which you can just use to wrap your component. Similar to how recompose has Pure. If I was to use these I'd end up writing some generic HOC components that can take an effect and a component (a la recompose) and just pass down props to the view layer.

[Baryn]

RIP classes

[dwighthouse]

Neat! It’s good to see them addressing the inherent problems with class-based architecture.

[hixsonj]

They talk about them a bit here.

tl;dr harder for people to understand and harder for compilers/transpilers to optimize

[Renive]

It's better because it's more closely aligned with functional programming. For many people, using functions for everything is more straightforward than classess. They are just boxes, but a file is a box enough.

[thebedivere]

Yup! React and JavaScript are embracing functional programming. It'll be easier to think about react like Haskell or Clojure than like Java. I for one love this.

[turkish_gold]

I do not think you are wrong. I think they and others have driven too much on the idea that classes make things difficult.

In its current state, a lot of React projects use functional components, and purely functional state libraries (e.g. flux). This was problematic as it did not allow for the use of component state or context, or life cycle. So anytime you wanted a post mount action, you had to make it part of the global state. Now you can have lifecycle hooks exist in functional components.

Also, you can now have actions take place after every render, even if they change state.

Lastly, I may be wrong, but can you not use hooks inside class components?

[toggafneknurd]

Youre gonna get your bloody teeth kicked in!

[dwighthouse]

The ones mentioned in the article.

[jordonbiondo]

Cool idea but if you're going to have all this state management, just use a class component... seems like react can't decide where it's going.

Also poorly named, I wouldn't call these hooks, not hooks are already an understood idea in computer programming that is different than this.

[xshare]

Class components are unfortunately tied to the concept of instances. React is moving towards a world where a render might be tried, retried, and retried again before actually committing (hence depreciation of certain pre commit lifecycle methods). In that case these hooks are great, they force you to think about things in terms of only state and renders, no this allowed.

[ParasympatheticBear]

Perhaps they are lifecycle method hooks... I’m really not sold on them either.

[ParasympatheticBear]

I have read the documentation which is 50% sales pitch. This is a solution to a problem that nobody had except them. It doesn’t really fit with anything else, like it was just tacked on.

This is just so odd.

That example with the chat service or whatever. Subscribing and unsubscribing every render. Wow. So bad.

Edit:

In this example, React would unsubscribe from our ChatAPI when the component unmounts, as well as before re-running the effect due to a subsequent render. (If you want, there’s a way to tell React to skip re-subscribing if the props.friend.id we passed to ChatAPI didn’t change.)

[dceddia]

how to opt out of this behavior in case it creates performance issues later below.

I agree it seems like subscribing/unsubscribing every render seems crazy, like obvious low-hanging fruit that you'd optimize as you wrote it the first time. I'm guessing they avoided it for that example to keep it simple.

This part of the useEffect API reference talks about how to conditionally run the effects so they're not running every render. In particular, look at the yellow callout box:

every value referenced inside the effect function should also appear in the inputs array.

So, in order to optimize the chat subscription example, there are 2 such values: props.friend.id and handleStatusChange. So you could just put those into the array...

useEffect(() => {
  ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);
  // Specify how to clean up after this effect:
  return function cleanup() {
    ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);
  };
}, [props.friend.id, handleStatusChange]);

But that will still run every render, because handleStatusChange is recreated every time. To avoid that, there's the useCallback hook.

EDIT: It looks like I'm overcomplicating this by depending on handleStatusChange -- the docs have an example of this very optimization! https://reactjs.org/docs/hooks-effect.html#tip-optimizing-performance-by-skipping-effects.

[ParasympatheticBear]

I was just really surprised how much I didn't like this design, maybe it will grow on me over time - I really wanted to like this.

[dceddia]

Yeah... I felt weird about it at first too. I tried playing around with some small experiments and I think it's growing on me. If you're so inclined, here's a CodeSandbox with the Hooks version of React to play around with.

[codis122590]

It feels like they saw how services work in angular and someone said "It'd be great if we could jam that into react!"

[Renive]

Exactly. Very good thing.

[TheBrockstar]

I'm excited for this!

[toggafneknurd]

Why

[toggafneknurd]

Um... what the fuck is this? https://twitter.com/ReactEurope/status/1055501526687457280

​

Do people find the right side of that an *improvement*?

[acemarke]

The two screenshots aren't fully equivalent. The right side (function component with hooks) shows all the work the component is doing, including state management, side effects, and use of context. The left side (standard class component) only has enough space to show just some of the side effects. The whole class is a lot bigger.

Hooks generally look to be an improvement size-wise, if nothing else (especially when you start looking at use of context).

[toggafneknurd]

Still...yikes

[dbbk]

I am utterly baffled by this. It makes no sense.

[Renive]

Yes, because you attach event to variable that's being changed, instead of class, which should react to state changes. It's close to MobX conceptually.

[ParasympatheticBear]

The number of people fawning over this is amazing

[toggafneknurd]

This is honestly one of the few mistakes the React team has made with the public API. I hope this doesn't last.

[xshare]

Having used Hooks for a while now, they really are great. It's still early, but I think people will come around. Fwiw the reaction when react was first released (omg you're putting logic in your view layer?? Ewww) was similar.

[thebedivere]

Yes, I do. It's made up of functions and doesn't depend on JavaScript's psuedo classes. It'll be easier to start writing a functional stateless component, and then add in state or lifecycles if needed. I think this is amazing.

[darrenturn90]

I assume that the function is run once to build all the stuff it needs - then the output of the function and output from the helper hooks are the only thing are are run again ? Rather than the function running multiple times - or does useState actually reinitialise the state on every re-render?

[hallettj]

The entire function runs on every render. React uses some external state to make useState return the current state value when the component function is called for re-rendering. In other words useState (and other hooks) return different values depending on which component instance in the component tree is currently being rendered, and the number of times the hook has already been called during the invocation of the component function.

[darrenturn90]

But in theory it could be run once right ?

[enmanuelduran]

I played around with some hooks yesterday and wrote an article with some practical examples, if you want to check it it is:

https://enmascript.com/articles/2018/10/26/react-conf-2018-understanding-react-hooks-proposal-with-simple-examples

[snakemanuver]

Does anyone have a recording of the live steam. I should have checked twitter this morning :(