DEV Community: Slava

Components Are Just Sparkling Hooks (Intro to Headless Components)

Slava — Sat, 24 May 2025 20:31:03 +0000

Slava

Apr 13 '25

Components Are Just Sparkling Hooks (Intro to Headless Components)

#react #patterns #javascript #webdev

Comments

6 min read

Components Are Just Sparkling Hooks (Intro to Headless Components)

Slava — Sun, 13 Apr 2025 00:00:00 +0000

Here’s a question you might encounter while interviewing for React developer roles:

“What is the difference between a component and a hook?”

The answer that the interviewer is likely looking for is along the lines of “A component is a building block for the UI, and hooks are utility functions provided by React to manage state and side-effects 😴”.

It’s a satisfactory answer if your goal is to find employment. But if you want to make an impression, the more daring answer is: “There is no difference 🔥”.

First, What is a Component?

The very technical answer is that it is a function that returns a ReactNode, which is anything that makes sense to render on-screen (including JSX, strings, numbers, nulls, and so on).

For a better reading experience: Read this post on BBSS.dev: https://www.bbss.dev/posts/sparkling-hooks/

Below is a valid React component:

const MyComponent = () => {
  return "Hello World!";
};

Components can render dynamic inputs using props...

const MyComponent = ({ name, onClick }) => {
  return <button onClick={onClick}>Hello {name}!</button>;
};

...and implement stateful behaviors using hooks.

const MyCounter = () => {
  const [count, increment] = useReducer((state) => state + 1, 0);

  return <button onClick={increment}>Counter {count}</button>;
};

From there, the sky is the limit!

const MyFancyCounter = () => {
  const [count, increment] = useReducer((state) => state + 1, 0);

  // Add fancy styles every time `count` doubles
  const fancyClass = useMemo(() => {
    const orderOfMagnitude = Math.floor(Math.log2(count));

    if (orderOfMagnitude <= 0) return "";

    switch (orderOfMagnitude) {
      case 1:
        return "fancy-1";
      case 2:
        return "fancy-2";
      case 3:
        return "fancy-3";
      default:
        // Beyond 255
        return "fanciest";
    }
  }, [count]);

  return (
    <button onClick={increment} className={fancyClass}>
      Counter {count}
    </button>
  );
};

No matter what we do in the implementation, we can use it as a black box in another component by mixing it into the JSX.

const FancyCounterApp = () => {
  return (
    <div>
      <h1>My Counter App</h1>
      <MyFancyCounter />
    </div>
  );
};

Second, What are Hooks?

Hooks are React built-in functions to manage state and effects. You can create new hooks by wrapping the React-provided hooks in a function.

Hooks can accept any input and return any value. The only restrictions are the rules of hooks, which dictate that hooks must not be called conditionally. Critically, those rules are transitive, meaning that anything that calls a hook is a hook itself and must follow those rules until it is used in a component.

This is where we get to the crux of the story: given that Components transitively inherit all restrictions of hooks (rules of hooks), and are more restrictive in their output (can only return ReactNodes): Components are indeed a subtype of hooks. Any component can be used as a hook!

Case in point, our most complex component from earlier can become a hook effortlessly:

// It's prefixed by `use` now, its a hook!
const useFancyCounter = () => {
  const [count, increment] = useReducer((state) => state + 1, 0);

  // Add fancy styles every time `count` doubles
  const fancyClass = useMemo(() => {
    const orderOfMagnitude = Math.floor(Math.log2(count));

    if (orderOfMagnitude <= 0) return "";

    switch (orderOfMagnitude) {
      case 1:
        return "fancy-1";
      case 2:
        return "fancy-2";
      case 3:
        return "fancy-3";
      default:
        // Beyond 255
        return "fanciest";
    }
  }, [count]);

  return (
    <button onClick={increment} className={fancyClass}>
      Counter {count}
    </button>
  );
};

const FancyCounterApp = () => {
  const myFancyCounter = useFancyCounter();
  return (
    <div>
      <h1>My Counter App</h1>
      {myFancyCounter}
    </div>
  );
};

So far, this might seem like uninteresting semantics, but there is a practical side to this exercise.

Headless Components

As previously noted, the distinguishing trait of a component is that it returns a ReactNode. For API purposes, the ReactNode is a black box. Since useFancyCounter() still returns a ReactNode, its internal state is opaque and not consumable.

The limitation matters because it prevents FancyCounterApp from easily implementing features such as:

rendering the {count} outside of the <button>
extending button styling
adding another button to increment the count by two
performing some event once the count reaches 10

Since useFancyCounter is a hook, instead of returning a ReactNode, it can expose its event handlers and state, which FancyCounterApp can leverage into a more flexible output.

// It's prefixed by `use` now, its a hook!
const useFancyCounter = () => {
  const [count, increment] = useReducer((state) => state + 1, 0);

  // Add fancy styles every time `count` doubles
  const fancyClass = useMemo(() => {
    const orderOfMagnitude = Math.floor(Math.log2(count));

    if (orderOfMagnitude <= 0) return "";

    switch (orderOfMagnitude) {
      case 1:
        return "fancy-1";
      case 2:
        return "fancy-2";
      case 3:
        return "fancy-3";
      default:
        // Beyond 255
        return "fanciest";
    }
  }, [count]);

  return { fancyClass, increment, count };
};

useFancyCounter is now a headless component because it implements all Component-adjacent functionality (event handling, state management, styling) but allows its caller to distill it into JSX instead of returning a pre-baked ReactNode.

The flexibility of this pattern is unparalleled, with none of the boilerplate that a composition-based solution would've brought.

const FancyCounterApp = () => {
  const { fancyClass, increment, count } = useFancyCounter();

  // performing some event once the count reaches 10
  useEffect(() => {
    if (count === 10) {
      showFireworks();
    }
  }, [count]);

  return (
    <div>
      <h1>My Counter App</h1>
      {/* rendering the `{count}` outside of the `<button>` */}
      <h2>Count is at {count}</h2>
      <button
        onClick={increment}
        // extend button styling
        className={clsx(fancyClass, "some-other-class")}
      >
        Increment by 1
      </button>
      {/* adding another button to increment the count by two */}
      <button
        onClick={() => {
          increment();
          increment();
        }}
      >
        Increment by 2
      </button>
    </div>
  );
};

Unit Testing

Headless components effectively decouple the view from the view model, making them testable individually.

// Testing full component
describe("FancyCounterApp", () => {
  it("increments", () => {
    render(<FancyCounterApp />);

    const incrementBtn = screen.findByLabel("Increment by 1");

    fireEvent.click(incrementBtn);
    fireEvent.click(incrementBtn);
    fireEvent.click(incrementBtn);

    expect("Count is at 3").toBeInDocument();
  });
});

// Testing component logic only
describe("useFancyCounter", () => {
  it("increments", () => {
    const { result } = renderHook(() => useFancyCounter());

    act(() => result.current.increment());
    act(() => result.current.increment());
    act(() => result.current.increment());

    expect(result.current.count).toBe(3);
  });
});

Composition + Headless Components

While headless components often solve the same kind of challenges as composition, the two patterns are compatible (the implementation of the new components is left as an exercise to the reader):

const FancyCounterApp = () => {
  return (
    <FancyCounter.Context value={useFancyCounter()}>
      <FancyCounter.Fireworks at={10} />
      <div>
        <h1>My Counter App</h1>
        <h2>
          Count is at <FancyCounter.Count />
        </h2>
        <FancyCounter.IncrementBtn by={1}>
          Increment by 1
        </FancyCounter.IncrementBtn>
        <FancyCounter.IncrementBtn by={2}>
          Increment by 2
        </FancyCounter.IncrementBtn>
      </div>
    </FancyCounterContext>
  );
};

This combined pattern is helpful if you want inversion of control while keeping the controller as an individual unit. The added benefit is the ability to reuse view-model logic between components that use context and those that don't.

Go Deeper: A future article will be covering advanced composition patterns. Subscribe to the BBSS newsletter to be the first to read it!

State of the Art

A few real-world libraries implement headless components (see: jxom/awesome-react-headless-components).

Some implement headless components exactly as described, using hooks and pushing them to their full potential (see: React Aria):

// https://react-spectrum.adobe.com/react-aria/useMenu.html#menubutton
function MenuButton<T extends object>(props: MenuButtonProps<T>) {
  // Create state based on the incoming props
  let state = useMenuTriggerState(props);

  // Get props for the button and menu elements
  let ref = React.useRef(null);
  let { menuTriggerProps, menuProps } = useMenuTrigger<T>({}, state, ref);

  return (
    <>
      <Button
        {...menuTriggerProps}
        buttonRef={ref}
        style={{ height: 30, fontSize: 14 }}
      >
        {props.label}
        <span aria-hidden="true" style={{ paddingLeft: 5 }}>
          ▼
        </span>
      </Button>
      {state.isOpen && (
        <Popover state={state} triggerRef={ref} placement="bottom start">
          <Menu {...props} {...menuProps} />
        </Popover>
      )}
    </>
  );
}

Others treat "headless" as a synonym for "unstyled", and instead expose their state through through children callbacks (see: Headless UI):

// https://headlessui.com/react/menu#using-render-props
function Example() {
  return (
    <Menu>
      <MenuButton as={Fragment}>
        {({ active }) => (
          <button className={clsx(active && "bg-blue-200")}>My account</button>
        )}
      </MenuButton>
      <MenuItems anchor="bottom">
        {links.map((link) => (
          <MenuItem key={link.href} as={Fragment}>
            {({ focus }) => (
              <a
                className={clsx("block", focus && "bg-blue-100")}
                href={link.href}
              >
                {link.label}
              </a>
            )}
          </MenuItem>
        ))}
      </MenuItems>
    </Menu>
  );
}

The above is different because a UI component's "head" is a renderable chunk. An unstyled ReactNode is convenient for some purposes but does not address the same challenges as a hook-based headless component.

Conclusion

It is easy to overlook the idea that components and hooks are not separate concepts, as they are always presented as distinct primitives.

Once accepted, headless components emerge as an obvious pattern that enables greater logic reusability, flexibility, and superior testing patterns.

If you enjoyed this article, you might also enjoy diving into the previous React article: Learning Suspense by Building a Suspense-Enabled Library.

Learn Suspense by Building a Suspense-Enabled Library

Slava — Mon, 08 Jul 2024 03:32:02 +0000

Suspense (along with concurrent rendering) has been a feature in React since v16.6.0. Despite this, I haven’t seen much of it in action beyond React.lazy and limited applications of “suspense-enabled libraries”.

What’s going on?

As of the impending React v19 release, Suspense is still not quite ready for primetime. The story of its APIs and internals still seems incomplete. In fact, the React team seems to think it’s so incomplete that the Suspense API is entirely undocumented. The Suspense documentation insists that the only way of using Suspense is via “Suspense-enabled frameworks”.

I think that purposefully hiding APIs in documentation is silly, but fine! I’ll play their game! Let’s build a Suspense-enabled library, and use it.

We will peel back the curtain of Suspense along the way.

Writing Effective Higher-Order Components in React.js

Slava — Fri, 03 Feb 2023 21:44:10 +0000

Many developers who experienced HOCs in the pre-hook era have been traumatized by the experience of data-provider HOCs and have stopped using them entirely as soon as they could.

I think that they were sworn off prematurely, and that there is room for them as long as you avoid using them in the wrong places.

I wrote a list of conventions to follow, and things to avoid in order to write HOCs effectively.

Read it here: https://www.bbss.dev/posts/effective-hocs/

Let me know what you think!

The State of Copy-Pasting in JavaScript

Slava — Sat, 15 Jan 2022 22:55:34 +0000

I recently did some work on a VS Code extension whose purpose is to handle rich pastes. It prompted me to survey different copy-pasting libraries and the state of the NPM ecosystem as a whole.

How do clipboards work?

Clipboards across different operating systems work essentially the same. For this reason, we will stick to looking at a single one -- Windows.

A common misconception about how clipboards work is that they contain a single piece of data, such as text or an image. In reality, clipboards hold all the ways target software can represent the data.

Consider if I copy the following webpage:

HTML headings as rendered by Firefox

When pasting it into Microsoft Word, it appears formatted as rich content:

Microsoft Word displays rich content exactly as Firefox does

When pasting it into Notepad++, it appears as plain text:

Notepad++ does not handle rich content

Pasting different content types depending on the software is possible because Firefox provides multiple representations of the rendered content to the clipboard.

Let's see what types the clipboard is holding using Powershell:

$dataObj = [System.Windows.Forms.Clipboard]::GetDataObject()
foreach ($fmt in $dataObj.GetFormats()) {
    [Console]::WriteLine($fmt)
}

## Output: ##
HTML Format
System.String
UnicodeText
Text
Chromium Web Custom MIME Data Format
Locale
OEMText

We can look inside some of the clipboard types using Powershell, mainly HTML Format and Text with the following commands:

# Get Text
[System.Windows.Forms.Clipboard]::GetText([System.Windows.Forms.TextDataFormat]::Text)

## Output: ##
This is heading 1
This is heading 2
This is heading 3
This is heading 4
This is heading 5
This is heading 6

# Get HTML Format
[System.Windows.Forms.Clipboard]::GetText([System.Windows.Forms.TextDataFormat]::Text)

## Output: ##
Version:0.9
StartHTML:00000174
EndHTML:00000410
StartFragment:00000208
EndFragment:00000374
SourceURL:https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_headers
<html><body>
<!--StartFragment--><h1>This is heading 1</h1>
<h2>This is heading 2</h2>
<h3>This is heading 3</h3>
<h4>This is heading 4</h4>
<h5>This is heading 5</h5>
<h6>This is heading 6</h6><!--EndFragment-->
</body>
</html>

The way to approach clipboards as a consumer is to consume the clipboard formats you know how to, prioritizing some over others. For example, Microsoft Word will prioritize pasting HTML Format formats over Text formats by default.

While Powershell has some built-in parsers, implementing the format specification for every type of content is a lot of work. Are there libraries that can help us with this?

Copy-Pasting in the NPM Ecosystem

The simplest clipboard library would let us query the clipboard directly for binary data. This approach would require us to a parser per format per operating system. While such libraries deserve a place in this world, they are not helpful for most applications. Most applications want to handle copying and pasting only for text, rich text, images, and sometimes files. Let's go through the different clipboard management libraries and see how they fare.

We are looking for a library that has the following features:

Pure JS, with native bindings
Cross-Platform Support
- Windows
- Linux
- MacOS
Copy to clipboard
- Plain Text
- Rich Text
- Images
- Files
Paste from clipboard
- Plain Text
- Rich Text
- Images
- Files

Here is a table I made from the collected NPM packages, featuring the most popular clipboard-related libraries on NPM:

Note: This table does not include browser-based copy-paste.

Features / Libraries	clipboardy	copy-paste	clipboard-cli	node-clipboard-wd	Electron (Not a library)
Pure JS	Uses system utilties	Uses system utilties	Uses system utilties	Chromium binary	Uses native bindings
Cross-Platform Support	Yes	Yes	Yes	Yes	Yes
Windows	Yes	Yes	Yes	Yes	Yes
Linux	Yes	Yes	Yes	Yes	Yes
MacOS	Yes	Yes	Yes	Yes	Yes
Copy to Clipboard	Partial	Partial	Partial	No	Yes
Plain Text	Yes	Yes	Yes	No	Yes
Rich Text	No	No	No	No	Yes
Images	No	No	No	No	Yes
Files	No	No	No	No	Exposes binary API
Paste from Clipboard	Partial	Partial	Partial	Yes	Yes
Plain Text	Yes	Yes	Yes	Yes	Yes
Rich Text	No	No	No	Yes	Yes
Images	No	No	No	Yes	Yes
Files	No	No	No	Yes	Exposes binary API

Honorable mention: save-clipboard-image, uses AppleScript to save an image from clipboard to a file.

Summary

Before writing this post, I was unaware that the result would be this. It appears that all of NPM's clipboard libraries work the same way: they call built-in executables on their host operating system and return the data. Interestingly, none of them handle images, rich text, or files despite no reason they couldn't deal with them the same way.

The only exceptions to this pattern are Electron and node-clipboard-wd. The former is a framework unsuitable for usage as a library. The latter was written by myself last week as an experiment.

Where do we go from here?

Software developers have crossed the clipboard bridge in other environments before. In fact, NodeJS developers have already crossed it in Electron, which uses native bindings under the hood. There is no reason we couldn't do the same using a more lightweight C++ library.

I find clip particularly promising in this regard, and I've been looking into writing a NodeJS wrapper around it. For posterity, here is a table of possible native libraries that I have found so far:

Features / Libraries	clip	arboard	clipboard
Cross-Platform Support	Yes	Yes	Yes
Windows	Yes	Yes	Yes
Linux	Yes	Yes	Yes
MacOS	Yes	Yes	Yes
Copy to Clipboard	Yes	Partial	Partial
Plain Text	Yes	Yes	Yes
Rich Text	Yes	No	No
Images	Yes	Yes	Yes
Files	Exposes binary API	No	No
Paste from Clipboard	Yes	Partial	Partial
Plain Text	Yes	Yes	Yes
Rich Text	Yes	No	No
Images	Yes	Yes	Yes
Files	Exposes binary API	No	No

Optimize Your Webserver by Installing a Single NGINX Module

Slava — Fri, 14 Jan 2022 18:54:41 +0000

In 2012, Google released version 1.0 of their PageSpeed modules for NGINX and Apache. It has gone largely unnoticed since then. The short of PageSpeed is that if you add it to your web server, you can configure it to optimize anything passing through it using techniques such as minification, format conversion, and even injecting scripts to lazy-load images. You can read more about what it does on the official site.

It sounded great in theory, but how properly install it with NGINX wasn't obvious. While Google does publish scripts to help with the installation, it requires a non-trivial depth of knowledge to do right. After struggling with it for many hours, I wrote a guide for personal future reference.

I recently returned to those notes to entirely automate the process using GitHub Actions. The work is open-source and available on GitHub.

Installation

Run the following as root on a Debian-based machine:

sudo su
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 8028BE1819F3E4A0
echo "deb https://nginx-pagespeed.knyz.org/dist/ /" > /etc/apt/sources.list.d/nginx-pagespeed.list
echo "Package: *" > /etc/apt/preferences.d/99nginx-pagespeed
echo "Pin: origin http://nginx-pagespeed.knyz.org/" >> /etc/apt/preferences.d/99nginx-pagespeed
echo "Pin-Priority: 900" >> /etc/apt/preferences.d/99nginx-pagespeed
apt update
apt install nginx-full # If NGINX is already installed, an `apt upgrade` works too
echo "pagespeed on;" > /etc/nginx/conf.d/pagespeed.conf
echo "pagespeed FileCachePath \"/var/cache/pagespeed/\";" >> /etc/nginx/conf.d/pagespeed.conf
echo "pagespeed FileCacheSizeKb 102400;" >> /etc/nginx/conf.d/pagespeed.conf
echo "pagespeed FileCacheCleanIntervalMs 3600000;" >> /etc/nginx/conf.d/pagespeed.conf
echo "pagespeed FileCacheInodeLimit 500000;" >> /etc/nginx/conf.d/pagespeed.conf
echo "pagespeed RewriteLevel CoreFilters;" >> /etc/nginx/conf.d/pagespeed.conf
systemctl reload nginx

The installation process is explained more thoroughly on the GitHub page if you're curious.

Once that is done, you will have an active NGINX + PageSpeed installation that will receive the same updates as upstream NGINX. You can learn more about individual filters that you can enable in the documentation.

This post was originally shared on my Building Better Software Slower blog