Context vs. Props Drilling

Was ist Props Drilling?

function App() {
    const user = { name: 'Anna' };
    return <Layout user={user} />;
}

function Layout({ user }) {
    // Layout nutzt user NICHT, reicht ihn nur weiter
    return <Sidebar user={user} />;
}

function Sidebar({ user }) {
    // Sidebar nutzt user NICHT, reicht ihn nur weiter
    return <UserPanel user={user} />;
}

function UserPanel({ user }) {
    // Erst hier wird user genutzt
    return <p>Hallo, {user.name}</p>;
}

Layout und Sidebar haben eine user-Prop, die sie nicht verwenden. Drei Ebenen Boilerplate für einen einzigen Wert. Bei Refactor (neue Zwischen-Komponente, Reihenfolgen-Wechsel, TypeScript-Typen) entstehen viele Berührungs-Punkte.

Lösung 1: Context

const UserContext = createContext(null);

function App() {
    const user = { name: 'Anna' };
    return (
        <UserContext.Provider value={user}>
            <Layout />
        </UserContext.Provider>
    );
}

function Layout() { return <Sidebar />; }
function Sidebar() { return <UserPanel />; }

function UserPanel() {
    const user = useContext(UserContext);
    return <p>Hallo, {user.name}</p>;
}

Layout und Sidebar brauchen die user-Prop nicht mehr. Konsumenten ziehen den Wert direkt aus dem Context.

Lösung 2: Component-Composition

Oft ist die beste Lösung, gar nicht erst durch Zwischen-Komponenten zu drillen — sondern die Konsumenten als children direkt von oben hineinzukomponieren.

function App() {
    const user = { name: 'Anna' };
    return (
        <Layout sidebar={<UserPanel user={user} />}>
            {/* Main-Inhalt */}
        </Layout>
    );
}

function Layout({ sidebar, children }) {
    return (
        <div>
            <aside>{sidebar}</aside>
            <main>{children}</main>
        </div>
    );
}

function UserPanel({ user }) {
    return <p>Hallo, {user.name}</p>;
}

Layout und der Sidebar-Slot sind generisch. UserPanel ist bereits mit Daten gefüllt, bevor es in den Layout-Slot wandert. Kein Drilling, kein Context — saubere Komposition.

Wann was?

Faustregel: Erst Composition versuchen. Wenn das nicht passt: Context für stabile Werte. Für State-Management: spezifische Libraries.

Trade-offs von Context

Vorteile:

• Kein Drilling.
• Direkter Zugriff in beliebiger Tiefe.
• Composable mit anderen Contexts.

Nachteile:

• Re-Render-Kosten: bei value-Wechsel rendern alle Konsumenten, auch wenn sie den geänderten Teil gar nicht nutzen.
• Implizite Abhängigkeit: Komponente, die useContext aufruft, verlangt einen Provider — wird beim Verschieben übersehen.
• Testen wird umständlicher: Tests müssen den Provider drumrum wrappen.
• Tooling-Sichtbarkeit: Props sind in DevTools explizit sichtbar, Context-Werte müssen man explizit aufklappen.

Trade-offs von Props Drilling

Vorteile:

• Explizit — beim Lesen sieht man genau, woher der Wert kommt.
• Refactoring-freundlich für Tools (ESLint, TypeScript erkennen falsche Pfade).
• Keine implizite globale Abhängigkeit.

Nachteile:

• Viel Boilerplate bei vielen Ebenen.
• Refactor-Schmerz: neue Zwischen-Komponente = überall Prop ergänzen.
• Komponenten haben Props, die sie nicht selbst nutzen — Code-Smell.

Beispiel — kombinierte Strategie

In einer realen App nutzen erfahrene Teams beide Werkzeuge bewusst:

// Globaler User (selten gewechselt) — Context
<AuthProvider>
    {/* Theme (selten gewechselt) — Context */}
    <ThemeProvider>
        {/* App-Layout mit Composition für Slots */}
        <Layout
            sidebar={<Sidebar />}
            header={<Header />}
        >
            {/* Form-Daten als Props (lokal) */}
            <UserForm
                initialValues={initialValues}
                onSubmit={handleSubmit}
            />
        </Layout>
    </ThemeProvider>
</AuthProvider>

Auth + Theme → Context (App-weit, selten gewechselt). Layout-Slots → Composition. Form-Daten → Props (lokal, explizit).

Weiterführende Ressourcen

Externe Quellen

• Passing Data Deeply with Context – react.dev
• Before you use Context – react.dev
• Composition vs. Inheritance – Legacy React Docs

Verwandte Artikel

• Einführung Context
• Performance-Fallstricke
• Composition statt Inheritance
• Props
• useContext