Forem: Niels Søholm

SOLID in React #3 — The Liskov Substitution Principle

Niels Søholm — Thu, 09 Oct 2025 19:15:56 +0000

Ever swapped out a service or component and suddenly half your UI broke?
You didn’t change what it did — you only changed how it did it.

That’s a Liskov Substitution Principle (LSP) problem hiding in plain sight.

Subtypes must be usable wherever their base type is expected.

In plain English:

If something claims to implement a contract, you should be able to plug it in anywhere that contract is expected — and everything still works the same.

When we violate LSP, we lose swappability — which makes abstraction pointless.

The smell: a “compatible” replacement that isn’t

Let’s say you abstract your data layer behind a simple UserService so you can later switch between REST and GraphQL.

// userService-rest.ts
export type User = { id: string; name: string };

export interface UserService {
  getUser(id: string): Promise<User>;
}

export const restUserService: UserService = {
  async getUser(id) {
    const res = await fetch(`/api/users/${id}`);
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return res.json();
  },
};

Later, you add a GraphQL version:

// userService-graphql.ts
import { UserService } from "./userService-rest";

export const graphqlUserService: UserService = {
  async getUser(id) {
    const res = await fetch("/graphql", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        query: `{ user(id: "${id}") { id name } }`,
      }),
    });
    const { data } = await res.json();
    return data.user; // seems fine…
  },
};

Looks fine — same shape, same types.
But then someone “optimizes” it:

// graphqlUserService.ts (oops)
export const graphqlUserService: UserService = {
  async getUser(id) {
    const res = await fetch("/graphql", { /* ... */ });
    const { data } = await res.json();
    // ⚠️ returns an array instead of a single object
    return [data.user];
  },
};

TypeScript doesn’t complain (the return type is any from fetch),
but the rest of the app now gets [ { id, name } ] instead of { id, name }.

Everything still “compiles,” but consumers start throwing runtime errors.
That’s a textbook LSP violation — the new subtype broke the behavioral contract.

The LSP mindset: define and respect contracts

LSP isn’t about types matching on paper; it’s about semantics being consistent.

If you define a contract like this:

export interface UserService {
  /** 
   * Fetch a user by id.
   * 
   * Resolves to a single user object when found, 
   * rejects with an error if not found or network fails.
   */
  getUser(id: string): Promise<{ id: string; name: string }>;
}

…then every implementation must honor it.
That means:

Always resolve to one object (not array or partial)
Throw or reject on error, not return null
Preserve property names and types

That’s what allows your UI components to stay decoupled and substitutable.

Applying LSP in a React context

Here’s a React component that depends on that contract:

// UserCard.tsx
import React, { useEffect, useState } from "react";
import type { UserService } from "./userService-rest";

type Props = {
  userId: string;
  provider: UserService;
};

export function UserCard({ userId, provider }: Props) {
  const [user, setUser] = useState<{ id: string; name: string } | null>(null);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    provider.getUser(userId)
      .then(setUser)
      .catch((e) => setError(e.message));
  }, [userId, provider]);

  if (error) return <p>Error: {error}</p>;
  if (!user) return <p>Loading...</p>;
  return <p>{user.name}</p>;
}

Now you can freely swap providers:

<UserCard userId="123" provider={restUserService} />
<UserCard userId="123" provider={graphqlUserService} />

If both implementations adhere to the same contract, UserCard doesn’t care where the data came from.
That’s LSP enabling flexibility.

Enforcing LSP with TypeScript and contract tests

TypeScript already enforces structural compatibility — but we can go further by locking down semantics and verifying them with tests.

1. Strengthen the type

Let’s make the interface explicit and strict:

// userService.ts
export interface UserService {
  getUser(id: string): Promise<{ id: string; name: string }>;
}

Then ensure every implementation explicitly declares it:

export const graphqlUserService: UserService = {
  async getUser(id) {
    const res = await fetch("/graphql", { /* ... */ });
    const { data } = await res.json();
    // ✅ return exactly the same shape
    return { id: data.user.id, name: data.user.name };
  },
};

If someone later tries to return an array, TypeScript will immediately flag it.

2. Behavioral contract tests

Even with types, semantics can drift.
So write a small test suite that verifies any implementation of UserService behaves correctly.

// userService.contract.test.ts
import type { UserService } from "./userService-rest";
import { restUserService } from "./userService-rest";
import { graphqlUserService } from "./userService-graphql";

async function assertUserService(provider: UserService) {
  const user = await provider.getUser("123");
  expect(user).toHaveProperty("id");
  expect(user).toHaveProperty("name");
  expect(typeof user.id).toBe("string");
}

test("REST service follows contract", async () => {
  await assertUserService(restUserService);
});

test("GraphQL service follows contract", async () => {
  await assertUserService(graphqlUserService);
});

If either provider breaks the contract (wrong shape, missing fields, bad error behavior), the test catches it immediately — long before runtime.

This enforces behavioral substitutability, not just type compatibility.

Common LSP pitfalls in frontend

Prop contracts that subtly differ

   // Old
   <Input value="abc" onChange={(v) => setValue(v)} />

   // New (breaking)
   <input value="abc" onChange={(e) => setValue(e.target.value)} />

Same props in name, different semantics — callers must now change. That’s an LSP break.

Visual components with mismatched accessibility

   function Button({ onClick }: { onClick: () => void }) {
     return <button onClick={onClick}>Save</button>;
   }

   // “Replacement”
   function LinkButton({ onClick }: { onClick: () => void }) {
     return <a onClick={onClick}>Save</a>; // ❌ breaks keyboard behavior
   }

Props match, but the accessible behavior doesn’t — callers expect a “button,” not a “link.”

Hooks that drift

   // Old
   function useAuth() { return { user, login, logout }; }

   // New
   function useAuth() { return { currentUser: user, signIn: login }; } // ❌ breaks every consumer

Hooks are contracts too — changing shape or semantics breaks substitution.

Quick heuristics

Before swapping a component, service, or hook, ask:

Can consumers use it without code changes?
Does it behave the same under the same inputs?
Would tests for the old one still pass with the new one?

If not — you’ve broken LSP.

Wrap-up

The Liskov Substitution Principle is what makes abstraction work.
It ensures that when you define an interface, every implementation can stand in for it safely — keeping your components, hooks, and services decoupled and interchangeable.

In React, this translates to honoring contracts:

Component props mean what they say
Hooks return consistent shapes
Services behave the same regardless of backend

When every part of your system keeps its promises, refactoring stops feeling risky — and flexibility becomes effortless.

SOLID in React #2 — The Open/Closed Principle

Niels Søholm — Wed, 08 Oct 2025 18:37:49 +0000

You build a component. It’s simple and clean—until someone needs “just one more variant.”
You add a flag, then another, maybe a conditional for a “special case.”
Suddenly, that tidy file has more ifs than a choose-your-own-adventure novel.

That’s exactly the situation the Open/Closed Principle (OCP) aims to prevent.

Open for extension, closed for modification.

In React, that means:
Don’t rewrite or add conditionals every time requirements grow.
Instead, design components that can be extended—and React’s composition model gives you that for free.

The smell: configuration-driven components that keep growing

Here’s a familiar anti-pattern:

// Modal.tsx (BEFORE)
import React from "react";

type ModalProps = {
  title: string;
  content: string;
  showFooter?: boolean;
  footerText?: string;
  onConfirm?: () => void;
  showCloseButton?: boolean;
};

export function Modal({
  title,
  content,
  showFooter = true,
  footerText = "OK",
  onConfirm,
  showCloseButton = true,
}: ModalProps) {
  return (
    <div className="modal">
      <header>
        <h3>{title}</h3>
        {showCloseButton && <button>x</button>}
      </header>
      <main>{content}</main>
      {showFooter && (
        <footer>
          <button onClick={onConfirm}>{footerText}</button>
        </footer>
      )}
    </div>
  );
}

This works fine—until you need a new variation:

A modal with a form
A modal with multiple action buttons
A modal that shows progress

Each new use case means adding props, conditionals, and more if statements.
Every change risks breaking something that already works.

The OCP mindset: composition over configuration

Instead of adding more props, make your component composable.
Let consumers decide what goes inside, while keeping the outer shell stable.

// Modal.tsx (AFTER)
import React from "react";

type ModalProps = {
  children: React.ReactNode;
};

export function Modal({ children }: ModalProps) {
  return (
    <div className="modal">
      <div className="modal-content">{children}</div>
    </div>
  );
}

Now the modal just provides structure.
Everything inside is up to the consumer:

// Example usages
<Modal>
  <h3>Delete item?</h3>
  <p>This action cannot be undone.</p>
  <button>Confirm</button>
</Modal>

<Modal>
  <h3>Upload progress</h3>
  <ProgressBar value={75} />
  <div className="actions">
    <button>Cancel</button>
    <button disabled>Uploading…</button>
  </div>
</Modal>

No new props, no conditionals, no internal edits.
The Modal component is closed for modification, yet open for extension via composition.

Why composition works

Composition flips the responsibility:

The component defines structure and styling (the container).
The consumer defines behavior and content (the variation).

The component doesn’t need to know what’s inside—it just needs to provide the right “slot” for it.
That’s the Open/Closed Principle expressed the React way.

Other idiomatic OCP patterns in React

React has a few other ways to create these extension points.

1. Render Props — when extension needs behavior

Render props let the parent control what gets rendered while the component controls how state or effects are managed.

// DataLoader.tsx
import React, { useEffect, useState } from "react";

type DataLoaderProps<T> = {
  url: string;
  render: (data: T | null, loading: boolean, error: Error | null) => React.ReactNode;
};

export function DataLoader<T>({ url, render }: DataLoaderProps<T>) {
  const [data, setData] = useState<T | null>(null);
  const [error, setError] = useState<Error | null>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch(url)
      .then((r) => r.json())
      .then(setData)
      .catch(setError)
      .finally(() => setLoading(false));
  }, [url]);

  return <>{render(data, loading, error)}</>;
}

Consumers decide how to display data, errors, or loading states:

<DataLoader
  url="/api/users"
  render={(data, loading, error) => {
    if (loading) return <Spinner />;
    if (error) return <ErrorMessage />;
    return <UserList users={data} />;
  }}
/>

The data-fetching logic stays untouched; new visuals just plug in.

2. Slots — named composition for structured layouts

Sometimes you want predictable structure (like header/body/footer) while still allowing flexibility.

// Card.tsx
type CardProps = {
  header?: React.ReactNode;
  children: React.ReactNode;
  footer?: React.ReactNode;
};

export function Card({ header, children, footer }: CardProps) {
  return (
    <div className="card">
      {header && <div className="card-header">{header}</div>}
      <div className="card-body">{children}</div>
      {footer && <div className="card-footer">{footer}</div>}
    </div>
  );
}

Consumers can mix and match freely:

<Card
  header={<h2>User Info</h2>}
  footer={<button>Save</button>}
>
  <ProfileForm />
</Card>

The card stays unchanged even as layouts evolve.

3. Hooks — extending logic instead of markup

Hooks let you extend or compose behavior rather than structure.

// useModal.ts
import { useState } from "react";

export function useModal() {
  const [open, setOpen] = useState(false);
  const toggle = () => setOpen((o) => !o);
  return { open, toggle };
}

Different components can reuse and extend this logic however they like:

const { open, toggle } = useModal();

<button onClick={toggle}>Toggle</button>
{open && (
  <Modal>
    <h3>Hello</h3>
    <button onClick={toggle}>Close</button>
  </Modal>
)}

The behavior is extendable and composable, yet the hook itself remains stable.

Practical benefits

Stable core components — no rewrites for new cases
Reduced risk — fewer regressions from prop bloat
Composable API — developers build new behavior from existing parts
Clear ownership — each unit does one thing and exposes extension seams

When you’re violating OCP

You’re adding new props or if branches every sprint
Components in common/ change constantly for unrelated features
Consumers need to fork or copy code to get small variations

In those cases, you’re missing a clean extension point.

Wrap-up

React makes the Open/Closed Principle feel natural: design components that can be composed, not configured.
If you’re adding another boolean prop or switch case, ask yourself:

“Could this instead be a child, a render prop, or a hook?”

When you embrace composition, your components stop growing in complexity and start growing in capability.

SOLID in React #1 — The Single Responsibility Principle

Niels Søholm — Mon, 06 Oct 2025 19:52:14 +0000

The Single Responsibility Principle (SRP) is the “S” in SOLID and it’s beautifully simple:

Do one thing, and do it well.

In frontend apps, SRP means separating rendering, data fetching, state orchestration, and side-effects.

Keep UI components presentational, move logic into hooks/services, and isolate side-effects, and let services handle I/O.

The payoff: easier testing, fewer merge conflicts, simpler reuse, higher maintainability.

The smell: a bloated component

Let’s start with a realistic “before” example. It renders UI, fetches data, polls, handles errors, and updates the document title—all in one file.

// UserProfile.tsx (BEFORE)
// ❌ Violates SRP: rendering + async fetching + polling + side-effects all here.
import React, { useEffect, useState } from "react";

type User = { id: string; name: string; bio?: string };

export function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState<User | null>(null);
  const [status, setStatus] = useState<"idle" | "loading" | "error" | "success">("idle");
  const [error, setError] = useState<string | null>(null);

  // data fetching + polling
  useEffect(() => {
    let cancelled = false;
    let interval: number | undefined;

    async function fetchUser() {
      try {
        setStatus("loading");
        const res = await fetch(`/api/users/${userId}`);
        if (!res.ok) throw new Error(`HTTP ${res.status}`);
        const data: User = await res.json();
        if (!cancelled) {
          setUser(data);
          setStatus("success");
        }
      } catch (e: any) {
        if (!cancelled) {
          setError(e.message);
          setStatus("error");
        }
      }
    }

    fetchUser();
    // poll every 30s
    interval = window.setInterval(fetchUser, 30_000);

    return () => {
      cancelled = true;
      if (interval) window.clearInterval(interval);
    };
  }, [userId]);

  // side-effect: set document title
  useEffect(() => {
    document.title = user ? `${user.name} | Profile` : "Loading…";
  }, [user]);

  if (status === "loading") return <p>Loading…</p>;
  if (status === "error") return <p>Could not load user: {error}</p>;

  return (
    <section>
      <h2>{user?.name}</h2>
      <p>{user?.bio ?? "No bio yet."}</p>
      <button onClick={() => alert("Followed!")}>Follow</button>
    </section>
  );
}

Problems:

Hard to test: you need to stub fetch, timers, and assert UI—all at once.
Hard to reuse: the polling rules are tied to this component.
Hard to change: any tweak risks merge conflicts because everything lives here.
Hard to understand: you need to "load up" a fairly involved mental model to understand and modify it with confidence.

SRP-minded refactor: split responsibilities

We’ll split into:

A service that knows how to talk to the API (pure I/O function).
A hook that orchestrates data fetching and polling.
A presentational component that renders UI from data.
A tiny side-effect hook to own the document.title concern.

1) Service: pure data access

// services/userService.ts
export type User = { id: string; name: string; bio?: string };

export async function fetchUser(id: string, signal?: AbortSignal): Promise<User> {
  const res = await fetch(`/api/users/${id}`, { signal });
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return res.json();
}

Single job: call the API and return data (or throw).
Easy to mock: swap with a test double in unit tests.

2) Hook: state + orchestration (no rendering)

// hooks/useUser.ts
import { useEffect, useMemo, useRef, useState } from "react";
import { fetchUser, User } from "../services/userService";

type Status = "idle" | "loading" | "error" | "success";

export function useUser(userId: string, { pollMs = 30_000 } = {}) {
  const [data, setData] = useState<User | null>(null);
  const [status, setStatus] = useState<Status>("idle");
  const [error, setError] = useState<string | null>(null);

  const abortRef = useRef<AbortController | null>(null);

  useEffect(() => {
    let cancelled = false;
    const controller = new AbortController();
    abortRef.current?.abort();
    abortRef.current = controller;

    async function run() {
      setStatus("loading");
      setError(null);
      try {
        const user = await fetchUser(userId, controller.signal);
        if (!cancelled) {
          setData(user);
          setStatus("success");
        }
      } catch (e: any) {
        if (!cancelled && e.name !== "AbortError") {
          setError(e.message);
          setStatus("error");
        }
      }
    }

    run();

    const id = window.setInterval(run, pollMs);
    return () => {
      cancelled = true;
      controller.abort();
      window.clearInterval(id);
    };
  }, [userId, pollMs]);

  return useMemo(() => ({ data, status, error }), [data, status, error]);
}

Single job: own data fetching lifecycle.
UI-agnostic: can be reused across components or pages.

3) Side-effect hook: `document.title`

// hooks/useDocumentTitle.ts
import { useEffect } from "react";

export function useDocumentTitle(title: string) {
  useEffect(() => {
    const prev = document.title;
    document.title = title;
    return () => {
      document.title = prev;
    };
  }, [title]);
}

One job: keep the browser tab title in sync.
Easily tested or ignored in tests.

4) Presentational component: render-only

// components/UserProfileView.tsx
import React from "react";
import type { User } from "../services/userService";

type Props = {
  user: User | null;
  status: "idle" | "loading" | "error" | "success";
  error?: string | null;
  onFollow?: () => void;
};

export function UserProfileView({ user, status, error, onFollow }: Props) {
  if (status === "loading") return <p>Loading…</p>;
  if (status === "error") return <p>Could not load user: {error}</p>;
  if (!user) return null;

  return (
    <section>
      <h2>{user.name}</h2>
      <p>{user.bio ?? "No bio yet."}</p>
      <button onClick={onFollow}>Follow</button>
    </section>
  );
}

Single job: render prop-based state.
Dead-simple to snapshot test or storybook.

Glue it together

// UserProfile.tsx (AFTER)
import React from "react";
import { useUser } from "./hooks/useUser";
import { useDocumentTitle } from "./hooks/useDocumentTitle";
import { UserProfileView } from "./components/UserProfileView";

export function UserProfile({ userId }: { userId: string }) {
  const { data, status, error } = useUser(userId, { pollMs: 30_000 });
  useDocumentTitle(status === "success" && data ? `${data.name} | Profile` : "Loading…");

  return (
    <UserProfileView
      user={data}
      status={status}
      error={error}
      onFollow={() => alert("Followed!")}
    />
  );
}

Now each unit has one clear responsibility:

userService.ts: remote I/O
useUser: state + lifecycle
useDocumentTitle: page chrome side-effect
UserProfileView: rendering

Testing gets easier (and faster)

With SRP, you can test each part in isolation.

Test the service (integration-ish, with MSW or a real test server)

// services/userService.test.ts
import { fetchUser } from "./userService";
// with MSW, define a handler for GET /api/users/:id

test("returns user when 200 OK", async () => {
  const user = await fetchUser("123");
  expect(user.id).toBe("123");
});

test("throws on non-OK", async () => {
  await expect(fetchUser("404")).rejects.toThrow(/HTTP 404/);
});

Test the hook (unit: mock the service)

// hooks/useUser.test.tsx
import { renderHook, waitFor } from "@testing-library/react";
import * as service from "../services/userService";
import { useUser } from "./useUser";

jest.spyOn(service, "fetchUser");

test("loads user and sets status", async () => {
  (service.fetchUser as jest.Mock).mockResolvedValue({ id: "123", name: "Ada" });

  const { result } = renderHook(() => useUser("123", { pollMs: 60_000 }));
  expect(result.current.status).toBe("loading");

  await waitFor(() => expect(result.current.status).toBe("success"));
  expect(result.current.data?.name).toBe("Ada");
});

Test the view (pure rendering)

// components/UserProfileView.test.tsx
import { render, screen } from "@testing-library/react";
import { UserProfileView } from "./UserProfileView";

test("shows name when success", () => {
  render(<UserProfileView user={{ id: "1", name: "Ada" }} status="success" />);
  expect(screen.getByText("Ada")).toBeInTheDocument();
});

No global fetch mocks in UI tests, no timers to juggle, no document title assertions unless you’re testing the small hook. Lower friction, faster feedback.

Tools you might use:

React Testing Library

MSW for API mocking during tests and local dev

Jest or Vitest

SRP heuristics for React

Name your units after their job. If you can’t describe it in one short phrase, it probably has more than one responsibility.
UI components render. If they start performing I/O, timers, or global side-effects, consider extracting a hook or a service.
Hooks orchestrate state. They don’t render, and they should avoid DOM mutations outside React (leave that to the browser or small effect hooks).
Services talk to the outside world. Keep them small and pure (params in, data/error out).
Prefer composition over conditionals. Multiple responsibilities often appear as long if/else blocks; split them into smaller components or hooks.
Test the smallest stable seam. Views via RTL, hooks via renderHook, services via MSW or direct mocks.

Common objections (and responses)

“But I’ll have more files.”
True—and each one is shorter, easier to read, and easier to diff. Merge conflicts go down because teams touch different files.
“Isn’t this premature abstraction?”
SRP isn’t abstraction for abstraction’s sake. It’s a guideline to keep responsibilities cohesive. Start simple; extract when a concern grows.
“Performance?”
Splitting into components/hooks doesn’t inherently hurt performance. In fact, clearer boundaries make memoization and virtualization easier.

Wrap-up

Single responsibility principle in React isn’t academic. It’s a practical way to reduce coupling, shrink tests, increase reuse and increase maintainability. Keep UI presentational, push logic into hooks, isolate side-effects, and let services handle I/O.

Do one thing, do it well.

Forem: Niels Søholm

SOLID in React #3 — The Liskov Substitution Principle

The smell: a “compatible” replacement that isn’t

The LSP mindset: define and respect contracts

Applying LSP in a React context

Enforcing LSP with TypeScript and contract tests

1. Strengthen the type

2. Behavioral contract tests

Common LSP pitfalls in frontend

Quick heuristics

Wrap-up

SOLID in React #2 — The Open/Closed Principle

The smell: configuration-driven components that keep growing

The OCP mindset: composition over configuration

Why composition works

Other idiomatic OCP patterns in React

1. Render Props — when extension needs behavior

2. Slots — named composition for structured layouts

3. Hooks — extending logic instead of markup

Practical benefits

When you’re violating OCP

Wrap-up

SOLID in React #1 — The Single Responsibility Principle

The smell: a bloated component

SRP-minded refactor: split responsibilities

1) Service: pure data access

2) Hook: state + orchestration (no rendering)

3) Side-effect hook: document.title

4) Presentational component: render-only

Glue it together

Testing gets easier (and faster)

Test the service (integration-ish, with MSW or a real test server)

Test the hook (unit: mock the service)

Test the view (pure rendering)

SRP heuristics for React

Common objections (and responses)

Wrap-up

3) Side-effect hook: `document.title`