React Compiler in 2026: Automatische Memoization en Interviewvragen

De React Compiler bereikte in oktober 2025 de stabiele versie 1.0, waarmee een fundamentele verandering plaatsvond in de manier waarop performance-optimalisatie binnen React-applicaties werkt. Voor technische sollicitatiegesprekken in 2026 is het essentieel geworden om de interne werking van de compiler, de memoization-strategie en de scenario's waarin handmatige optimalisatie nog steeds van toepassing is, grondig te begrijpen.

Dit artikel behandelt de kernconcepten van de React Compiler, de compilatiepijplijn, de regels waaraan code moet voldoen, en de meest gestelde interviewvragen over dit onderwerp. Ontwikkelaars die zich voorbereiden op een React-interview vinden hier de technische diepgang die nodig is om deze vragen met vertrouwen te beantwoorden.

Wat is de React Compiler en hoe optimaliseert deze de code?

De React Compiler is een build-time optimaliserende compiler die React-componenten analyseert en automatisch granulaire memoization toevoegt waar dat de performance ten goede komt. In tegenstelling tot handmatige memoization met useMemo of useCallback, kan de compiler conditioneel memoizen met een fijnere granulariteit dan een ontwikkelaar redelijkerwijs zou kunnen onderhouden.

De compiler opereert als een Babel-plugin (met groeiende SWC-ondersteuning in Next.js 15.3.1+). Elke component wordt onafhankelijk verwerkt, waarbij de Babel AST wordt getransformeerd naar een aangepaste High-Level Intermediate Representation (HIR) voordat meerdere optimalisatiepassen worden uitgevoerd.

Productieresultaten van Meta bevestigen de impact: de Quest Store registreerde tot 12% snellere initiële laadtijden en meer dan 2,5x snellere interacties. Sanity Studio rapporteerde een reductie van 20-30% in rendertijd over 1.231 gecompileerde componenten.

Antwoordstructuur voor interviews: Definieer de compiler, leg uit dat deze werkt tijdens build-time (niet runtime), noem de HIR-pipeline en citeer echte metrics.

// Before compilation
function UserProfile({ user, theme }) {
  const fullName = user.firstName + ' ' + user.lastName;
  const style = { color: theme.primary, fontSize: 16 };
  return <div style={style}>{fullName}</div>;
}

// After compilation (simplified representation)
function UserProfile({ user, theme }) {
  const $ = useMemoCache(4);
  let fullName;
  if ($[0] !== user.firstName || $[1] !== user.lastName) {
    fullName = user.firstName + ' ' + user.lastName;
    $[0] = user.firstName;
    $[1] = user.lastName;
    $[2] = fullName;
  } else {
    fullName = $[2];
  }
  // style and JSX similarly memoized...
}

Dit voorbeeld illustreert hoe de compiler een eenvoudige string-concatenatie omzet naar een gecachede berekening. De useMemoCache hook beheert een array van gecachede waarden, en de gegenereerde code vergelijkt de huidige inputwaarden met de vorige voordat de berekening opnieuw wordt uitgevoerd. Het kernpunt voor interviews: de compiler memoized op waardeniveau, niet op componentniveau.

De compilatiepijplijn: van broncode naar geoptimaliseerde output

Deze vraag test diepgaand begrip. De React Compiler-pipeline omvat zeven onderscheiden fasen:

1. Source naar AST — Babel parst JavaScript/TypeScript naar een Abstract Syntax Tree
2. AST naar HIR — De compiler transformeert de AST naar zijn High-Level Intermediate Representation, specifiek ontworpen voor het componentmodel van React
3. SSA-transformatie — Single Static Assignment zorgt ervoor dat elke variabele exact één keer wordt toegewezen, wat nauwkeurige data-flow tracking mogelijk maakt
4. Typeinferentie en effectanalyse — De compiler classificeert operaties naar hun effecten: read, store, capture, mutate, freeze
5. Reactieve analyse — Elke expressie wordt geclassificeerd als statisch (constanten, imports) of reactief (afgeleid van props, state, context)
6. Scope Discovery — De compiler identificeert onafhankelijke memoization-scopes die apart gecached en geïnvalideerd kunnen worden
7. Codegeneratie — Geoptimaliseerd JavaScript met automatische memoization wordt gegenereerd

De analysefase bouwt een dependency graph die laat zien welke berekeningen afhankelijk zijn van welke waarden. De compiler bepaalt voor elke expressie of memoization voordelig is. Triviale berekeningen worden niet gememoized, omdat de overhead van caching groter zou zijn dan de winst.

Rules of React: wat de compiler veronderstelt

De React Compiler voert statische analyse uit onder de aanname dat componenten de Rules of React volgen. Wanneer code deze regels schendt, slaat de compiler de optimalisatie voor dat component over — zonder melding. Dit is een frequent interviewonderwerp.

De drie kernregels:

• Componenten en hooks moeten puur zijn — Bij dezelfde inputs moet het renderen altijd dezelfde output produceren. Geen lezen of schrijven van externe veranderlijke state tijdens het renderen.
• Hooks moeten de aanroepconventies volgen — Hooks mogen niet conditioneel worden aangeroepen, binnen loops of in geneste functies.
• Props en state zijn onveranderlijk binnen een render — Nooit props of state direct muteren; altijd setter-functies gebruiken.

// Rule violation: mutating during render
function BadCounter({ items }) {
  // The compiler will skip this component
  items.sort(); // Mutates the prop array!
  return <ul>{items.map(i => <li key={i}>{i}</li>)}</ul>;
}

// Correct: create a new sorted array
function GoodCounter({ items }) {
  const sorted = [...items].sort();
  return <ul>{sorted.map(i => <li key={i}>{i}</li>)}</ul>;
}

ESLint-integratie: overtredingen detecteren voor de build

Het standalone pakket eslint-plugin-react-compiler is deprecated sinds eind 2025. Alle compiler-gerelateerde lintregels bevinden zich nu in eslint-plugin-react-hooks@latest.

Configuatie met ESLint flat config:

import reactHooks from 'eslint-plugin-react-hooks';
import { defineConfig } from 'eslint/config';

export default defineConfig([
  reactHooks.configs.flat.recommended,
]);

De compiler-aangedreven regels detecteren drie kritieke patronen:

• set-state-in-render — Het aanroepen van setState tijdens het renderen, wat oneindige loops veroorzaakt
• set-state-in-effect — Dure berekeningen binnen effects die cascaderende re-renders triggeren
• refs — Toegang tot .current op refs tijdens het renderen (refs zijn veranderlijke escape hatches, niet render-safe)

Voor interviews is de aanbevolen adoptiestrategie: activeer eerst de ESLint-regels, los alle schendingen op en schakel dan de compiler in. Deze gefaseerde aanpak minimaliseert verrassingen.

Wanneer handmatige optimalisatie nog steeds relevant is

De compiler elimineert niet al het performance-werk. Verschillende scenario's vereisen nog steeds handmatige interventie:

1. Externe store-subscriptions

De compiler volgt alleen React state, props en context. Externe stores (Redux, Zustand, MobX) vereisen useSyncExternalStore of het eigen selectormechanisme van de store voor renderoptimalisatie.

2. Dure berekeningen met grote datasets

Hoewel de compiler retourwaarden memoized, profileert deze niet de uitvoeringskosten. Een functie die 100.000 items filtert, wordt nog steeds uitgevoerd wanneer de dependencies veranderen.

3. Ref-gebaseerde imperatieve logica

Refs zijn opzettelijk uitgesloten van het reactieve model van de compiler. Animaties, canvas-tekening en integratie met DOM-bibliotheken van derden vereisen nog steeds handmatige controle.

4. Cross-component memoization

De compiler memoized binnen een enkel component of hook. Het delen van berekende waarden over componenten vereist nog steeds state lifting, context of externe cachelagen.

// The compiler handles this automatically
function ProductCard({ product, currency }) {
  const formattedPrice = formatCurrency(product.price, currency);
  const discount = product.originalPrice - product.price;
  return (
    <div>
      <span>{formattedPrice}</span>
      {discount > 0 && <Badge>Save {discount}</Badge>}
    </div>
  );
}

// Manual optimization still needed: expensive external computation
function DataGrid({ rows }) {
  const processedRows = useMemo(
    () => rows.map(row => heavyTransform(row)), // O(n) with large n
    [rows]
  );
  return <VirtualList items={processedRows} />;
}

React Compiler inschakelen in verschillende frameworks

Interviewers testen vaak praktische kennis van toolchain-configuratie:

Next.js (15.3.1+): SWC-native ondersteuning. Inschakelen in next.config.js:

const nextConfig = {
  experimental: {
    reactCompiler: true,
  },
};
export default nextConfig;

Vite 8 met @vitejs/plugin-react v6: Aangezien v6 interne Babel heeft laten vallen voor oxc, vereist de compiler @rolldown/plugin-babel:

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import babel from '@rolldown/plugin-babel';
import { reactCompilerPreset } from 'babel-plugin-react-compiler';

export default defineConfig({
  plugins: [
    react(),
    babel({ presets: [reactCompilerPreset] }),
  ],
});

Expo SDK 54+: Standaard ingeschakeld. Geen configuratie nodig.

React Compiler versus handmatige memoization: interviewvergelijking

| Aspect | React Compiler | Handmatig (useMemo/useCallback) | |--------|---------------|-------------------------------------| | Granulariteit | Waardeniveau, per expressie | Blokniveau, door ontwikkelaar bepaald | | Conditionele memoization | Ondersteund | Niet mogelijk | | Onderhoudskosten | Nul — automatisch | Hoog — dependency arrays, wrapper componenten | | Cross-component | Enkele component scope | Enkele component scope | | Externe stores | Niet gevolgd | Niet gevolgd (gebruik useSyncExternalStore) | | Class components | Niet ondersteund | N/A (gebruik React.memo) | | Build-vereiste | Babel-plugin of SWC | Geen | | Performancepotentieel | 20-60% minder re-renders (typisch) | Afhankelijk van ontwikkelaarsvaardigheid |

De interview-gerichte samenvatting: de compiler automatiseert 80-90% van de memoization die ontwikkelaars voorheen handmatig afhandelden, met betere granulariteit en nul onderhoudsoverhead. De overige 10-20% betreft externe integraties, dure berekeningen en imperatief DOM-werk.

Veelgestelde interviewvragen met beknopte antwoorden

V: Werkt de React Compiler tijdens build-time of runtime? Build-time. De compiler is een Babel-plugin die broncode transformeert tijdens compilatie. De geoptimaliseerde output gebruikt een runtime helper (useMemoCache) om gecachede waarden op te slaan, maar alle analyse vindt plaats voor deployment.

V: Moeten bestaande useMemo- en useCallback-aanroepen worden verwijderd? Het React-team raadt aan om bestaande handmatige memoization te behouden. Verwijdering kan de compilatie-output op subtiele manieren veranderen. Voor nieuwe code kan op de compiler worden vertrouwd en hoeft handmatige memoization alleen na profiling bij een specifieke behoefte te worden toegevoegd.

V: Wat gebeurt er wanneer de compiler code tegenkomt die niet kan worden geoptimaliseerd? De compiler slaat dat component of die hook stilzwijgend over. De applicatie blijft correct functioneren — dat specifieke onderdeel draait simpelweg zonder automatische memoization. De ESLint-regels maken deze gevallen zichtbaar tijdens ontwikkeling.

V: Hoe werkt de compiler samen met Server Components? Server Components draaien op de server en produceren geserialiseerde output — ze worden niet opnieuw gerenderd op de client. De compiler richt zich op Client Components waar re-renders de primaire performancezorg zijn. De twee optimalisaties zijn complementair: Server Components reduceren de bundlegrootte, de compiler reduceert de client re-render kosten.

V: Kan de compiler custom hooks optimaliseren? Ja. De compiler analyseert zowel componenten als hooks. Een custom hook die afgeleide state berekent, krijgt zijn retourwaarden automatisch gememoized, wat elk component dat deze aanroept ten goede komt.

V: Is de React Compiler compatibel met class components? Nee. De compiler ondersteunt alleen functionele componenten. Class components moeten worden geconverteerd naar functionele componenten om van automatische memoization te profiteren.

Conclusie

• React Compiler v1.0 is een build-time tool die granulaire memoization op waardeniveau toevoegt via een compilatiepipeline van zeven fasen (AST, HIR, SSA, typeinferentie, effectanalyse, reactieve analyse, codegeneratie)
• De compiler veronderstelt dat componenten de Rules of React volgen; schendingen veroorzaken een stille opt-out, detecteerbaar door eslint-plugin-react-hooks met het recommended preset
• Handmatige optimalisatie blijft noodzakelijk voor externe store-subscriptions, dure berekeningen met grote datasets, ref-gebaseerde imperatieve logica en cross-component caching
• De praktische configuratie verschilt per framework: SWC-native in Next.js, @rolldown/plugin-babel in Vite 8, standaard actief in Expo SDK 54+
• Voor interviews moet gearticuleerd worden wat de compiler automatiseert (80-90% van memoization) en wat niet (externe state, dure cross-component berekeningen, class components)
• Het aanbevolen adoptiepad is eerst ESLint-regels, dan compiler-activering — interviewers vragen hier vaak naar als gefaseerde strategie