Prop Drilling in React: Was es ist und wie du es vermeidest

Prop Drilling heißt, eine Prop durch Komponenten zu reichen, die sie nicht nutzen, nur damit eine Komponente weiter unten im Baum es kann. Hier wandert user von App über Page und Sidebar zu Avatar, der einzigen Komponente, die es liest.

import { useState } from 'react';

function Avatar({ user }) {
    return <strong>{user.name}</strong>;
}

function Sidebar({ user }) {
    console.log('Sidebar got user, but only passes it on');
    return (
        <aside style={{ padding: 8, background: '#f3f3f3' }}>
            Signed in as <Avatar user={user} />
        </aside>
    );
}

function Page({ user }) {
    console.log('Page got user, but only passes it on');
    return (
        <main>
            <h3>Dashboard</h3>
            <Sidebar user={user} />
        </main>
    );
}

export default function App() {
    const [user, setUser] = useState({ name: 'Ada' });
    return (
        <div>
            <button onClick={() => setUser({ name: user.name === 'Ada' ? 'Linus' : 'Ada' })}>
                Switch user
            </button>
            <Page user={user} />
        </div>
    );
}

Vier Ebenen, und nur die letzte interessiert sich für user. Die Konsole zeigt, wie Page und Sidebar für einen Wert laufen, den sie nie anzeigen. Klicke auf den Button, und sie loggen erneut.

Warum es schmerzt

Zwei oder drei Ebenen sind in Ordnung. Zum Problem wird Prop Drilling, wenn der Baum wächst:

• Die Komponenten in der Mitte tragen Props, die sie nicht nutzen. Page und Sidebar haben jetzt eine Prop user in ihrer Signatur, also kannst du sie nicht lesen, ohne dich zu fragen, wofür sie ist.
• Jede Änderung berührt jede Ebene. Füge user.avatarUrl oder einen zweiten Wert wie onLogout hinzu, und du bearbeitest jede Komponente auf dem Weg, nicht nur die beiden Enden.
• Eine Komponente zu verschieben bricht die Kette. Verschiebe Avatar in einen anderen Zweig, und du musst user durch einen neuen Weg fädeln.
• Eine Prop geht leicht verloren. Vergiss, sie in einer Ebene weiterzugeben, und die tiefe Komponente bekommt undefined, ohne Fehler an der Ebene, die sie verloren hat.

Probiere es: Füge in App eine Funktion onLogout hinzu, die Avatar aufrufen soll. Du wirst alle vier Komponenten bearbeiten.

Lösung 1: Komposition mit children

Diese Lösung wird oft übersehen. Statt Daten nach unten zu reichen, damit eine tiefe Komponente damit rendern kann, lass die Komponente, der die Daten gehören, die tiefe Komponente selbst rendern, und reich das fertige Element als children (oder als beliebige andere Prop) nach unten. Die Ebenen in der Mitte rendern einen Slot und sehen user nie.

import { useState } from 'react';

function Avatar({ user }) {
    return <strong>{user.name}</strong>;
}

function Sidebar({ children }) {
    console.log('Sidebar rendered');
    return <aside style={{ padding: 8, background: '#f3f3f3' }}>{children}</aside>;
}

function Page({ sidebar }) {
    console.log('Page rendered');
    return (
        <main>
            <h3>Dashboard</h3>
            {sidebar}
        </main>
    );
}

export default function App() {
    const [user, setUser] = useState({ name: 'Ada' });
    return (
        <div>
            <button onClick={() => setUser({ name: user.name === 'Ada' ? 'Linus' : 'Ada' })}>
                Switch user
            </button>
            <Page
                sidebar={
                    <Sidebar>
                        Signed in as <Avatar user={user} />
                    </Sidebar>
                }
            />
        </div>
    );
}

Page und Sidebar wissen nicht mehr, dass es einen Nutzer gibt. App erzeugt Avatar dort, wo user lebt, und reicht es als fertiges Element nach unten. Solche Layout-Komponenten werden wiederverwendbar, und onLogout hinzuzufügen ist jetzt nur noch eine Änderung in App und Avatar. Beide loggen weiterhin bei jedem Klick, weil App ihnen bei jedem Render ein neues Element übergibt: Komposition vereinfacht den Code, nicht die Anzahl der Renders. Die Seite zu children behandelt weitere Slot-Muster.

Komposition funktioniert, wenn die Komponente, der die Daten gehören, auch entscheiden kann, wie der tiefe Teil aussieht. Sie hilft nicht, wenn die tiefe Komponente in einer Bibliothek oder einer Struktur steckt, die der Besitzer nicht rendert.

Lösung 2: Context

Wenn viele Komponenten in verschiedenen Tiefen denselben Wert brauchen (das Theme, den angemeldeten Nutzer, die aktuelle Sprache), leg ihn in Context. Jede Komponente unter dem Provider liest ihn mit useContext, und dazwischen ändert sich nichts.

import { createContext, useContext, useState } from 'react';

const UserContext = createContext(null);

function Avatar() {
    const user = useContext(UserContext);
    return <strong>{user.name}</strong>;
}

function Greeting() {
    const user = useContext(UserContext);
    return <p>Welcome back, {user.name}.</p>;
}

function Sidebar() {
    return (
        <aside style={{ padding: 8, background: '#f3f3f3' }}>
            Signed in as <Avatar />
        </aside>
    );
}

function Page() {
    return (
        <main>
            <Greeting />
            <Sidebar />
        </main>
    );
}

export default function App() {
    const [user, setUser] = useState({ name: 'Ada' });
    return (
        <UserContext value={user}>
            <button onClick={() => setUser({ name: user.name === 'Ada' ? 'Linus' : 'Ada' })}>
                Switch user
            </button>
            <Page />
        </UserContext>
    );
}

Avatar und Greeting lesen den Nutzer aus zwei verschiedenen Tiefen, und Page und Sidebar nehmen keine Props. Füge irgendwo unter Page einen dritten Leser hinzu, und es funktioniert, ohne den Rest anzufassen. Der Preis: Der Datenfluss ist in den Props nicht mehr sichtbar, und jeder Leser rendert, wenn sich der Wert ändert. Die Seite zu useContext behandelt Provider, Standardwerte und diese Renders.

Lösung 3: eine State-Bibliothek

Für großen App-State, den viele Komponenten lesen und der sich oft ändert (ein Warenkorb, ein Dokumenteditor, Live-Daten), lässt eine State-Bibliothek wie Redux Toolkit, Zustand oder Jotai jede Komponente genau den Ausschnitt abonnieren, den sie nutzt. Das vermeidet sowohl das Drilling als auch die Kosten von „jeder Konsument rendert“ bei einem großen Context. Es ist aber eine weitere Abhängigkeit und ein weiterer Satz Konzepte, also greif dazu, wenn die ersten beiden Lösungen nicht mehr reichen, nicht um eine Prop zu reparieren, die drei Ebenen wandert.

// Zustand, for comparison (not available in the editor here)
const useCart = create((set) => ({
    items: [],
    add: (item) => set((s) => ({ items: [...s.items, item] })),
}));

function CartCount() {
    const count = useCart((s) => s.items.length); // renders only when the count changes
    return <span>{count}</span>;
}

Wann Prop Drilling in Ordnung ist

Props zu übergeben ist die Art, wie Daten in React fließen, und es ist das am leichtesten lesbare Muster: Du kannst einen Wert von oben bis unten verfolgen, indem du auf das JSX schaust. Eine Prop, die durch eine oder zwei Komponenten geht, die einen Teil davon nutzen, oder durch eine kurze Kette eng verwandter Komponenten, ist kein Problem, das gelöst werden muss. Verlagere State in das nächste gemeinsame Elternteil, reich ihn nach unten und wechsle den Ansatz erst, wenn die Ebenen in der Mitte anfangen, Props zu tragen, mit denen sie nichts anfangen können.