Not Everything Needs a Component

In the early 2000s, a new term, Divitis, was coined to refer to The practice of authoring web-page code with many div elements in place of meaningful semantic HTML elements. This was part of an effort to increase awareness of semantics in HTML within the frame of the Progressive Enhancement technique.

Fast forward 20 years - I witness a new syndrome affecting web developers, one I call componentitis. Here is my made-up definition:

Componentitis: the practice of creating a component for every aspect of a UI in place of a simpler and more reusable solution.

Components

So, first of all, what is a component? I think React popularized the term to refer to its building blocks:

React lets you combine your markup, CSS, and JavaScript into custom "components", reusable UI elements for your app.
— React documentation - Your First Component

While the concept of reusable UI elements wasn’t new at the time (in CSS, we already had techniques like OOCSS, SMACSS, and BEM), the key difference is its original approach to the location of markup, style, and interaction. With React components (and all the subsequent UI libraries), it’s possible to co-locate everything in a single file within the boundaries of a component.

So, using Facebook’s latest CSS library Stylex, you could write:

import * as stylex from "@stylexjs/stylex";
import { useState } from "react";

// styles
const styles = stylex.create({
    base: {
        fontSize: 16,
        lineHeight: 1.5,
        color: "#000",
    },
});

export function Toggle() {
    // interactions
    const [toggle, setToggle] = useState(false);
    const onClick = () => setToggle((t) => !t);

    // markup
    return (
        <button type="button" onclick="{onClick}">
            {toggle}
        </button>
    );
}

You can be a fan or not of writing CSS in object notation (I’m not), but this level of co-location is often a good way to make a component-based project more maintainable: everything is within reach and explicitly bound.

In libraries like Svelte, the co-location is even more clear (and the code more concise):

<script>
    let toggle = $state(false)
    const onclick = () => toggle = !toggle
</script>

<button type="button">
    {toggle}
</button>

<style>
button {
    font-size: 16px;
    line-height: 1.5;
    color: #000;
}
</style> 

Over time, this pattern has gained so much traction to the point that everything is encapsulated in components. You have probably encountered page components like this:

export function Page() {
    return (
        <layout>
            <header nav="{<Nav"></header>} />
            
                <stack spacing="{2}">
                    <item>Item 1</item>
                    <item>Item 2</item>
                    <item>Item 3</item>
                </stack>
            
            <footer></footer>
        </layout>
    );
}

Co-location of one

The above code looks clean and consistent: we use the component interface to describe a page.

But then, let’s look at the possible implementation of Stack. This component is usually a wrapper to ensure all direct child elements are vertically stacked and evenly spaced:

import * as stylex from "@stylexjs/stylex";
import type { PropsWithChildren } from "react";

const styles = stylex.create({
    root: {
        display: "flex",
        flexDirection: "column",
    },
    spacing: (value) => ({
        rowGap: value * 16,
    }),
});

export function Stack({
    spacing = 0,
    children,
}: PropsWithChildren) {
    return (
        <div styles.spacing>
            {children}
        </div>
    );
}

We only define the styles and the root element of the component.

In this case, we could even say that the only thing we are co-locating is the style block since the HTML is only used to hold a CSS class reference, and there is no interactivity or business logic.

The (avoidable) cost of flexibility

Now, what if we want to be able to render the root element as a section and maybe add some attributes? We need to enter the realm of polymorphic components. In React and with TypeScript this might end up being something like the following:

import * as stylex from "@stylexjs/stylex";
import { useState } from "react";

// styles
const styles = stylex.create({
    base: {
        fontSize: 16,
        lineHeight: 1.5,
        color: "#000",
    },
});

export function Toggle() {
    // interactions
    const [toggle, setToggle] = useState(false);
    const onClick = () => setToggle((t) => !t);

    // markup
    return (
        <button type="button" onclick="{onClick}">
            {toggle}
        </button>
    );
}

In my opinion, this isn't very readable at first glance. And remember: we are just rendering an element with 3 CSS declarations.

Back to the basics

A while back, I was working on a pet project in Angular. Being used to thinking in components, I reached out to them to create a Stack. It turns out that in Angular polymorphic components are even more complex to create.

I started to question my implementation design and then I had an epiphany: why spend time and lines of code on complex implementations when the solution had been right in front of me all along?

<script>
    let toggle = $state(false)
    const onclick = () => toggle = !toggle
</script>

<button type="button">
    {toggle}
</button>

<style>
button {
    font-size: 16px;
    line-height: 1.5;
    color: #000;
}
</style> 

Really, that’s the barebone native implementation of the Stack . Once you load the CSS in the layout, it can be used right away in your code:

export function Page() {
    return (
        <layout>
            <header nav="{<Nav"></header>} />
            
                <stack spacing="{2}">
                    <item>Item 1</item>
                    <item>Item 2</item>
                    <item>Item 3</item>
                </stack>
            
            <footer></footer>
        </layout>
    );
}

Add type-safety in JavaScript frameworks

The CSS-only solution provides neither typing nor IDE auto-completion.

Also, if we are not using spacing variants, it might feel too verbose to write both a class and a style attribute instead of a spacing prop. Assuming you're using React, you could leverage JSX and create a utility function:

import * as stylex from "@stylexjs/stylex";
import type { PropsWithChildren } from "react";

const styles = stylex.create({
    root: {
        display: "flex",
        flexDirection: "column",
    },
    spacing: (value) => ({
        rowGap: value * 16,
    }),
});

export function Stack({
    spacing = 0,
    children,
}: PropsWithChildren) {
    return (
        <div styles.spacing>
            {children}
        </div>
    );
}

Note that React TypeScript doesn’t allow unknown CSS properties. I used a type assertion for brevity, but you should choose a more robust solution.

If you’re using variants you can modify the utility function to provide a developer experience similar to PandaCSS patterns:

import * as stylex from "@stylexjs/stylex";

type PolymorphicComponentProps<t extends react.elementtype> = {
    as?: T;
    children?: React.ReactNode;
    spacing?: number;
} & React.ComponentPropsWithoutRef<t>;

const styles = stylex.create({
    root: {
        display: "flex",
        flexDirection: "column",
    },
    spacing: (value) => ({
        rowGap: value * 16,
    }),
});

export function Stack<t extends react.elementtype="div">({
    as,
    spacing = 1,
    children,
    ...props
}: PolymorphicComponentProps<t>) {
    const Component = as || "div";
    return (
        <component styles.spacing>
            {children}
        </component>
    );
}
</t></t></t></t>

Prevent code duplication and hardcoded values

Some of you might have noticed that, in the last example, I hardcoded the expected values of spacing in both the CSS and the utility files. If a value is removed or added, this might be an issue because we must keep the two files in sync.

If you’re building a library, automated visual regression tests will probably catch this kind of issue. Anyway, if it still bothers you, a solution might be to reach for CSS Modules and either use typed-css-modules or throw a runtime error for unsupported values:

<div>





<pre class="brush:php;toolbar:false">.stack {
  --s: 0;
    display: flex;
    flex-direction: column;
    row-gap: calc(var(--s) * 16px);
}

export function Page() {
    return (
        <layout>
            <header nav="{<Nav"></header>} />
            
                <div classname="stack">



<p>Let's see the main advantages of this approach:</p>

<ul>
<li>reusability</li>
<li>reduced complexity</li>
<li>smaller JavaScript bundle and less overhead</li>
<li><strong>interoperability</strong></li>
</ul>

<p>The last point is easy to overlook: Not every project uses React, and if you’re including the stack layout pattern in a Design System or a redistributable UI library, developers could use it in projects using different UI frameworks or a server-side language like PHP or Ruby.</p>

<h2>
  
  
  Nice features and improvements
</h2>

<p>From this base, you can iterate to add more features and improve the developer experience. While some of the following examples target React specifically, they can be easily adapted to other frameworks.</p>

<h3>
  
  
  Control spacing
</h3>

<p>If you're developing a component library you definitely want to define a set of pre-defined spacing variants to make space more consistent. This approach also eliminates the need to explicitly write the style attribute:<br>
</p>

<pre class="brush:php;toolbar:false">.stack {
  --s: 0;
  display: flex;
  flex-direction: column;
  row-gap: calc(var(--s) * 16px);

  &.s\:1 { --s: 1 }
  &.s\:2 { --s: 2 }
  &.s\:4 { --s: 4 }
  &.s\:6 { --s: 6 }
}

/** Usage:
<div>



<p>For a bolder approach to spacing, see Complementary Space by Donnie D'Amato.</p>

<h3>
  
  
  Add better scoping
</h3>

<p>Scoping, in this case, refers to techniques to prevent conflicts with other styles using the same selector. I’d argue that scoping issues affects a pretty small number of projects, but if you are really concerned about it, you could:</p>

<ol>
<li>Use something as simple as CSS Modules, which is well supported in all major bundlers and frontend frameworks.</li>
<li>Use cascade layers resets to prevent external stylesheets from modifying your styles (this is an interesting technique).</li>
<li>Define a specific namespace like .my-app-... for your classes.</li>
</ol>

<p>Here is the result with CSS Modules:<br>
</p>

<pre class="brush:php;toolbar:false">.stack {
  --s: 0;
  display: flex;
  flex-direction: column;
  row-gap: calc(var(--s) * 16px);

  &.s1 { --s: 1 }
  &.s2 { --s: 2 }
  &.s4 { --s: 4 }
  &.s6 { --s: 6 }
}

/** Usage
import * from './styles/stack.module.css'

<div classname="{`${styles.stack}">
    // ...
</div>  
*/

Alternatives

If you still think a polymorphic component would be better, really can't deal with plain HTML, or don’t want to write CSS in a separate file (though I am not sure why), my next suggestion would be to take a look at PandaCSS and create custom patterns or explore other options like vanilla-extract. In my opinion, these tools are an over-engineered CSS metalanguage but still better than a polymorphic component.

Another alternative worth considering is Tailwind CSS, which has the advantage of being interoperable between languages and frameworks.

Using the default spacing scale defined by Tailwind, we could create a stack- plugin like this:

import * as stylex from "@stylexjs/stylex";
import { useState } from "react";

// styles
const styles = stylex.create({
    base: {
        fontSize: 16,
        lineHeight: 1.5,
        color: "#000",
    },
});

export function Toggle() {
    // interactions
    const [toggle, setToggle] = useState(false);
    const onClick = () => setToggle((t) => !t);

    // markup
    return (
        <button type="button" onclick="{onClick}">
            {toggle}
        </button>
    );
}

As a side note: it's interesting that Tailwind uses the component mental model in matchComponents to describe complex CSS rulesets, even if it does not create any real component. Maybe another example of how pervasive the concept is?

Takeaways

The case of Componentitis, beyond its technical aspects, demonstrates the importance of pausing to examine and question our mental models and habits. Like many patterns in software development, components emerged as solutions to real problems, but when we began defaulting to this pattern, it became a silent source of complexity. Componentitis resembles those nutritional deficiencies caused by a restricted diet: the problem isn't with any single food but rather with missing out on everything else.