React useContext Hook: Daten ohne Props teilen

useContext liest einen Wert, den eine Elternkomponente bereitstellt, sodass eine Komponente tief im Baum ihn bekommt, ohne dass jede Komponente dazwischen ihn als Prop weiterreicht. Du erzeugst einen Context mit createContext, umschließt einen Teil des Baums mit einem Provider mit value und rufst useContext(TheContext) überall dort auf, wo du diesen Wert brauchst.

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

const ThemeContext = createContext('light');

function Button({ children }) {
    const theme = useContext(ThemeContext);
    const dark = theme === 'dark';
    return (
        <button style={{ background: dark ? '#222' : '#eee', color: dark ? '#fff' : '#000' }}>
            {children} ({theme})
        </button>
    );
}

function Toolbar() {
    return (
        <div>
            <Button>Save</Button> <Button>Cancel</Button>
        </div>
    );
}

export default function App() {
    const [theme, setTheme] = useState('light');
    return (
        <div>
            <label>
                <input
                    type="checkbox"
                    checked={theme === 'dark'}
                    onChange={(e) => setTheme(e.target.checked ? 'dark' : 'light')}
                />
                Dark mode
            </label>
            <ThemeContext value={theme}>
                <Toolbar />
            </ThemeContext>
        </div>
    );
}

Toolbar erwähnt das Theme nie, und doch ändern sich beide Buttons, wenn du das Kästchen anhakst. Genau darum geht es bei Context: Die Komponenten in der Mitte tragen keine Prop, die sie nicht nutzen, das Problem des Prop Drilling, das Context löst.

Die drei Schritte

// 1. Create it once, outside any component, usually in its own file
export const ThemeContext = createContext('light');

// 2. Provide a value to a part of the tree
<ThemeContext value={theme}>
    <Page />
</ThemeContext>

// 3. Read it in any component inside that part
const theme = useContext(ThemeContext);

In React 19 ist das Context-Objekt selbst der Provider. Älterer Code schreibt <ThemeContext.Provider value={theme}>, was weiterhin funktioniert, also wirst du beides sehen.

useContext sucht im Baum nach oben den nächsten Provider dieses Context. Eine Komponente liest den nächstgelegenen, also kannst du Provider verschachteln, um einen Wert für einen Abschnitt zu überschreiben.

Der Standardwert

Das Argument von createContext ist das, was useContext zurückgibt, wenn kein Provider über der Komponente steht. Es ändert sich nicht, wenn sich State ändert; es ist ein Fallback.

import { createContext, useContext } from 'react';

const LanguageContext = createContext('en');

const GREETINGS = { en: 'Hello', es: 'Hola', ja: 'こんにちは' };

function Greeting() {
    const lang = useContext(LanguageContext);
    return <p>{GREETINGS[lang]} ({lang})</p>;
}

export default function App() {
    return (
        <div>
            <Greeting />
            <LanguageContext value="es">
                <Greeting />
                <LanguageContext value="ja">
                    <Greeting />
                </LanguageContext>
            </LanguageContext>
        </div>
    );
}

Das erste Greeting hat keinen Provider über sich und bekommt den Standardwert 'en'. Das zweite liest 'es', und das dritte liest das nähere 'ja'. Ändere das äußere value="es" zu value="ja", und nur die zweite Zeile ändert sich.

Context aus einem Kind aktualisieren

Context reicht einen Wert nur nach unten. Damit ein tiefes Kind ihn ändern kann, halte den Wert im State dort, wo der Provider ist, und lege den Setter daneben in den Context.

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

const UserContext = createContext(null);

function LoginButton() {
    const { user, setUser } = useContext(UserContext);
    if (user) {
        return <button onClick={() => setUser(null)}>Log out {user}</button>;
    }
    return <button onClick={() => setUser('Ada')}>Log in as Ada</button>;
}

function Header() {
    const { user } = useContext(UserContext);
    return <p>{user ? `Signed in as ${user}` : 'Not signed in'}</p>;
}

export default function App() {
    const [user, setUser] = useState(null);
    return (
        <UserContext value={{ user, setUser }}>
            <Header />
            <div style={{ padding: 12, border: '1px solid #ccc' }}>
                <LoginButton />
            </div>
        </UserContext>
    );
}

LoginButton ruft setUser auf, der State in App ändert sich, der Provider bekommt einen neuen Wert, und Header aktualisiert sich ebenfalls. Keine der Komponenten hat eine Prop bekommen.

Jeder Konsument rendert neu, wenn sich der Wert ändert

Wenn sich der value eines Providers ändert, rendert React jede Komponente, die useContext dafür aufruft, auch wenn sie in einem memo steckt und ihre Props gleich geblieben sind. React vergleicht alten und neuen Wert mit Object.is. Also ist value={{ user, setUser }} bei jedem Render von App ein neues Objekt, und jeder Konsument rendert erneut, selbst wenn sich user nicht geändert hat.

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

const PlainContext = createContext(null);
const MemoContext = createContext(null);

const PlainReader = memo(function PlainReader() {
    const { name } = useContext(PlainContext);
    console.log('PlainReader rendered');
    return <p>Plain: {name}</p>;
});

const MemoReader = memo(function MemoReader() {
    const { name } = useContext(MemoContext);
    console.log('MemoReader rendered');
    return <p>Memoized: {name}</p>;
});

export default function App() {
    const [name, setName] = useState('Ada');
    const [clicks, setClicks] = useState(0);

    const plainValue = { name, setName };
    const memoValue = useMemo(() => ({ name, setName }), [name]);

    return (
        <div>
            <button onClick={() => setClicks(clicks + 1)}>Unrelated update ({clicks})</button>
            <PlainContext value={plainValue}>
                <PlainReader />
            </PlainContext>
            <MemoContext value={memoValue}>
                <MemoReader />
            </MemoContext>
        </div>
    );
}

Beide Leser loggen beim ersten Render einmal. Klicke auf den Button: Nur PlainReader loggt erneut, weil sein Context ein neues Objekt bekommen hat. useMemo gibt MemoContext dasselbe Objekt, bis sich name ändert, also bleibt MemoReader, wie er ist. Das ist erst wichtig, wenn das Rendern langsam wird; für eine kleine App ist ein neues Objekt pro Render in Ordnung.

Contexts aufteilen

Ein Wert, der sich oft ändert, und ein Wert, der sich nie ändert, sollten sich keinen Context teilen. Wenn der Setter beim State liegt, rendert eine Komponente, die nur setUser aufrufen muss, trotzdem jedes Mal, wenn sich user ändert. Lege sie in zwei Contexts, und jeder Konsument abonniert nur, was er liest:

const UserContext = createContext(null);
const SetUserContext = createContext(() => {});

function UserProvider({ children }) {
    const [user, setUser] = useState(null);
    return (
        <SetUserContext value={setUser}>
            <UserContext value={user}>{children}</UserContext>
        </SetUserContext>
    );
}

setUser aus useState behält für immer dieselbe Identität, also rendern Komponenten, die nur SetUserContext lesen, nie wegen eines Logins. Dieselbe Idee gilt für unabhängige Daten: Ein Theme und ein Warenkorb gehören in getrennte Contexts, nicht in einen großen AppContext.

Ein häufiger letzter Schliff ist ein Custom Hook wie useUser(), der useContext(UserContext) aufruft und einen klaren Fehler wirft, wenn der Provider fehlt, damit Aufrufer das Context-Objekt nie direkt importieren.

Context, Props oder eine State-Bibliothek

• Props sind der Standard. Einen Wert zwei oder drei Ebenen nach unten zu reichen ist klar und leicht nachzuverfolgen.
• Context passt zu Werten, die viele Komponenten in vielen Tiefen brauchen und die sich selten ändern: Theme, Sprache, der angemeldete Nutzer, ein Objekt mit Feature-Flags.
• Eine State-Bibliothek (Redux Toolkit, Zustand, Jotai und andere) passt zu großem State, der sich oft ändert, wenn eine Komponente einen Ausschnitt abonnieren und Renders durch den Rest überspringen soll. Context hat keinen solchen Selektor: Ein Konsument rendert bei jeder Änderung des Werts.

Bevor du zu Context oder einer Bibliothek greifst, prüfe, ob das Übergeben von Komponenten als children das Drilling beseitigt. Oft ist das so, ganz ohne neue API.