Prop drilling w React: co to jest i jak go unikać

Prop drilling to przekazywanie propsa przez komponenty, które go nie używają, tylko po to, żeby mógł go użyć komponent niżej w drzewie. Tutaj user wędruje z App przez Page i Sidebar, żeby dotrzeć do Avatar, jedynego komponentu, który go czyta.

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>
    );
}

Cztery poziomy, a tylko ostatni interesuje się user. Konsola pokazuje, że Page i Sidebar wykonują się dla wartości, której nigdy nie wyświetlają. Kliknij przycisk, a znowu wypiszą log.

Dlaczego to szkodzi

Dwa albo trzy poziomy są w porządku. Prop drilling staje się problemem, gdy drzewo rośnie:

• Komponenty pośrodku noszą propsy, których nie używają. Page i Sidebar mają teraz w sygnaturze prop user, więc nie da się ich czytać bez zastanawiania się, do czego służy.
• Każda zmiana dotyka każdej warstwy. Dodaj user.avatarUrl albo drugą wartość, na przykład onLogout, a edytujesz każdy komponent na ścieżce, a nie tylko dwa końce.
• Przeniesienie komponentu przerywa łańcuch. Przenieś Avatar do innej gałęzi, a będziesz musiał przeprowadzić user nową ścieżką.
• Łatwo zgubić prop. Zapomnij przekazać go w jednej warstwie, a głęboki komponent dostanie undefined, bez żadnego błędu w warstwie, która go zgubiła.

Spróbuj: dodaj w App funkcję onLogout, którą ma wywołać Avatar. Edytujesz wszystkie cztery komponenty.

Rozwiązanie 1: kompozycja z children

To rozwiązanie ludzie pomijają. Zamiast przekazywać dane w dół, żeby głęboki komponent mógł się z nimi wyrenderować, pozwól komponentowi, który jest właścicielem danych, samemu wyrenderować głęboki komponent i przekaż gotowy element w dół jako children (albo dowolny inny prop). Warstwy pośrodku renderują slot i nigdy nie widzą user.

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 i Sidebar już nie wiedzą, że istnieje jakiś użytkownik. App tworzy Avatar tam, gdzie żyje user, i przekazuje go w dół jako gotowy element. Takie komponenty układu stają się wielokrotnego użytku, a dodanie onLogout to teraz zmiana tylko w App i Avatar. Oba nadal wypisują log przy każdym kliknięciu, bo App za każdym razem, gdy się renderuje, przekazuje im nowy element: kompozycja upraszcza kod, a nie zmniejsza liczbę renderowań. Strona o children omawia więcej wzorców ze slotami.

Kompozycja działa, gdy komponent, który jest właścicielem danych, może też zdecydować, jak wygląda głęboka część. Nie pomaga, gdy głęboki komponent siedzi w bibliotece albo w strukturze, której właściciel nie renderuje.

Rozwiązanie 2: kontekst

Gdy wiele komponentów na różnych głębokościach potrzebuje tej samej wartości (motyw, zalogowany użytkownik, bieżący język), umieść ją w kontekście. Każdy komponent pod providerem odczytuje ją przez useContext, a nic pomiędzy się nie zmienia.

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 i Greeting odczytują użytkownika z dwóch różnych głębokości, a Page i Sidebar nie przyjmują żadnych propsów. Dodaj trzeci komponent czytający gdziekolwiek pod Page, a zadziała bez ruszania reszty. Koszt: przepływ danych nie jest już widoczny w propsach, a każdy komponent czytający renderuje się, gdy zmienia się wartość. Strona o useContext omawia providery, wartości domyślne i te ponowne renderowania.

Rozwiązanie 3: biblioteka stanu

Dla dużego stanu aplikacji, który czyta wiele komponentów i który często się zmienia (koszyk, edytor dokumentów, dane na żywo), biblioteka stanu, taka jak Redux Toolkit, Zustand albo Jotai, pozwala każdemu komponentowi subskrybować tylko wycinek, którego używa. Pozwala to uniknąć zarówno drillingu, jak i kosztu „każdy konsument się renderuje" przy jednym dużym kontekście. To też kolejna zależność i kolejny zestaw pojęć, więc sięgaj po nią, gdy dwa pierwsze rozwiązania przestają wystarczać, a nie po to, żeby naprawić prop, który wędruje przez trzy poziomy.

// 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>;
}

Kiedy prop drilling jest w porządku

Przekazywanie propsów to sposób, w jaki płyną dane w React, i najłatwiejszy do czytania wzorzec: możesz prześledzić wartość od góry do dołu, patrząc na JSX. Prop, który przechodzi przez jeden czy dwa komponenty używające jego części albo przez krótki łańcuch blisko związanych komponentów, nie jest problemem do rozwiązania. Podnieś stan do najbliższego wspólnego rodzica, przekaż go w dół i zmieniaj podejście dopiero wtedy, gdy warstwy pośrodku zaczynają nosić propsy, do których nie mają żadnego zastosowania.