Headless UI Components: A Journey With High Order Components, Render Props, and Custom Hooks

Headless UI components without UI but with UI functionality

We have given an introduction to React-Table — a custom Hook to build an extendable table without the actual UI component. This type of component is called a headless UI component — it separates the logic and behavior of a component from its visual representation.

Headless UI components have a long journey with high order components, render props, and custom hooks. These concepts will be explained in this article.

High Order Components

We have a component that prints out a simple UI:

For this article, the source code is verified in CodePen:

We want to make the text blue. This can be done by adding the style to line one or passing the style through line three. However, we want this style transformation logic to be reusable for other components too.

A high order component (HOC) is a good choice for this task. It’s a function that takes a component and returns a new component, with additional logic and behavior. It’s commonly defined as follows:

const EnhancedComponent = higherOrderComponent(WrappedComponent);

So, we create a HOC in the following code:

This HOC is named withColor (lines 1-8). It takes props and extracts out color if defined. Otherwise, it uses red as the default color (line 2). The rest props are passed down to the original component (line 5). It’s important to use composition, instead of mutating the original component.

This HOC wraps the original component by a div, styled with color (line 4), which is defined as blue at line 14.

Now we see the text blue:

You may be asking why we created TransformedComponent outside of App, instead directly mutating the original component in the render, as follows:

const App = () => {
  const TransformedComponent = withColor(BaseComponent);
  return <TransformedComponent value={1} color="blue"/>;
}

React’s diffing algorithm (also called reconciliation) uses component reference to determine whether it should update the existing subtree or throw it away and mount a new one. If the component returned from render is strictly equal to the component from the previous render, React recursively updates the subtree by diffing it with the new one. If they’re not equal, the previous subtree is completely unmounted.

If TransformedComponent is generated inside render, it has a new reference for each render, which would cause unnecessary unmounting.

If you have to put TransformedComponent inside render, the alternative way is to apply useMemo to keep the reference between renders.

withColor transforms the color. What if we also want to change the font style to be italic?

Another HOC is created to transform the font style:

This additional HOC is named withFontStyle (lines 1-8). It takes props and extracts out fontStyle if defined. Otherwise, it uses normal as the default fontStyle (line 2). The rest props are passed down to the original component (line 5).

This HOC wraps the original component by a div, styled with fontStyle (line 4), which is defined as italic at line 24.

Here we compose two HOCs at line 21.

What if we want to transform props in the original component, something like multiple of the original value?

Another HOC will do.

This new HOC is named withMultipleValue (lines 1 - 9). It takes props and extracts out factor if defined. Otherwise, it uses 1 as the default factor (line 2). A new value is calculated at line 3, which replaces the original value at line 6. newprops are passed down to the original component (line 8).

This HOC is applied at line 31, which times the factor, 5, defined at line 36.

We compose three HOCs in lines 31-33. These lines look a little congested but they can be formatted like this if you have ramda installed:

import compose from "ramda";

const TransformedComponent = compose(
  withMultipleValue,
  withFontStyle, 
  withColor,
)(BaseComponent);

If you use Create React App, lodash is built-in and lines 31-33 can be written as:

import flowRight from "lodash/flowRight";

const TransformedComponent = flowRight(
  withMultipleValue,
  withFontStyle,
  withColor,
)(BaseComponent);

Render Props

HOCs work well. Why do we need render props?

Well, HOCs use static composition, but render props use dynamic composition.

Render props refer to a technique for sharing code between React components using a prop whose value is a function that returns a React element. A component with a render prop calls this function instead of implementing its own rendering.

Libraries that use render props include React Router, Downshift and Formik.

It is said that most HOCs can be accomplished by regular components with render props.

Conceptually, HOCs provide additional logic and behavior to existing components. Render props provide components with intended logic and behavior, which can be applied to any visual representation.

Let’s see how to convert HOC, withColor, to a render prop implementation:

Lines 1-4 define ColorComp that adopts a render prop. At line 3, the color logic is set to the outer div, which can be applied to any rendered components.

Lines 8-10 deploy ColorComp with the render prop set to BaseComponent.

Line 12 initializes color to be blue.

Although this pattern is called render props, it does not have to be named render. Any prop that is a function for rendering is technically a render prop.

We rename render to test at line 3 and 9. It also functions as it’s called render.

If you really want a HOC for some reason, you can add on to the above code by creating a HOC on top of render props.

Lines 6-8 is a HOC on top of render props (line 7). This HOC is used in line 12. It works as well as a regular HOC.

We’ve tried various ways to implement withColor using render props. How about convert withFontStyle to render props as well?

Here’s the source code:

Lines 1-4 define FontStyleComp that adopts a render prop. At line 3, the fontStyle logic is set to the outer div, which can be applied to any rendered components.

Lines 14-19 deploy FontStyleComp with the render prop set to ColorComponent that has the render prop set to BaseComponent.

Line 23 initializes fontStyle to be italic.

What about converting withMultipleValue to render props too?

Here’s the source code:

Lines 1-4 define MultipleValueComp that adopts a render prop. At line 3, it provides the logic to calculate the new value based on factor, and then renders whatever from the render prop as visual representation.

Lines 24-37 deploys FontStyleComp with the render prop set to FontStyleComponent, a nested component with render props.

Line 41 initializes factor to be 5.

We have given examples of HOCs and render props. When applications have a massive quantity of nested components, you can see the problem commonly known as “wrapper hell.”

Headless UI Components

A headless user interface component is a component that offers maximum visual flexibility by providing no interface. It separates the logic and behavior of a component from its visual representation.

A famous headless implementation is p/>. It uses children to implement render props and emphasizes the basics of Unix philosophy:

Rule of Separation: Separate policy from mechanism; separate interfaces from engines.

— Eric S. Raymond

Headless UI components with render props

Headless UI Components made render props popular since they need a way to dynamically apply the logic and behavior to any components. It delivers more flexibility for large-scale components than HOCs.

A headless UI component can offer its children methods and values:

CombinedComp at lines 1-7 creates a headless UI component that supplies its children with three methods: getFactor (line 3), getColor (line 4), and getFontStyle (line 5).

When the component is used at lines 12 -18, these methods are available to its children elements (lines 14-16). Isn’t it beautiful for logic and behavior to be reused?

Headless UI components with custom hooks

Here comes React hooks, which creates React components without extending from a class component. Besides built-in hooks, there are custom hooks, which are a wrapper function surrounding existing hooks. It’s a mechanism to reuse stateful logic and behavior that are isolated for each usage.

Hooks are a tornado in React world. They deliver the promise of functional programming. Hooks are easy to compose and straightforward to use. They end the “wrapper hell” caused by render props.

However, headless UI components continue. With the assistance of custom hooks, headless UI components have become more popular.

The following is a list of Awesome React Headless Components:

• React Albus: React component library for building declarative multi-step flows (wizards).
• Dayzed: Primitives to build simple, flexible, WAI-ARIA compliant React date-picker components.
• Downshift: Primitive to build simple, flexible, WAI-ARIA compliant enhanced input React components.
• React Ranger: A headless render prop component for building range and multi-range sliders in React.
• React Selected: React component to build flexible and accessible radio buttons/elements.
• React T-Minus: React component to handle simple countdowns.
• React Toggled: React component to build simple, flexible, and accessible toggle components.
• React Values: A set of tiny, composable React components for handling state with render props.
• React Table: Hooks for building lightweight, fast and extendable table.

We rewrite the previous headless UI component example with a custom hook:

useCombinedComp at lines 1-10 creates a headless UI component with three methods: getFactor (line 4), getColor (line 5), and getFontStyle (line 6).

When the custom hook is used at line 15, these methods are available in App component (lines 16-20).

Custom hooks make the build process simple and straightforward. Are you ready to construct your own headless UI components?

Conclusion

React was born in May 2013. History is bunk.

The following facts remain true:

• Most HOCs can be accomplished by render props.
• HOCs use static composition while render props use dynamic composition.
• React hooks are dynamic without Wrapper Hell.
• React hooks end render props, but HOCs continue on.
• Headless UI Components are magic: They do not have a UI, but have the UI functionality.

Thanks for reading. I hope this was helpful. You can see my other Medium publications here.