Prop Drilling di React: Apa Itu dan Cara Menghindarinya

Prop drilling adalah mengirim prop melewati komponen yang tidak memakainya, hanya agar komponen yang lebih jauh di bawah tree bisa memakainya. Di sini, user berpindah dari App melewati Page dan Sidebar untuk mencapai Avatar, satu-satunya komponen yang membacanya.

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

Empat level, dan hanya level terakhir yang peduli pada user. Konsol menunjukkan Page dan Sidebar berjalan untuk sebuah nilai yang tidak pernah mereka tampilkan. Klik tombolnya, dan keduanya mencatat log lagi.

Kenapa ini merepotkan

Dua atau tiga level itu wajar. Prop drilling menjadi masalah saat tree bertambah besar:

• Komponen di tengah membawa props yang tidak dipakainya. Page dan Sidebar sekarang punya prop user di signature-nya, jadi kamu tidak bisa membacanya tanpa bertanya-tanya untuk apa prop itu.
• Setiap perubahan menyentuh setiap lapisan. Tambahkan user.avatarUrl atau nilai kedua seperti onLogout, dan kamu mengedit setiap komponen di sepanjang jalurnya, bukan hanya kedua ujungnya.
• Memindahkan komponen memutus rantainya. Pindahkan Avatar ke cabang lain, dan kamu harus menyalurkan user lewat jalur baru.
• Prop mudah terlewat. Lupa meneruskannya di satu lapisan, dan komponen di bawah mendapat undefined, tanpa error di lapisan yang kehilangannya.

Coba sendiri: tambahkan fungsi onLogout di App yang harus dipanggil Avatar. Kamu akan mengedit keempat komponen.

Solusi 1: komposisi dengan children

Solusi inilah yang sering dilewatkan orang. Alih-alih mengirim data ke bawah agar komponen di dalam bisa merender dengannya, biarkan komponen pemilik data merender sendiri komponen di dalam itu, lalu kirim elemen jadinya ke bawah sebagai children (atau prop lain). Lapisan tengah merender sebuah slot dan tidak pernah melihat 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 dan Sidebar tidak lagi tahu bahwa ada user. App membuat Avatar di tempat user berada dan menyerahkannya ke bawah sebagai elemen jadi. Komponen layout seperti ini menjadi bisa dipakai ulang, dan menambahkan onLogout sekarang hanya mengubah App dan Avatar. Keduanya tetap mencatat log di setiap klik, karena App mengirim elemen baru setiap kali ia merender: komposisi menyederhanakan kode, bukan jumlah render. Halaman children membahas lebih banyak pola slot.

Komposisi berhasil saat komponen pemilik data juga bisa menentukan tampilan bagian di dalam. Cara ini tidak membantu saat komponen di dalam itu berada di dalam library atau struktur yang tidak dirender oleh pemiliknya.

Solusi 2: context

Saat banyak komponen di kedalaman yang berbeda butuh nilai yang sama (tema, user yang sedang login, bahasa saat ini), taruh nilai itu di context. Komponen mana pun di bawah provider membacanya dengan useContext, dan tidak ada yang berubah di antaranya.

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 dan Greeting membaca user dari dua kedalaman yang berbeda, dan Page serta Sidebar tidak menerima props. Tambahkan pembaca ketiga di mana saja di bawah Page, dan ia langsung berfungsi tanpa menyentuh yang lain. Biayanya: alur data tidak lagi terlihat di props, dan setiap pembaca merender saat nilainya berubah. Halaman useContext membahas provider, nilai default, dan render ulang tersebut.

Solusi 3: library state

Untuk state aplikasi yang besar, dibaca banyak komponen, dan sering berubah (keranjang belanja, editor dokumen, data live), library state seperti Redux Toolkit, Zustand, atau Jotai memungkinkan setiap komponen subscribe hanya ke bagian yang dipakainya. Cara ini menghindari drilling sekaligus biaya "setiap konsumen ikut merender" dari satu context besar. Ini juga berarti satu dependensi tambahan dan sekumpulan konsep baru, jadi pakai saat dua solusi pertama tidak lagi cukup, bukan untuk memperbaiki prop yang berpindah tiga level.

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

Kapan prop drilling tidak masalah

Mengirim props adalah cara data mengalir di React, dan merupakan pola yang paling mudah dibaca: kamu bisa mengikuti sebuah nilai dari atas sampai bawah hanya dengan melihat JSX-nya. Prop yang melewati satu atau dua komponen yang memakai sebagiannya, atau melewati rantai pendek komponen yang saling berkaitan erat, bukan masalah yang perlu dipecahkan. Angkat state ke induk bersama terdekat, kirim ke bawah, dan baru ganti pendekatan saat lapisan tengah mulai membawa props yang tidak ada gunanya bagi mereka.