DRY in React: A Study in Composability Over Configuration

📖 Start Here

Before reading this: Please read Swizec Teller's original article:

"DRY is a footgun, remember to YAGNI"

This codebase is a response to that article. Understanding Swizec's argument is essential context for the counter-thesis presented here.

Thesis

The problem with DRY (Don't Repeat Yourself) isn't the principle itself, but the approach. Instead of anticipating flexibility through configuration props, expose internal primitives for composition.

Context: The DRY Footgun

In his article, Swizec identifies a critical problem with premature abstraction. He describes how a generic button component evolves:

"You start with a simple button component. Then you need a blue one. Then a green one. Then one that's disabled sometimes. Then one that's only disabled when some other state is true. Then..."

The pattern he describes is familiar to anyone who's worked in a large React codebase: a component starts simple, accumulates props to handle edge cases, and eventually becomes a configuration nightmare:

// The anti-pattern Swizec warns against
<GenericButton
  variant="primary"
  size="large"
  disabled={!isActive}
  color="green"
  onClick={handleClick}
  showLoader={isLoading}
  iconPosition="left"
  // ... 15 more props
/>

Swizec's conclusion:

DRY leads to bloated abstractions. Use YAGNI instead—don't abstract until patterns genuinely emerge.

(YAGNI: "You Aren't Gonna Need It")

The Problem with This Conclusion

Swizec is right about the symptom, but the diagnosis misses something crucial. The issue isn't DRY itself—it's configuration-based abstraction.

When you try to make a component flexible by adding props for every scenario, you're making a flawed assumption:

You can predict what flexibility points your consumers will need.

You can't.

This codebase demonstrates an alternative approach: don't predict flexibility—provide composability.

Two Approaches to Abstraction

Let's make this concrete. Imagine you need buttons with different colors and behaviors.

❌ Configuration-Based DRY (The Footgun)

// Attempt to predict all variations
const GenericButton = ({
  variant,
  color,
  size,
  disabled,
  loading,
  onClick,
  children
}) => {
  const styles = {
    backgroundColor: color === 'primary' ? 'blue' : color === 'danger' ? 'red' : 'gray',
    fontSize: size === 'large' ? '18px' : '14px',
    opacity: disabled ? 0.5 : 1,
    // ... more conditional styling
  };

  return (
    <button
      style={styles}
      disabled={disabled || loading}
      onClick={onClick}
    >
      {loading ? 'Loading...' : children}
    </button>
  );
};

Why this fails:

Every new variation requires modifying the component
Props proliferate as you discover edge cases
The component becomes brittle—changing one case risks breaking others
Consumers are constrained by your predictions

✅ Composition-Based DRY (This Codebase)

import { createElement, useCallback } from 'react';

// Expose internal primitives for composition
const GenericButton = ({ children, onClick, ...enhancement }) => {
  const track = callback =>
    useCallback(
      (...params) => console.log(callback.toString()) || callback(...params),
      [callback]
    );

  const style = {
    border: "1px solid black",
    fontSize: "14px",
    padding: "10px",
    cursor: "pointer"
  };

  const Button = props => (
    <button
      onClick={track(onClick)}
      style={style}
      {...props}
      {...enhancement}
    />
  );

  // The key: expose pieces for composition
  const pieces = { Button, track, style };

  const isComponent = object => typeof object === "function";

  return isComponent(children)
    ? createElement(children, pieces)  // Pass pieces to function child
    : <Button>{children}</Button>;
};

Why this succeeds:

GenericButton solves one problem: a tracked, styled button primitive
Internal pieces (Button, track, style) are explicitly exposed
Consumers compose what they need without GenericButton knowing about their use cases
No props proliferation—flexibility comes from composition, not configuration

Note: The key mechanism is using createElement to invoke the function child with pieces: createElement(children, pieces). This is what enables the render props pattern.

The Pattern: Render Props for Primitive Exposure

The critical insight is in how GenericButton handles children using the Render Props pattern:

const isComponent = object => typeof object === "function";

return isComponent(children)
  ? createElement(children, pieces)  // Advanced: pass primitives for composition
  : <Button>{children}</Button>;     // Simple: just render a button

This dual consumption pattern enables:

Basic Usage (No Composition)

<GenericButton onClick={() => alert('clicked')}>
  Click Me
</GenericButton>

Advanced Usage (Compose Primitives)

<GenericButton onClick={() => alert('clicked')}>
  {({ Button, style, track }) => (
    <Button style={{ ...style, background: 'green' }}>
      Custom Button
    </Button>
  )}
</GenericButton>

The consumer decides the complexity level. GenericButton doesn't predict it.

Case Study: Progressive Enhancement

Let's trace how different components consume GenericButton with varying levels of composition.

Level 1: Direct Primitive Usage (`ClickMe.js`)

import { createElement } from 'react';
import GenericButton from './GenericButton';

const ClickMe = () => (
  <GenericButton onClick={() => alert("closePage()")}>
    {({ Button, style }) => (
      <Button style={{ ...style, background: "blue" }}>
        ClickMe
      </Button>
    )}
  </GenericButton>
);

export default ClickMe;

What's happening:

Receives Button and style from GenericButton
Spreads base styles and overrides background
Reuses tracking and base button logic without reimplementation

Level 2: Layered Composition (`Activable.js`)

import { createElement } from 'react';
import GenericButton from './GenericButton';

const identify = component =>
  Object.assign(component, { displayName: "Custom(GenericButton)" });

const Activable = ({ onClick, children, active }) => (
  <GenericButton onClick={onClick} disabled={!active}>
    {pieces => createElement(identify(children), pieces)}
  </GenericButton>
);

export default Activable;

What's happening:

Wraps GenericButton to add activation state behavior
Acts as a composition middleware—receives pieces from GenericButton and forwards them
Uses createElement(identify(children), pieces) to invoke the child function with pieces
Uses identify to set component displayName for React DevTools
Doesn't know what children will do with pieces
Single responsibility: map active prop to disabled state

Level 3: Complex Composition with Side Effects (`Input.js`)

import { createElement, useState, useEffect } from 'react';
import GenericButton from './GenericButton';

const URL = "https://placekitten.com/300/300";

const createImage = src => {
  const img = new Image();
  img.src = src;
  return img;
};

const Input = () => {
  const [loading, setLoading] = useState(true);
  const load = () => setLoading(false);

  useEffect(() => {
    createImage(URL).addEventListener("load", load, true);
  }, []);

  return (
    <GenericButton>
      {({ track, style }) =>
        loading ? (
          <p style={{ ...style, border: "none", cursor: "default" }}>
            Loading image...
          </p>
        ) : (
          <input
            type="image"
            src={URL}
            alt="Image as button"
            onClick={track(() => alert("clickImage()"))}
            onMouseOver={track(() => console.log("mouseOverImage()"))}
            onMouseOut={track(() => console.log("mouseOutImage()"))}
            style={{ ...style, padding: "0" }}
          />
        )
      }
    </GenericButton>
  );
};

export default Input;

What's happening:

Uses only track and style pieces (ignores Button)
Renders completely different elements (<p> or <input>)
Demonstrates that pieces are à la carte—use what you need
GenericButton never anticipated this use case, yet it works perfectly
Uses React Hooks (useState, useEffect, useCallback) for state management

The Technical Contract

Let's formalize what makes this pattern work.

Type Signature (Conceptual)

// GenericButton's pieces contract
type ButtonPieces = {
  Button: React.ComponentType<React.ButtonHTMLAttributes<HTMLButtonElement>>;
  track: <T extends (...args: any[]) => any>(callback: T) => T;
  style: React.CSSProperties;
};

// GenericButton accepts either:
// 1. ReactNode (simple usage)
// 2. Function receiving pieces (composition usage)
type GenericButtonProps = {
  onClick: () => void;
  children: React.ReactNode | ((pieces: ButtonPieces) => React.ReactNode);
} & React.HTMLAttributes<HTMLButtonElement>;

The Inversion of Control

Traditional configuration-based components force the component to control how consumers use it:

// Component controls the consumer
<GenericButton variant="primary" />  // Consumer limited to predefined variants

Composition-based components invert this (Inversion of Control):

// Consumer controls the composition
<GenericButton>
  {({ Button, style }) => /* Consumer decides what to render */}
</GenericButton>

This is true Dependency Inversion at the component level.

Why This Defeats the Footgun

Let's revisit Swizec's concern: as requirements evolve, configuration-based components become unmaintainable.

Scenario: New Requirement Arrives

Requirement: "We need a button that shows an image after loading."

Configuration Approach (Breaks Down)

// Now GenericButton needs to know about images and loading states
<GenericButton
  variant="image-loader"
  imageUrl="..."
  showLoadingText={true}
  loadingText="Loading image..."
  onImageLoad={...}
/>

Every new requirement modifies GenericButton. This is the footgun Swizec warns about:

"Every time you need a variation, you modify the shared component. It grows. It becomes complex. Eventually it's easier to duplicate than to use."

Composition Approach (Scales Naturally)

// GenericButton doesn't change at all
<GenericButton>
  {({ track, style }) =>
    loading ? (
      <p style={style}>Loading...</p>
    ) : (
      <input
        type="image"
        src={imageUrl}
        onClick={track(onClick)}
      />
    )
  }
</GenericButton>

The requirement is handled at the consumer level using exposed primitives. GenericButton remains untouched.

Swizec's Requirements: Solved Without Modification

Let's directly address every requirement Swizec mentions. The key insight: GenericButton never changes—all variations are handled by consumers composing primitives.