Thinking in React Hooks

But as you can see by the blog post, there are tradeoffs between doing something the way people are familiar with, versus a different way that's less familiar, but has different capabilities that might fit the problems better.

Classes map to certain use cases very well; for instance, there's no Hook for "componentDidCatch" or any other error handling.

That being said, you are not losing anything. The tools are simply different (although the old tools are still there, too!).

As the blog post goes into, you can still implement the same _behavior_ as you did with componentDidMount/componentDidUpdate, but with Hooks you can formalize the different patterns you would find when using those methods into a custom hook that you can reuse. This wasn't possible before.

shouldComponentUpdate can be easily replaced with React.memo, a higher-order component that takes a function that compares the previous props to the new props and returns whether they are the same. Wrapping it in React.memo without a custom comparator is the same as PureComponent.

We used to fetch data with HOCs. That never worked well with typescript and was a big problem when you wanted to use more than one (ie, fetching multiple data sources). With hooks we just add separate hooks for each data source we fetch... and the hooks themselves are much simpler than HOCs.

Like the article mentions, hooks move up a layer of abstraction. I'm purging my brain of all the nitty gritty detail of React component lifecycles, because all I ever really cared about was getting data to update at the right time. And now that's the level I can operate at.

Yeah, it doesn't look like standard object oriented code that we're used to. Maybe they could have chosen a different syntax, dunno. But after you get used to hooks, the grass definitely is greener.

The article doesn't show pathological cases using classes, but with hooks it becomes possible to extract complex behaviors involving different lifecycles much more cleanly.

I recently migrated a large React project to use hooks and a lot of repetitive code with lots of repeated patterns (especially things related to data access) is now much more cleaner. Now I can just have something like `useFetch` instead of ten lines of code that I needed just because I was using lifecycle methods.

And the fact that the order of hooks matter is what makes them so easy to abstract. Having them store their own "id" would remove the need for that rule, but then you'd be running at other kinds of bugs.

The order of hooks is only important insofar as they do not change between rendering. That's it. Hooks should always be called, and always in the same order.

A basic React Hooks component has way less boilerplate involved than a class component does, and hooks allow for much better code architecture when it comes to separation of concerns.

Functional components force your component lifecycle into a funnel where the lifecycle becomes obvious, because all the inter-dependencies are already there.

For componentDidMount, you can replicate this easily with hooks:

  const Hello = () => {
    const mounted = useRef(false)
    useEffect(() => {
      if (!mounted.current) {
        mounted.current = true
        console.log("Mounted!");
      }
    }, [])
    return <>Hello</>
  }

  function useMounted(f) {
    const mounted = useRef(false)
    useEffect(() => {
      if (!mounted.current) {
        mounted.current = true
        f()
      }
    }, [])
  }

  const Hello = () => {
    useMounted(() => {
      console.log("Mounted!");
    })
    return <>Hello</>
  }

The useMounted() example, coincidentally, shows a real benefit to hooks: Easy extraction of reusable logic. Hooks are like plugins this way. For example, one hook I've written that I use all the time is this [1], it lets you get a callback every time your component resizes. If you were to do this with a class-based component, you'd have to use an ugly HOC, which results in lots of unnecessary wrapping/nesting.

For componentDidUpdate, useMemo() is arguably easier to deal with.

[1] https://gist.github.com/atombender/b95bbd2014f6a3ec303b843a9...

My main complaint with hooks is people seem to think they always need them. I've seem components where every single piece of data, no matter how trivial, is slapped into a useMemo(). It becomes a lot of mental overhead to trace through them all, especially confirming the useMemos have the correct dependencies specified. Especially when the vast majority of the time, useMemo just isn't needed.

With my hooks I've not gotten that visibility but that's probabbly just me getting used to hooks and how to write them better in a way that makes things as clear as the old lifecycle methods.

It doesn't help that I'm bit of a noob as far as web development goes and most examples I look at are pretty straight forward simple apps for teaching the concepts ... but my questions start when things start scaling up.

There is a huge need for them to have abstractions which provide structure and consistency without being hidden behind too much magic. React in general, redux, and hooks, to me all work to fill this need in a way which is superior to alternative tools. Specifically you can learn how they work in ten minutes or less.

Of course ecosystem variety is critical and there are no doubt many cases where mobx, non-hooks, or similar implementations are the better solution.

It's harder to fix some classes of mistakes/performance issues in the more automatic systems, and the classes of mistakes in the manual dependency tracking world are often easier to spot ("why isn't this updating?" when forgetting a dependency as opposed to "why is this updating too often?" with automatic tracking).

I wouldn't be surprised if there aren't more automatic tracking tools that show up built on top of the basic hook pattern.

My biggest complaint with the React dependency tracking is that empty dependency array [] has different behavior from null/undefined dependency array and so far I always have to look up which one I actually need and I just haven't yet written enough hooks that I've internalized why which behavior is which. It keeps the hook functions terse to write, but it's a small papercut.

Isn't this a constraint imposed by the language? If they could reflectively inspect the code making up a functional component, they could determine the dependencies, am I right?

1) Instead of taking a callback, can your hook return some value instead? I've found that in most cases, it can. That value can then be used to in some other (hopefully shorter) dependency array for a useEffect() hook that is a peer to your original hook.

2) In cases where your hook must take a callback, your hook should store the latest version of the callback in a local useRef. This add a lot more boilerplate code, but it feels safer to me than requiring the caller to manage the identity of the callback.

I've just had to make peace with the fact that I'm going to have to write a lot of boilerplate glue code around hooks. I try not to worry about it and I just hope the next version of hooks is better.

  const useClickOutside = (ref, onClickOutside, isActive) => {
    ...
    useEffect(() => {
      if (!isListening && isActive) {
        addHandlers(handler)
        setListening(true)
      } else if (isListening && !isActive) {
        removeHandlers(handler)
        setListening(false)
      }
      return () => {
        removeHandlers(handler)
      }
    }, [ref, !onClickOutside, isActive])
  }

Anyway, I agree with you that at times they can a bit too abstract for the fellow programmer. Without prior knowledge how hooks work it can be quite tedious to read (without proper documentation at least)

MobX does the same, automatically and under the hood. Vuex from Vue.js, likewise, but (currently) using Proxies. Svelte goes around the limitations of the language at compile-time.

Meanwhile hooks seem to be an attempt to write with performance in mind which in JS often isn't very effective and results in less readable code - unless you really know what you're doing.

I've noticed that even proponents of rewriting everything with hooks often don't fully understand how this thing works and because of that eventually write both less readable and less performant code.

My take is that this is the swan song of React. It solves a class of problems in React that are unheard of in other frameworks.

That's not to say hooks aren't without a downside, it is more to learn, with a different mental model, and their own edge cases. But having used hooks exclusively for a larger project, I couldn't imagine going back to lifecycle methods.

> or example, one of them has 4 setState() calls after each other instead of combining them.

You would still need one line for each state property set:

  this.setState({
    data: newData,
    dimensions: getDimensions(),
    xScale: getXScale(),
    yScale: getYScale(),
  })

In fact that makes things longer in terms of LoC. A bit less noisy though, that'd be true.

> Another manually performs deep equality checks for each key instead of using some library/helper.

Yeah well, I think this is completely fair if you want to "compare oranges with oranges". If the author were to include external libraries, then they would no longer be comparing "Reach with hooks" with "classic React", but with "classic React + some X library" instead.

Maybe the code you work on is a special case, but in my experience that sounds exactly like an opportunity to refactor your code into custom hooks, as you mention in your last paragraph.

The primary difference is where the data _flows from_. Like another commenter pointed out, your examples can be done similarly as trivially with Hooks. The difference is that the state is stored in Reagent in a global mutable atom, while the state in React is stored in the React tree, and is tied to the render lifecycle.

This doesn't seem like a huge difference on its face, but in practice it makes for very different experiences navigating a code base.

In Reagent, your data is flowing down via props but also from the side via any number of atoms/subscriptions/etc. In React, you know that your data is always either state local to the component or passed via props.

This isn't even to mention the other various hooks like useEffect, which allows you to coordinate side-effects with changes in data in a composable, locally-scoped way that Reagent does not allow you to do. In order to coordinate side effects, it requires you to keep the description of side effects completely separate from your components, which makes them less composable.

For people who enjoy the way that React Hooks makes you think, and are also interested in ClojureScript (immutable data structures + amazing standard library + hot reloading + macros built into the language), check out https://github.com/Lokeh/hx or its WIP successor, https://github.com/Lokeh/helix (I am the author of these libraries).

    const Counter = () => {
      const [count, setCount] = React.useState(0)
      return (
        <div>
          <p>You have clicked the button {count} times.</p>
          <button onClick={() => setCount(count => count + 1)}>Increment</button>
        </div>
      )
    }

  (ns qlkit-example.core
    (:require [qlkit.core :as ql]))
  
  (defcomponent Counter
    (state {:count 0})
    (render [atts {:keys [count] :as state}]
            [:div [:p "You have clicked the button" count " times."]
                  [:button {:on-click #(ql/update-state! update :count inc)} "Increment"]]))
  
  (ql/mount {:component Counter
             :dom-element (js/document.getElementById "app")})

I'm not aware of such solution in reagent or rum. Something like re-frame comes to mind, but there, all effects are global.

I tend to agree. With a couple of caveats:

On my team we have visual tests that use factory data to just make sure different states of each widget look right. I think it’s pretty valuable as a safety net for CSS refactors. We use Chromatic for this, but they charge per state, so even a medium sized app will get into the $500+ range per month.

I also think that, while in practice every front end I’ve worked on is tightly coupled to the backend (making front-end only testing pretty useless), if you build an “optimistic UI”, you can do it.

We got close to this at my last company, where we used Vuex to implement a kind of a simple dB on the client, and allow server syncs to kind of build up in the background as needed.

You still need to stub some initial requests, but you could test a UI by doing that and then kind of “coasting” in the front end. Eventually you’d hit an interaction that needed the server, but in this way you can test some short sequences of interaction, which is probably enough to test the basic interactions, and leave the E2E tests for actually making sure the front end is wired to the server, db, work queues, etc correctly.

They require Zone.js stuff in Angular and use of ES2015 Proxies in Vue.js. React has neither of these.

Hooks is basically a different syntax describing the same framework.

I personally love them since I no longer need to care about lifecycle methods, but can describe state and state change logic.

Or are you just talking about “pure” functional components? How would you build a full featured application with just those?

I think it’s actually _less_ magical now, because of the required static order of hook invocation. This implies that each component instance has something like an array backing it that keeps track of hooks calls between renders. This array maybe could hold said state value at the index corresponding to the static ordering of that useState call. So then maybe useState just populates the initial value in the array and provides a callback which both sets the value in the array and then queues up a component re-render

React uses simple objects called "fibers" to track metadata for every component in the tree.

When you begin rendering a function component, React creates a linked list of hooks, and attaches the linked list to the fiber so it knows what hooks exist for that component.

Each hook can save some kind of value in the linked list. For `useState`, it's the state value. For `useCallback` or `useMemo`, it's the cached value, and so on.

When you render again, React loops over the hooks linked list, reads the value at that index, and returns it to your component.

Shawn Wang has a talk where he builds a tiny version of hooks in a few lines:

https://www.swyx.io/speaking/react-hooks/

Honestly I don't care at the moment since I'm a user and not the developer of the framework.

But hooks feels so much simpler for me - I can reason about what the component does instead of what framework lifecycle methods it goes through.

It isn't, it's diffed against the previous virtual dom, to create a set of patches, which are then applied to the real tree. This is why modifying the dom directly through refs can result in bugs.

    function doThing(target) {
      console.log(myVar);
      const myVar = target.prop;
    }

If your goal is simply to see what it renders first, that's fine, you simply need to look at what the function returns.

I disagree with your assertion that LSFF is 'backwards' - it is simply not what you are used to.

MSFF could definitely be argued for class-based components, but it's simply not an option for hook-based components.

In this case, there's only 1 result… the author's public repo. So I guess the search worked! But the theme seems to be a personalised one the author created themselves.

But the primary colors remind of Solarized Dark, if that helps: https://www.google.com/search?q=solarized+dark&tbm=isch

const [thing, setThing] = useState(true)

useEffect(() => { console.log({ thing }) }, [thing])

  function Counter() {
    const [counter, setCounter] = React.useState(0);
    React.useEffect(() => {
      const interval = setInterval(() => setCounter(n => n + 1), 100);
      return () => clearInterval(interval);
    }, [])

    return (
      <div>{counter}</div>
    );
  }

  import React, {useState, useEffect} from 'react';
  
  const CounterComponent = React.memo(() => {
    const [counter, setcounter] = useState(0);
  
    useEffect(
      () => {
        let counterTimer = null;
        const incrementCounter = () => setcounter(counter + 1);
  
        // counterTimer is null if it has not yet been started
        if (counterTimer === null) {
          counterTimer = setInterval(incrementCounter, 1000);
        }
  
        // Remove event listener on cleanup - note the remove function signature needs to match the add function sig
        return () => clearInterval(counterTimer);
    }, [counter]
    );

    return <span>{counter}<br/></span>;

  export {CounterComponent};

You've already mentioned in the other comment, that drift is your concern, and that can be fixed easily. Though it has nothing to do with hooks. One has to track the time when the clock starts, and query current time on every tick.

As for creating a setInterval() and tearing it down after every render, you can simply pass an empty deps list, instead of declaraing counter variable as a dep in the array. Or, if you want to keep ESLint happy, declare counter as a dep, but use `setTimeout()` instead of `setInterval`

I took a stab at this (React with TS):

  import * as React from "react";
  const TICK_INTERVAL: number = 1000;

  function App() {
    const [counter, setCounter] = React.useState<number>(0);
    React.useEffect(() => {
      const startTime = Date.now();
      const timer = setInterval(() => {
        setCounter(_ => {
          const timeNow = Date.now();
          return Math.round((timeNow - startTime) / TICK_INTERVAL);
        });
      }, TICK_INTERVAL);
      return () => {
        if (timer) {
          clearInterval(timer);
        }
      };
    }, []);
    return (
      <div className="App">
        <h1>{counter}</h1>
      </div>
    );

But this code wouldn't be that different if you wrote it in class fashion, except you'd be making a few of calls to this. Most of this would go in componentDidMount and the cleanup would go in componentWillUnMount

Where hooks really shine, is if you want to add / extend this functionality.

Say, you now want the counter to pause when you're not looking at that tab, and resume once the browser tab is in focus. Imagine if you had a pageVisibility API hook, and it returns true and false accordingly, based whether or not the tab is visible at any point of time or not.

In a real-world scenario, it'd not be a basic counter, but maybe an API polling for real time data, and user don't want the page to keep on polling when not in focus.

In that case, you'd have two changes: one call to the useVisible hook, and one more to pass the boolean output of this hook into your Effect hook.

  const TICK_INTERVAL: number = 1000;

  function App() {
    const [counter, setCounter] = React.useState<number>(0);
    const startTime = React.useRef<ReturnType<typeof Date.now>>(Date.now());
    const isVisible: boolean = useVisibility(); // assume taken from NPM
    React.useEffect(() => {
      const timer = setInterval(
        () => {
          if (TICK_INTERVAL && isVisible) {
            setCounter(_ => {
              const timeNow = Date.now();
              return Math.round((timeNow - startTime.current) / TICK_INTERVAL);
            });
          }
        },
        isVisible ? TICK_INTERVAL : null
      );
      return () => {
        if (timer) {
          clearInterval(timer);
        }
      };
    }, [isVisible]);
    return (
      <div className="App">
        <h1>{counter}</h1>
      </div>
    );
  }

Now, let's go one step further, and add local-storage / indexed DB for storing these values, on page close. If you close the page, and re-open, it should resume from where it was before closing, and then count up from there - not zero.

All we need now, is another hook, that abstracts away that storage interaction, storing on window.unload and componentWillUnMount, and retrieving value from storage when component mounts for the first time.

After this point, it'd be illuminating to look back and try to combine these three functionalities, using class components with HOC or Render Props pattern; and think about the effort it'd take to decouple and reuse the count-up logic, from the page visibility logic, from the storage logic.

Edit: formatting

    setA(1)
    setB(2)
    setC(3)

On the other hand, if the state setters were called outside of a React event handler (such as a `setTimeout` or somewhere in an async function), each of those would cause a separate render pass, and the `useMemo` callback would end up being called 3 times.

Note that in the upcoming Concurrent Mode, React will batch updates across event ticks by default.

Edit: useEffect performs a side effect every time one of it's dependencies has changed value. Passing an empty array means the effect is only run once (on mount) because there are no dependencies.