Applying the Interface Segregation Principle to Cleaner React Components

This article explains the Interface Segregation Principle, illustrates its original intent with simple code examples, and demonstrates how applying ISP in React—by narrowing component props, avoiding prop drilling, and using context or composition—leads to cleaner, more maintainable front‑end code.

KooFE Frontend Team
KooFE Frontend Team
KooFE Frontend Team
Applying the Interface Segregation Principle to Cleaner React Components

Interface Segregation Principle

The core idea of the Interface Segregation Principle (ISP) is to avoid large interfaces that contain many methods or values; instead, create small, purpose‑specific interfaces. The principle originated at Xerox, where a single job class grew unwieldy over time.

interface Job {
    fax(): void;
    scan(): void;
    print(): void;
}

function print(job: Job) {
    // We're using only a single method from the interface
    // But we expect the entire interface to be implemented
    job.print();
}

When code is split into smaller classes and interfaces that cover only specific tasks, it becomes simpler to implement, maintain, and test.

interface PrintJob {
    print(): void;
}

function print(job: PrintJob) {
    // We only expect the interface to implement the print method
    job.print();
}

Although ISP is straightforward in object‑oriented contexts, applying it in front‑end development can be less obvious because the only interfaces developers usually encounter are prop definitions.

Too Many Dependencies

Consider a React component that receives a full User object as a prop but only uses the name field. This violates ISP because the component depends on more data than it actually needs.

interface Props {
    user: User;
}

function UserGreeting({ user }: Props) {
    return <h1>Hey, {user.name}!</h1>;
}

Refactoring the component to accept only the required name value eliminates the unnecessary dependency.

interface Props {
    name: string;
}

function UserGreeting({ name }: Props) {
    return <h1>Hey, {name}!</h1>;
}

When a component depends on a larger object, tests must mock the entire object, even fields that are irrelevant, making testing more cumbersome.

Prop Drilling

Another common ISP violation is prop drilling—passing a value through multiple components that do not use it, merely to reach a deeper component.

function Dashboard({ user }) {
    return (
        <section>
            <Header />
            ...
        </section>
    );
}

function Header({ user }) {
    return (
        <header>
            <Navigation user={user} />
        </header>
    );
}

function Navigation({ user }) {
    return (
        <nav>
            <UserGreeting name={user.name} />
            ...
        </nav>
    );
}

function UserGreeting({ name }) {
    return <h1>Hey, {name}!</h1>;
}

This pattern misleads developers into thinking each intermediate component needs the full user object, when they actually do not use it.

Solutions include using React context or a state‑management library so that only the component that truly needs the data accesses it directly.

function UserGreeting() {
    const user = useUser();
    return <h1>Hey, {user.name}!</h1>;
}

Component composition is another alternative that avoids unnecessary prop passing.

function Dashboard({ user }) {
    return (
        <section>
            <Header>
                <Navigation>
                    <UserGreeting name={user.name} />
                </Navigation>
            </Header>
        </section>
    );
}

Simplicity

The Interface Segregation Principle can be summed up in one sentence: code should not depend on values or methods it does not use. By keeping interfaces (or prop definitions) minimal, React components become easier to understand, test, and evolve.

ReActFrontend ArchitectureSOLIDinterface segregation
KooFE Frontend Team
Written by

KooFE Frontend Team

Follow the latest frontend updates

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.