DEV Community: Boris Serdiuk

An opinionated guide to React hooks

Boris Serdiuk — Thu, 10 Feb 2022 20:36:36 +0000

React API offers you multiple built-in hooks. However not all of them are equally useful. Some you can see almost in every app or a library, some others you will not need unless you are writing a super special module. React documentation gives some guidance where to use hooks, but in a super neutral format. In this article I will try to dive deeper into the real use-cases, giving my opinion on how every hook should be used.

Basic hooks

In their docs, React already has separation on basic and advanced hooks:

Basic

useState
useEffect
useContext

Advanced

useReducer
useRef
useLayoutEffect
useImperativeHandle
useCallback
useMemo
useDebugValue

The docs do not clarify reasons for this separation, however it is important for understanding the hooks API. Basic hooks cover some common use-cases, their purpose is clear and does not cause any controversy in the discussions.

Advanced hooks

You likely do not need to use these hooks. Almost every task can be solved without these, you will get clean and idiomatic React code. Every time you use a hook from this list, you are making a compromise and stepping off the normal "React-way". You need to have a good reason and explanation to use a hook from the advanced list. In this article we cover typical valid and invalid use-cases for advanced hooks.

useReducer

This is a form of setState for complex values. Sometimes you store not just one value, but a combination of related values. For example, state of a data-fetching process:

interface DataFetchingState {
  data: Data | null; // fetched data
  isLoading: boolean; // whether data-fetching is in progress
  error: Error | null; // error information, if data-fetching attempt failed
}

This can be solved using a few separate useState hooks. However you may want to enforce some constraints in this state, for example prvent a combination of {isLoading: true, error: anError}. Previous error needs to be removed when a new data-fetching attempt begins. useReducer allows you to control state changes via wrapping them into actions. This way you can only dispatch a certain predefined set of actions, which will properly handle the respective state changes.

When to use it? I would recommend switching to useReducer when you have 3 or more related state values. Fewer values work just fine via useState, useReducer would be an overkill, it will require you to write more code to handle a simple case.

When not to use it? If you have multiple state values, but they all are unrelated. For example, you have multiple form fields:

const [firstName, setFirstName] = useState("");
const [lastName, setLastName] = useState("");
const [email, setEmail] = useState("");

These fields do not depend on each other, user can fill them in any order. Even though there are 3 different values, they are not related, so no need for useReducer.

useRef

Originally, refs in React provided a way to interact with DOM nodes directly. However, later this concept evolved into a general storage of any kind of value between component renders. useRef is also recommended as a replacement for class instance properities, this.something, which is not available in functional components.

When to use it?

If you need to access a DOM node, this hook seems unavoidable, however ask yourself first — do I really need to manipulate with DOM by hand? When you go this way, you become in charge of handling state updates properly and integrate with component mount/unmount lifecycle. Basically, you are stepping off one of the greatest power in React – the VDOM. Did you check if there is an option to do the same manipulation by refactoring your CSS? Or can you just read the DOM value inside an event handler via event.target and therefore reduce the number of direct manipulations down to events only?

Then we also have a use-case about storing other content, not DOM nodes. Note, that assigning ref.current = newValue does not trigger a component re-render. If you need this, perhaps it is better to put it into useState?

Sometimes you put the value in ref to later use it inside effect cleanup. However, it is redundant in some cases:

const observerRef = useRef();
useEffect(() => {
  observerRef.current = new MutationObserver(() => {
    /* do something */
  });
  observerRef.current.observe(document.body);
  return () => {
    observerRef.current.unobserve(document.body);
  };
}, []);

Using observerRef is redundant here. The value can be stored as a plain variable:

useEffect(() => {
  const observer = new MutationObserver(() => {
    /* do something */
  });
  observer.observe(document.body);
  return () => {
    observer.unobserve(document.body);
  };
}, []);

This is also much shorter to write!

To sum it up, useRef in your components only if these conditions met:

The value does not depend on component rendering
The value cannot be stored inside a closure of useEffect hook

useLayoutEffect

This is where many people may fall into the trap "misguided by the name". If the hook name contains layout, I should put all my layout operations there, shouldn't I? However, this is not always the case. The primary difference between useEffect and useLayoutEffect is the timing of the operation. useEffect is asynchronous and useLayoutEffect is synchronous. Let's look at a simple demo:

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    console.log("effect");
  }, [count]);

  useLayoutEffect(() => {
    console.log("layout effect");
  }, [count]);

  function onClick() {
    setCount((count) => {
      console.log("during update");
      return count + 1;
    });
    console.log("after update");
    Promise.resolve().then(() => {
      console.log("microtask after update");
    });
  }

  return (
    <>
      <button onClick={onClick}>increment</button>
      <div>{count}</div>
    </>
  );
}

This is what we see in the console after clicking the button:

"during update";
"after update";
"layout effect";
"microtask after update";
"effect";

Effect is the most delayed operation here. It gets called when all other updates completed and you can read the final DOM state (or do any other side effects). Layout effect fires right after React finished its updates, but before browser repainted the page. It is useful to apply some adjustments before user sees fully rendered page, however beware of forced sychronous layouts which may slow down the rendering performance, especially, if you call that effect often. Also, keep in mind that because layout effect is synchronous, some other operations may not be completed yet. I happened to see this code:

useLayoutEffect(() => {
  // delaying operation because something is not ready yet
  const frame = requestAnimationFrame(() => {
    /*do something*/
  });
  return () => {
    cancelAnimationFrame(frame);
  };
}, []);

This is redundant, here we just reinvented a wheel (useEffect). This code will do the same, but much simpler:

useEffect(() => {
  /*do something*/
}, []);

Also note if useLayoutEffect tries to execute during server-side rendering, it prints you a warning. This is also likely a sign you should be using useEffect instead.

useCallback

When we define an inline function inside our functional component, we are getting a new instance on each render

function Demo() {
  const handler = () => {};
  return <div>something</div>;
}

Usually, it does not cause any inconvenience. However, sometimes it happens, most often when the handler is a dependency of useEffect:

const handler = () => {};

useEffect(() => {
  // heavy side effect is here
}, [handler]);

Whenever handler changes, "heavy side effect" will be executed again. However, because handler function is inline, the change will be detected on every component render. useCallback comes to the rescue:

// now we have the same instance of `handler` on each render
const handler = useCallback(() => {}, []);

useEffect(() => {
  // heavy side effect is here
}, [handler]);

However it only works that easy with [] in the dependencies array. More likely, there will be something, sometimes another function:

const doSomething = () => {};
const handler = useCallback(() => {}, [doSomething]);

Now we need to useCallback-ify this too:

const doSomething = useCallback(() => {}, []);
const handler = useCallback(() => {}, [doSomething]);

This way we are piling up a fragile pyramid of callbacks, if any of them will not memoize properly, the heavy side effect will be executed regardless our efforts. Very often it happens when we receive a value from props:

function Demo({ onChange }) {
  const handler = useCallback(() => {
      onChange();
      // do something else
  }, [onChange]);

  useEffect(() => {
    // heavy side effect is here
  }, [handler]);
}

// oh no! Our side effect got out of control!
<Demo onChange={() => {}}}>

We might useCallback-ify the handler in the parent component too, but how do we ensure we captured all instances? The code may be split in different files and even repositories. The effort seems futile.

Fortunately, there is a more elegant solution to this problem, React documentation mentions this:

// custom reusable hook
function useStableCallback(fn) {
  const ref = useRef();
  useEffect(() => {
    ref.current = fn;
  }, [fn]);
  const stableCallback = useCallback((...args) => {
    return ref.current(...args);
  }, []);
  return stableCallback;
}

This way we are getting back to a simple dependency-free useCallback, which relies on ref to deliver the actual latest value. Now we can refactor our code and remove all manual dependency tracking:

function Demo({ onChange }) {
  const handler = useStableCallback(() => {
    onChange();
    // do something else
  });

  useEffect(() => {
    // heavy side effect is here
  }, [handler]);
}

Now we do not have to worry about onChange reference, handler will be called with latest instance, whichever it was at the moment of calling.

When not to use it? Do not useCallback if you have a cascade of functions depending on each other. Consider refactoring via useStableCallback custom hook. For functions in useEffect dependencies, wrap only the the direct dependency, all other functions may remain inline arrow functions, keeping your code simple and readable.

When not to use it? Do not useCallback to "optimize" event handlers. There is no evidence that it improves anything. Adding event listeners to DOM-nodes is a super cheap operation, a fraction of millisecond. On the other hand, wrapping into useCallback is also not a free operation, it comes with a cost, more expensive than actually refreshing event handlers. React is already optimized by default, no need over-optimize by hand. If you do not trust me, make your own experiments, try to find a difference and let me know, I will be happy to learn!

useMemo

This is a bigger brother of useCallback. That hook worked only for functions, this one can store any kind of values:

// avoid computing fibonacci number on every render
const fib = useMemo(() => {
  return fibonacci(N);
}, [N]);

Sometimes you integrate with a 3rd-party library and you need to create an object instance, but this one is expensive:

const ace = useMemo(() => {
  const editor = ace.edit(editorRef.current);
  editor.on("change", onChange);
}, [onChange]);

Note, that the hazard of dependencies from useCallback applies here too. Solution is also the same – wrap into stable callback

const onChangeStable = useStableCallback(onChange);
const ace = useMemo(() => {
  const editor = ace.edit(editorRef.current);
  editor.on("change", onChangeStable);
}, [onChangeStable]);

When to use it? When you have a solid proof that your operation is expensive (for example, you compute fibonacci numbers, or instantiate a heavy object).

When not to use it? When you are unsure if the operation is expensive or not. For example, this is unnecessary:

function Select({ options }) {
  const mappedOptions = useMemo(
    () => options.map((option) => processOption(option)),
    [options]
  );

  return (
    <select>
      {mappedOptions.map(({ label, value }) => (
        <option value={value}>{label}</option>
      ))}
    </select>
  );
}

Always bechmark your code before doing any optimizations! There will not be millions of items in options array (in which case we will need to talk about UX in your app). Memoization does not improve anything in render time. The code could be simplified without any harm:

function Select({ options }) {
  const mappedOptions = options.map((option) => processOption(option));

  return (
    <select>
      {mappedOptions.map(({ label, value }) => (
        <option value={value}>{label}</option>
      ))}
    </select>
  );
}

How to useMemo properly: you write the code without any memoization, then confirm it is slow and this slowdown is significant (this is an important step, many potential optimizations will not pass this check). If there is a confirmed improvement, create also a test to ensure that the optimization worked and has an obsevable impact. Do not forget about useMemo dependencies array, any change there will waste all your efforts. Choose your dependencies carefully!

Super advanced hooks

This section could be called "wow, what is that hook?" These hooks have super niche use-cases and if you have one, you likely already know everything this article wanted to say, but here we go anyway.

useImperativeHandle

React tries to be a declarative framework, where you are describing what you want to get and then React internally figures out how. However, in real world, there are many imperative APIs, for example is focusing DOM elements programmatically.

Let's say we are building an custom Input component:

const Input = React.forwardRef((props, ref) => {
  return <input ref={ref} />;
});

It is a good practice to wrap component into forwardRef to allow consumers to interact with the underlying native input, for example focus it via inputRef.current.focus(). However, sometimes we may want to add some extra code when the native element gets focused. useImperativeHandle helps us to proxy the call:

const Input = React.forwardRef((props, ref) => {
  const nativeInputRef = useRef();
  useImperativeHandle(ref, () => ({
    focus: () => {
      nativeInputRef.current.focus();
      // do something else, if needed
    },
  }));

  return <input ref={nativeInputRef} />;
});

Note that this way we also encapsulating access to the underlying <input> element, only focus function is exposed. This is also useful when you want to enforce API boundaries for your components and prevent unauthorized access to element internals.

useDebugValue

React recommends to extracting group of related hooks into a function and treat it as a custom hook. For example we created a custom useStableCallback hook above:

function useStableCallback(fn) {
  const ref = useRef();
  useEffect(() => {
    ref.current = fn;
  }, [fn]);
  const stableCallback = useCallback((...args) => ref.current(...args), []);
  return stableCallback;
}

We can have multiple other custom hooks, for example useDarkMode(), which returns you the current color scheme of the page:

const darkMode = useDarkMode();

<div style={{ background: darkMode ? "darkblue" : "deepskyblue" }} />;

How can we inspect the latest return value of useDarkMode. We can put console.log(darkMode), but the log message will be out of the context. useDebugValue connects the value with the hook it was called from:

function useDarkMode() {
  const darkMode = getDarkModeValueSomehow();
  useDebugValue(darkMode);
  return darkMode;
}

In React devtools we will see this value along with other components props:

here is our hook in the bottom left corner

Conclusion

There is nothing else to add in the end. I hope you found this guide useful. Happy coding!

If you want to see more content from me, please check also my Twitter account: @justboriss

Popular patterns and anti-patterns with React Hooks

Boris Serdiuk — Thu, 11 Mar 2021 18:25:58 +0000

It's been more than 2 years since Hooks API was added to React. Many projects already adopted the new API and there was enough time to see how the new patterns work in production. In this article I am going to walk you through my list of learnings after maintaining a large hooks-based codebase.

Learning #1. All standard rules apply

Hooks require developers to learn new patterns and follow some rules of hooks. This sometimes makes people think that new pattern dismisses all previous good practices. However, hooks are just yet another way of creating reusable building blocks. If you are creating a custom hook, you still need to apply basic software development practices:

Single-responsibility principle. One hook should encapsulate a single piece of functionality. Instead of creating a single super-hook, it is better to split it into multiple smaller and independent ones
Clearly defined API. Similar to normal functions/methods, if a hook takes too many arguments, it is a signal that this hook needs refactoring to be better encapsulated. There were recommendations of avoiding React components having too many props, same for React hooks – they also should have minimal number of arguments.
Predictable behavior. The name of a hook should correspond to its functionality, no additional unexpected behaviours.

Even though these recommendations may look very obvious, it is still important to ensure that you follow them when you are creating your custom hooks.

Learning #2. Dealing with hook dependencies.

Several React hooks introduce a concept of "dependencies" – list of things which should cause a hook to update. Most often this can be seen in useEffect, but also in useMemo and useCallback. There is a ESLint rule to help you managing an array of dependencies in your code, however this rule can only check the structure of the code and not your intent. Managing hook dependencies is the most tricky concept and requires a lot of attention from a developer. To make your code more readable and maintainable, you could reduce the number of hook dependencies.

Your hooks-based code could become easier with this simple trick. For example, let's consider a custom hook useFocusMove:

function Demo({ options }) {
  const [ref, handleKeyDown] = useFocusMove({
    isInteractive: (option) => !option.disabled,
  });
  return (
    <ul onKeyDown={handleKeyDown}>
      {options.map((option) => (
        <Option key={option.id} option={option} />
      ))}
    </ul>
  );
}

This custom hook takes a dependency on isInteractive, which can be used inside the hook implementation:

function useFocusMove({ isInteractive }) {
  const [activeItem, setActiveItem] = useState();

  useEffect(() => {
    if (isInteractive(activeItem)) {
      focusItem(activeItem);
    }
    // update focus whenever active item changes
  }, [activeItem, isInteractive]);

  // ...other implementation details...
}

ESLint rule requires isInteractive argument to be added to useEffect dependencies, because the rule does not know where this custom hook is used and if this argument is ever changing or not. However, as a developer, we know that once defined this function always has the same implementation and adding it to the dependencies array only clutters the code. Standard "factory function" pattern comes to the rescue:

function createFocusMove({ isInteractive }) {
  return function useFocusMove() {
    const [activeItem, setActiveItem] = useState();

    useEffect(() => {
      if (isInteractive(activeItem)) {
        focusItem(activeItem);
      }
    }, [activeItem]); // no ESLint rule violation here :)

    // ...other implementation details...
  };
}

// usage
const useFocusMove = createFocusMove({
  isInteractive: (option) => !option.disabled,
});
function Demo({ options }) {
  const [ref, handleKeyDown] = useFocusMove();
  // ...other code unchanged...
}

The trick here is to separate run-time and develop-time parameters. If something is changing during component lifetime, it is a run-time dependency and goes to the dependencies array. If it is once decided for a component and never changes in runtime, it is a good idea to try factory function pattern and make hooks dependencies management easer.

Learning #3. Refactoring useEffect

useEffect hook us a place for imperative DOM interactions inside your React components. Sometimes they could become very complex and adding dependencies array on top of that makes it more difficult tor read and maintain the code. This could be solved via extracting the imperative DOM logic outside the hook code. For example, consider a hook useTooltipPlacement:

function useTooltipPosition(placement) {
  const tooltipRef = useRef();
  const triggerRef = useRef();
  useEffect(() => {
    if (placement === "left") {
      const triggerPos = triggerRef.current.getBoundingElementRect();
      const tooltipPos = tooltipPos.current.getBoundingElementRect();
      Object.assign(tooltipRef.current.style, {
        top: triggerPos.top,
        left: triggerPos.left - tooltipPos.width,
      });
    } else {
      // ... and so on of other placements ...
    }
  }, [tooltipRef, triggerRef, placement]);
  return [tooltipRef, triggerRef];
}

The code inside useEffect is getting very long and hard to follow and track if the hook dependencies are used properly. To make this simper, we could extract the effect content into a separate function:

// here is the pure DOM-related logic
function applyPlacement(tooltipEl, triggerEl, placement) {
  if (placement === "left") {
    const triggerPos = tooltipEl.getBoundingElementRect();
    const tooltipPos = triggerEl.getBoundingElementRect();
    Object.assign(tooltipEl.style, {
      top: triggerPos.top,
      left: triggerPos.left - tooltipPos.width,
    });
  } else {
    // ... and so on of other placements ...
  }
}

// here is the hook binding
function useTooltipPosition(placement) {
  const tooltipRef = useRef();
  const triggerRef = useRef();
  useEffect(() => {
    applyPlacement(tooltipRef.current, triggerRef.current, placement);
  }, [tooltipRef, triggerRef, placement]);
  return [tooltipRef, triggerRef];
}

Our hook has become one line long and easy to track the dependencies. As a side bonus we also got a pure DOM implementation of the positioning which could be used and tested outside of React :)

Learning #4. useMemo, useCallback and premature optimisations

useMemo hook documentation says:

You may rely on useMemo as a performance optimisation

For some reason, developers read this part as "you must" instead of "you may" and attempt to memoize everything. This may sound like a good idea on a quick glance, but it appears to be more tricky when it comes to details.

To make benefits from memoization, it is required to use React.memo or PureComponent wrappers to prevent components from unwanted updates. It also needs very fine tuning and validation that there are no properties changing more often than they should. Any single incorrect propety might break all memoization like a house of cards:

// Detect dark theme var iframe = document.getElementById('tweet-1320888155504103424-632'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1320888155504103424&theme=dark" }

This is a good time to recall YAGNI approach and focus memoization efforts only in a few hottest places of your app. In the remaining parts of the code it is not worth adding extra complexity with useMemo/useCallback. You could benefit from writing more simple and readable code using plain functions and apply memoization patterns later when their benefits become more obvious.

Before going the memoization path, I could also recommend you checking the article "Before You memo()", where you can find some alternatives to memoization.

Learning #5. Other React API still exist

If you have a hammer, everything looks like a nail

The introduction of hooks, made some other React patterns obsolete. For example, useContext hook appeared to be more convenient than Consumer component.

However, other React features still exist and should not be forgotten. For example, let's take this hook code:

function useFocusMove() {
  const ref = useRef();
  useEffect(() => {
    function handleKeyDown(event) {
      // actual implementation is extracted outside as shown in learning #3 above
      moveFocus(ref.current, event.keyCode);
    }
    ref.current.addEventListener("keydown", handleKeyDown);
    return () => ref.current.removeEventListener("keydown", handleKeyDown);
  }, []);
  return ref;
}

// usage
function Demo() {
  const ref = useFocusMove();
  return <ul ref={ref} />;
}

It may look like a proper use-case for hooks, but why couldn't we delegate the actual event subscription to React instead of doing manually? Here is an alternative version:

function useFocusMove() {
  const ref = useRef();
  function handleKeyDown(event) {
    // actual implementation is extracted outside as shown in learning #3 above
    moveFocus(ref.current, event.keyCode);
  }
  return [ref, handleKeyDown];
}

// usage
function Demo() {
  const [ref, handleKeyDown] = useFocusMove();
  return <ul ref={ref} onKeyDown={handleKeyDown} />;
}

The new hook implementation is shorter and has an advantage as hook consumers can now decide where to attach the listener, in case if they have more complex UI.

This was only one example, there could be many other scenarios, but the primary point remains the same – there are many React patterns (high-order components, render props, and others) which still exist and make sense even if hooks are available.

Conclusion

Basically, all learnings above go to one fundamental aspect: keep the code short and easy to read. You will be able to extend and refactor it later in the future. Follow the standard programming patterns and your hook-based codebase will live long and prosper.

Things I wish other frameworks grab from Svelte

Boris Serdiuk — Mon, 30 Dec 2019 09:52:57 +0000

After some experience working on a Svelte project, I was very amazed by this framework. Svelte is very innovative and has many interesting features. When I have to switch to another framework, I miss some features and wish the would be available.

Here goes my list of features that I find useful and unique for Svelte. This is not a full list of Svelte features, but rather a list of my favorites, which I wish to be able to use in other frameworks too.

1. Modular API

This is one of the most compelling points of Svelte. It was initially positioned as a framework highly tied to a compiler. This is a special class of frameworks, called disappearing, because their code dissolves with our app code for better compression.

The part of this amazing compression rate is due to the modular API, where features provided via individual modules, which can be omitted if not used

import { createEventDispatcher } from 'svelte'; // not included if you don't dispatch events
import { writable } from 'svelte/store'; // no need for shareable state – don't include this

This modularity allows hello world project on Svelte to be just about 1Kb big (minified+gzipped).

Some other frameworks support this pattern too. You can find this in Preact, for example, but Svelte goes even further and makes all export values tree-shakeable. It means that even parts of a single module can be stripped if they are not used.

However, the major frameworks, like React or Vue, are distributed as a single bundle with all APIs. It would be nice to see them moving towards modularity too.

2. Built-in transition library.

Svelte has built-in helpers for creating animated transitions of elements. You need to import a transition function and apply it to an element

import { fade } from 'svelte/transition';

<div transition:fade>This text will appear with transition</div>

The syntax is short, but also very flexible. You can implement your own transition functions and use them instead of fade used in this example. Svelte documentation covers this process well.

Other frameworks, Vue, for example, also have built-in libraries. But they are mostly based on applying extra class names to entering or leaving elements. Svelte is different, it allows you to specify the entire transition in each frame. All you need is to return a function that defines styles of an element depending on a keyframe t. This is the most trivial example:

function whoosh(node) {
  return {
    css: t => `transform: scale(${t})`
  };
}

Because animation is defined in Javascript and you have access to properties of the DOM node, you can create more complex animations and apply any kind of logic to the transition.

Animating transitions in Svelte is a great experience that other frameworks could pick up too.

3. Use actions

Svelte allows you to mix additional functionality to dom nodes via use: syntax:

<div use:draggable>I am draggable!</div>

Using this syntax you can attach multiple behaviors to the same node

<div use:draggable use:tooltip="Some tooltip">Draggable with tooltip</div>

This is very convenient when you want to apply some special behavior to an element, but you don't want to create an extra wrapper just for that.

Vue and Angular have a similar concept of directives, but React misses this feature, requiring you to write boilerplate code working with refs or create more intermediate components.

4. Classname bindings

It is very common to apply different styles for an element via different CSS class names. In React, we have to manually construct the list of classes to a string, or use some utility libraries, like classnames. Svelte has an elegant syntax for that:

<div
    class="simple" // always rendered
    class:active={isActive} // rendered if isActive == true
    class:selected={isSelected} // can repeat for multiple classes
/>

Angular and Vue have their own class name helpers, but they look like an extra syntax inside of a template:

<div v-bind:class="{ active: isActive, selected: isSelected }" />

The Svelte API is easier to read and modify. I wish other frameworks would adopt the approach from Svelte.

Conclusion

This list of features is not full, of course, but these are the topmost features that make Svelte very unique and practical framework. If you have not tried Svelte before, this list might convince you to do so.