useContext: essentie, toegangshook tot context en providers in React

Wat is useContext in React

useContext — is een hook die in React 16.8 is toegevoegd samen met de andere hooks, waarmee je een waarde uit de React context kunt lezen. Context is een ingebouwd mechanisme in React, bedoeld voor het doorgeven van gegevens door de componentenboom zonder dat je handmatig props op elk niveau hoeft door te geven. useContext vervangt de Consumer-component uit de oude Context API en maakt de code beknopter en leesbaarder.

Typische gebruiksscenario’s voor context zijn ontwerpthema’s (licht/donker), regionale instellingen en vertalingen (i18n), gebruikersauthenticatie, applicatie-instellingen en andere globale gegevens die nodig zijn voor veel componenten op verschillende nestniveaus. Het React-team raadt aan om context te gebruiken voor gegevens die globaal zijn voor de subboom van componenten, maar niet voor de hele applicatie.

Volgens React Team — Context documentation (2025) is onjuist gebruik van context een van de belangrijkste oorzaken van prestatieproblemen in React-applicaties. Elke verandering van waarde in de Provider veroorzaakt herrenderen van alle gebruikers, ongeacht welk deel van de gegevens is veranderd. Optimalisatie via useMemo en het splitsen van contexten lost dit probleem op.

import { createContext, useContext } from 'react';

// Context aanmaken met standaardwaarde
const ThemeContext = createContext('licht');

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

Hoe werkt context in React

Het contextmechanisme in React is geïmplementeerd via het Provider-Consumer-patroon. createContext retourneert een object met twee entiteiten: Provider — de component die de waarde doorgeeft, en het contextobject zelf dat in useContext wordt gebruikt. De Provider wordt in de componentenboom gemonteerd en geeft de waarde door aan alle onderliggende elementen, ongeacht de nestdiepte.

Wanneer React een useContext-aanroep tegenkomt, beweegt het omhoog door de fiberboom op zoek naar de dichtstbijzijnde Provider voor die context. Als de Provider wordt gevonden, wordt de waarde ervan geretourneerd. Als de Provider niet wordt gevonden, wordt de standaardwaarde geretourneerd die aan createContext is doorgegeven. Deze zoektocht vindt plaats bij elke render, maar dankzij memorisatie van fiber-knooppunten is deze zeer snel en beïnvloedt de prestaties niet.

Volgens React — Context internals (2024) gebruikt de interne implementatie van useContext een gelinkte lijst van hooks, vergelijkbaar met useState. Elke hook slaat een verwijzing op naar het fiber-knooppunt, waardoor React snel kan bepalen welke Provider bij die context hoort. Als de Provider de waarde bijwerkt, markeert React alle fiber-knooppunten die deze context gebruiken voor herrenderen.

Provider en geneste contexten

Provider-componenten kunnen in elkaar worden genest, waardoor een hiërarchie van contexten ontstaat. Elke onderliggende Provider overschrijft de waarde van de ouder voor zijn subboom. Dit is handig wanneer op het ene scherm een licht thema nodig is en in een genest modaal venster een donker thema. useContext retourneert altijd de waarde van de dichtstbijzijnde Provider hoger in de boom.

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

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

Een provider maken met createContext

De functie createContext(defaultValue) maakt een contextobject. De parameter defaultValue wordt gebruikt wanneer een component useContext aanroept, maar er hoger in de boom geen corresponderende Provider is. Zonder defaultValue retourneert useContext undefined, wat kan leiden tot onverwachte fouten. Het wordt aanbevolen om altijd een zinvolle standaardwaarde of null door te geven.

Het maken van een aangepaste provider is een veelvoorkomend patroon voor het inkapselen van contextlogica. Binnen zo’n provider wordt de status opgeslagen (via useState of useReducer) en beschikbaar gesteld via de value-prop van de Provider. Dit verbergt implementatiedetails voor consumerende componenten en centraliseert de contextbeheerlogica op één plek.

// Aangepaste provider met statusbeheer
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>
    );
}

useContext gebruiken in onderliggende componenten

In functionele componenten is useContext de enige manier om toegang te krijgen tot context. Het vervangt de Consumer-component uit de oude Context API, die het render-prop-patroon vereiste: <ThemeContext.Consumer>{value => ...}</ThemeContext.Consumer>. useContext maakt de code linearer en leesbaarder, vooral bij het werken met meerdere contexten in één component.

Wanneer je meerdere contexten in één component gebruikt, roep je useContext gewoon meerdere keren aan voor elke context. Elke aanroep retourneert de waarde van de bijbehorende Provider. De volgorde van aanroepen doet er niet toe, omdat elke context een onafhankelijke entiteit is. React optimaliseert meerdere aanroepen via hetzelfde systeem van fiber-verwijzingen.

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: wanneer wat kiezen

De keuze tussen useContext en Redux hangt af van de schaal en complexiteit van statusbeheer. useContext + useReducer is een lichte vervanging voor Redux voor kleine en middelgrote applicaties. Het vereist geen installatie van een externe bibliotheek, is gemakkelijker te leren en voldoende voor de meeste taken. Redux is gerechtvaardigd wanneer een strikte architectuur met middleware, ontwikkeltools en onveranderlijke updates nodig is.

Het belangrijkste voordeel van Redux boven useContext is optimalisatie van herrenderingen. Standaard, bij verandering van waarde in de Provider, worden alle contextgebruikers opnieuw gerenderd. Redux met useSelector en shallowEqual stelt componenten in staat om alleen op bepaalde delen van de status te abonneren, wat het aantal herrenderingen in grote applicaties aanzienlijk vermindert. Context kan ook worden geoptimaliseerd door splitsing in meerdere kleine contexten.

Volgens Redux maintainers — When to use Redux (2024) heeft 70% van de React-applicaties geen Redux nodig. Als je minder dan 50 componenten hebt en de status geen complexe logica heeft met caching, debounce en neveneffecten — is useContext + useReducer meer dan voldoende. Redux voegt boilerplate toe en moet bewust worden gebruikt.

Veelvoorkomende fouten met useContext

De meest voorkomende fout is het opnieuw aanmaken van het value-object bij elke render van de Provider. Als je value={{ user, login }} aan de Provider doorgeeft, wordt bij elke render van de Provider een nieuw object gemaakt, wat herrenderen van alle gebruikers veroorzaakt, zelfs als de gegevens niet zijn veranderd. De oplossing — memorisatie van value via useMemo of het gebruik van aparte contexten voor veel en weinig veranderende gegevens.

• Overbodige herrenderingen — nieuw value-object bij elke Provider-render. Gebruik useMemo voor memorisatie van value.
• Te grote context — één Provider met tientallen velden zorgt dat alle onderliggende componenten herrenderen bij verandering van elk veld. Verdeel in meerdere contexten op basis van betekenis.
• Ontbreken van defaultValue — als de Provider niet wordt gevonden, retourneert useContext defaultValue, en als het undefined is — zal elke aanroep mislukken met een TypeError.
• Geneste Providers van hetzelfde type — overschrijven van context op diepe niveaus kan verwarrend zijn en leiden tot onverwachte waarden.

// ❌ Nieuw object bij elke render — alle gebruikers herrenderen
<AuthContext.Provider value={{ user, login }}>{children}</AuthContext.Provider>

// ✅ Gememoriseerde waarde — herrenderen alleen wanneer gebruiker of login verandert
const authValue = useMemo(() => ({ user, login }), [user, login]);
<AuthContext.Provider value={authValue}>{children}</AuthContext.Provider>

Om het probleem van de „grote context” op te lossen, verdeel je de globale status in logische groepen: AuthContext, ThemeContext, I18nContext. Elke context is verantwoordelijk voor zijn eigen domein en werkt onafhankelijk bij. Dit is eenvoudiger dan proberen één gigantische context via useMemo te optimaliseren en geeft voorspelbaarder herrendergedrag.