useContext: Wesen, der Kontextzugriffs-Hook und Provider in React

Was ist useContext in React

useContext ist ein Hook, der in React 16.8 zusammen mit anderen Hooks hinzugefügt wurde und das Lesen eines Wertes aus dem React-Kontext ermöglicht. Kontext ist ein in React eingebauter Mechanismus, der dazu dient, Daten durch den Komponentenbaum zu leiten, ohne Props auf jeder Ebene manuell übergeben zu müssen. useContext ersetzt die Consumer-Komponente der alten Context API und macht den Code prägnanter und lesbarer.

Typische Anwendungsfälle für Kontext umfassen Designs (hell/dunkel), Gebietsschema und Übersetzungen (i18n), Benutzerauthentifizierung, Anwendungseinstellungen und alle anderen globalen Daten, die viele Komponenten auf verschiedenen Verschachtelungsebenen benötigen. Das React-Team empfiehlt, Kontext für Daten zu verwenden, die für einen Teilbaum von Komponenten global sind, aber nicht für die gesamte Anwendung.

Laut React Team — Kontextdokumentation (2025) ist die falsche Verwendung von Kontext eine der Hauptursachen für Leistungsprobleme in React-Anwendungen. Jede Wertänderung im Provider führt zu einem Neurendern aller Konsumenten, unabhängig davon, welcher Teil der Daten sich geändert hat. Die Optimierung durch useMemo und die Aufteilung von Kontexten löst dieses Problem.

import { createContext, useContext } from 'react';

// Kontext mit Standardwert erstellen
const ThemeContext = createContext('hell');

function ThemedButton() {
    const theme = useContext(ThemeContext);
    return <button className={`btn-${theme}`}>Click</button>;
}

Wie Kontext in React funktioniert

Der Kontextmechanismus in React wird durch das Provider-Consumer-Muster implementiert. createContext gibt ein Objekt mit zwei Entitäten zurück: Provider — eine Komponente, die den Wert weitergibt, und das Kontextobjekt selbst, das in useContext verwendet wird. Der Provider wird im Komponentenbaum montiert und gibt den Wert unabhängig von der Verschachtelungstiefe an alle Kindelemente weiter.

Wenn React auf einen useContext-Aufruf stößt, durchläuft es den Fiber-Baum auf der Suche nach dem nächsten Provider für diesen Kontext. Wenn ein Provider gefunden wird, wird dessen Wert zurückgegeben. Wenn kein Provider gefunden wird, wird der an createContext übergebene Standardwert zurückgegeben. Diese Suche erfolgt bei jedem Rendern, aber dank der Memoisierung von Fiber-Knoten ist sie sehr schnell und beeinträchtigt die Leistung nicht.

Laut React — Kontextinterna (2024) verwendet die interne Implementierung von useContext eine verknüpfte Liste von Hooks, ähnlich wie useState. Jeder Hook speichert einen Verweis auf einen Fiber-Knoten, sodass React schnell bestimmen kann, welcher Provider zu diesem Kontext gehört. Wenn ein Provider seinen Wert aktualisiert, markiert React alle Fiber-Knoten, die diesen Kontext verwenden, für das Neurendern.

Provider und verschachtelte Kontexte

Provider-Komponenten können ineinander verschachtelt werden, wodurch eine Hierarchie von Kontexten entsteht. Jeder untergeordnete Provider überschreibt den Wert des übergeordneten für seinen eigenen Teilbaum. Dies ist nützlich, wenn ein Bildschirm ein helles Design benötigt, während ein verschachteltes modales Fenster ein dunkles Design benötigt. useContext gibt immer den Wert des nächsten Providers weiter oben im Baum zurück.

const UserContext = createContext(null);
const ThemeContext = createContext('hell');

function App() {
    return (
        <UserContext.Provider value={{ name: 'Alice' }}>
            <ThemeContext.Provider value='dark'>
                <Profile />
            </ThemeContext.Provider>
        </UserContext.Provider>
    );
}

Erstellen eines Providers mit createContext

Die Funktion createContext(defaultValue) erstellt ein Kontextobjekt. Der Parameter defaultValue wird verwendet, wenn eine Komponente useContext aufruft, aber kein entsprechender Provider weiter oben im Baum vorhanden ist. Ohne defaultValue gibt useContext undefined zurück, was zu unerwarteten Fehlern führen kann. Es wird empfohlen, immer einen sinnvollen Standardwert oder null zu übergeben.

Das Erstellen eines benutzerdefinierten Providers ist ein gängiges Muster zur Kapselung der Kontextlogik. Innerhalb eines solchen Providers wird der Zustand (über useState oder useReducer) gespeichert und über die value-Prop des Providers bereitgestellt. Dies verbirgt Implementierungsdetails vor den Konsumentenkomponenten und zentralisiert die Kontextverwaltungslogik an einem Ort.

// Benutzerdefinierter Provider mit Zustandsverwaltung
const AuthContext = createContext(null);

function AuthProvider({ children }) {
    const [user, setUser] = useState(null);

    const login = useCallback(async (email, pass) => {
        const u = await loginApi(email, pass);
        setUser(u);
    }, []);

    return (
        <AuthContext.Provider value={{ user, login }}>
            {children}
        </AuthContext.Provider>
    );
}

Verwendung von useContext in Kindkomponenten

In funktionalen Komponenten ist useContext der einzige Weg, um auf Kontext zuzugreifen. Es ersetzt die Consumer-Komponente der alten Context API, die das Render-Prop-Muster erforderte: <ThemeContext.Consumer>{value => ...}</ThemeContext.Consumer>. useContext macht den Code linearer und lesbarer, insbesondere bei der Arbeit mit mehreren Kontexten in einer Komponente.

Bei der Verwendung mehrerer Kontexte in einer Komponente rufen Sie einfach useContext mehrmals für jeden Kontext auf. Jeder Aufruf gibt den Wert des entsprechenden Providers zurück. Die Reihenfolge der Aufrufe spielt keine Rolle, da jeder Kontext eine unabhängige Einheit ist. React optimiert mehrere Aufrufe über dasselbe Fiber-Referenzsystem.

function Dashboard() {
    const { user } = useContext(AuthContext);
    const theme = useContext(ThemeContext);
    const { locale } = useContext(I18nContext);

    return (
        <div className={`dashboard-${theme}`}>
            <h1>{locale.greeting}, {user.name}</h1>
        </div>
    );
}

useContext vs Redux: wann was wählen

Die Wahl zwischen useContext und Redux hängt vom Umfang und der Komplexität der Zustandsverwaltung ab. useContext + useReducer ist ein leichter Ersatz für Redux für kleine und mittlere Anwendungen. Es erfordert keine Installation einer externen Bibliothek, ist leichter zu erlernen und für die meisten Aufgaben ausreichend. Redux ist gerechtfertigt, wenn eine strenge Architektur mit Middleware, Entwicklertools und unveränderlichen Aktualisierungen erforderlich ist.

Der Hauptvorteil von Redux gegenüber useContext ist die Optimierung des Neurenderns. Standardmäßig werden bei einer Wertänderung in einem Provider alle Kontextkonsumenten neu gerendert. Redux mit useSelector und shallowEqual ermöglicht es Komponenten, nur bestimmte Teile des Zustands zu abonnieren, was die Anzahl der Neurenderungen in großen Anwendungen erheblich reduziert. Kontext kann auch durch Aufteilung in viele kleine Kontexte optimiert werden.

Laut Redux-Maintainern — Wann Redux verwenden (2024) benötigen 70% der React-Anwendungen kein Redux. Wenn Sie weniger als 50 Komponenten haben und der Zustand keine komplexe Logik mit Caching, Debounce und Seiteneffekten umfasst — ist useContext + useReducer mehr als ausreichend. Redux fügt Boilerplate hinzu und sollte bewusst eingesetzt werden.

Typische Fehler mit useContext

Der häufigste Fehler ist das Neuerstellen des Wertobjekts bei jedem Rendern des Providers. Wenn Sie value={{ user, login }} an den Provider übergeben, wird bei jedem Rendern des Providers ein neues Objekt erstellt, was dazu führt, dass alle Konsumenten neu gerendert werden, selbst wenn sich die Daten nicht geändert haben. Die Lösung besteht darin, den Wert mit useMemo zu memoieren oder separate Kontexte für häufig und selten wechselnde Daten zu verwenden.

• Unnötiges Neurendern — ein neues Wertobjekt bei jedem Provider-Rendern. Verwenden Sie useMemo, um den Wert zu memoieren.
• Zu großer Kontext — ein Provider mit Dutzenden von Feldern führt dazu, dass alle untergeordneten Komponenten neu gerendert werden, wenn sich ein Feld ändert. Teilen Sie ihn nach Bedeutung in mehrere Kontexte auf.
• Fehlender defaultValue — wenn kein Provider gefunden wird, gibt useContext defaultValue zurück, und wenn dieser undefined ist, löst jeder Aufruf einen TypeError aus.
• Verschachtelte Provider desselben Typs — das Überschreiben von Kontext auf tiefen Ebenen kann verwirrend sein und zu unerwarteten Werten führen.

// ❌ Neues Objekt bei jedem Rendern — alle Konsumenten werden neu gerendert
<AuthContext.Provider value={{ user, login }}>{children}</AuthContext.Provider>

// ✅ Memoierter Wert — Neurendern nur bei Änderung von user oder login
const authValue = useMemo(() => ({ user, login }), [user, login]);
<AuthContext.Provider value={authValue}>{children}</AuthContext.Provider>

Um das Problem des „großen Kontexts“ zu lösen, teilen Sie den globalen Zustand in logische Gruppen auf: AuthContext, ThemeContext, I18nContext. Jeder Kontext ist für seinen eigenen Bereich verantwortlich und aktualisiert sich unabhängig. Dies ist einfacher, als zu versuchen, einen riesigen Kontext durch useMemo zu optimieren, und führt zu einem vorhersehbareren Neurenderungsverhalten.