React Native en TypeScript in 2026: type-veilige architectuur en sollicitatievragen

De type-safety van React Native met TypeScript is medio 2026 flink volwassen geworden: versie 0.87 maakt de Strict TypeScript API tot de verplichte standaard en rondt een ingrijpende modernisering van de toolchain af. TypeScript is niet langer optionele lijm tussen JavaScript en native code. Het stuurt het volledige contract aan, van component-props tot TurboModule-interfaces, en vangt afwijkingen al tijdens de build op in plaats van in crash-logs in productie.

Waarom TypeScript nu de standaard is voor React Native-projecten

Elke aanroep van npx react-native init zet sinds versie 0.76 een TypeScript-project op. De echte verschuiving vond echter plaats op de native grens. Vóór Codegen schreven ontwikkelaars handmatige type-asserties bij de overgang van JavaScript naar Objective-C of Kotlin, een via strings gedefinieerd contract dat stilletjes brak tijdens runtime. Codegen leest TypeScript-specificatiebestanden en genereert daaruit automatisch C++-, Objective-C++- en Java/Kotlin-interfaces. Declareert de TypeScript-specificatie een methode die number teruggeeft, dan dwingt de gegenereerde native interface die beperking af tijdens compilatie.

De React Native-documentatie behandelt de basisopzet, maar de type-veilige patronen die er in productie toe doen, gaan verder: getypeerde navigatiestacks, generieke API-hooks, discriminated unions voor state machines en Codegen-gestuurde TurboModule-specificaties.

De Strict TypeScript API: van opt-in naar standaard

De Strict TypeScript API werd geïntroduceerd in React Native 0.80 als opt-in feature. Vanaf 0.87 is het de verplichte standaard voor alle nieuwe projecten. Types worden direct uit de broncode van React Native gegenereerd in plaats van handmatig onderhouden, wat afwijkingen tussen de gedocumenteerde API en de daadwerkelijke implementatie elimineert.

{
  "extends": "@react-native/typescript-config",
  "compilerOptions": {
    "strict": true,
    "exactOptionalPropertyTypes": true,
    "noUncheckedIndexedAccess": true
  }
}

Met deze configuratie levert het importeren van iets uit een subpad zoals react-native/Libraries/Text/Text een type-fout op. Alle imports moeten uit het root-pakket react-native komen. Als een library of oudere codebase nog steeds afhankelijk is van diepe imports, is er een tijdelijke opt-out beschikbaar tot 0.88:

{
  "extends": "@react-native/typescript-config",
  "compilerOptions": {
    "customConditions": ["react-native", "react-native-legacy-deep-imports"]
  }
}

Deze opt-out wordt verwijderd in 0.89. Migratie moet daarvoor plaatsvinden.

Toolchain-vereisten in 0.87

React Native 0.87 verhoogt de minimumversies over de hele build-keten:

Voor Android vereist AGP 9 extra configuratie:

# android/gradle.properties
android.builtInKotlin=false
android.newDsl=false

Deze vereisten gelden voor alle projecten die 0.87+ als doel hebben. De migratiegids voor de New Architecture behandelt de bredere context van deze wijzigingen.

Type-veilige navigatie met React Navigation 7

React Navigation 7.x biedt eersteklas TypeScript-ondersteuning. Het kernpatroon: definieer een type RootStackParamList dat elke schermnaam koppelt aan de verwachte params, en geef dat type vervolgens door aan navigators en schermcomponenten.

export type RootStackParamList = {
  Home: undefined;
  Profile: { userId: string };
  Settings: undefined;
  ArticleDetail: { articleId: string; source: 'feed' | 'search' };
};

export type AppTabParamList = {
  Dashboard: undefined;
  Explore: { category?: string };
  Notifications: undefined;
};

Schermcomponenten ontvangen dan getypeerde props zonder handmatige cast:

import type { NativeStackScreenProps } from '@react-navigation/native-stack';
import type { RootStackParamList } from '../navigation/types';

type Props = NativeStackScreenProps<RootStackParamList, 'ArticleDetail'>;

export function ArticleDetailScreen({ route, navigation }: Props) {
  // route.params.articleId is string — gegarandeerd door het type
  // route.params.source is 'feed' | 'search' — geen runtime-controle nodig
  const { articleId, source } = route.params;

  // navigation.navigate('Profile', { userId: '123' }) — typegecontroleerd
  // navigation.navigate('Profile', {}) — compilatiefout: userId ontbreekt
  return (
    <ArticleView id={articleId} referrer={source} />
  );
}

Dit elimineert een hele categorie runtime-fouten: navigeren naar een scherm met verkeerde of ontbrekende params faalt al tijdens de build.

Een type-veilige TurboModule bouwen met Codegen

TurboModules vervangen het oude Native Modules-systeem. Het TypeScript-specificatiebestand dient als enige bron van waarheid, want Codegen genereert daaruit de native interfaces. Lopen specificatie en native implementatie uiteen, dan faalt de build.

import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  getDeviceModel(): string;
  getBatteryLevel(): Promise<number>;
  getStorageInfo(): Promise<{
    totalBytes: number;
    freeBytes: number;
    usedPercentage: number;
  }>;
  onBatteryChange(callback: (level: number) => void): void;
}

export default TurboModuleRegistry.getEnforcing<Spec>('DeviceInfo');

Het uitvoeren van npx react-native codegen genereert de bijbehorende C++-, Objective-C++- en Java-interfaces. De native implementatie moet elke methodesignatuur exact naleven. Zo moet getStorageInfo een object met drie numerieke velden teruggeven; een afwijkende vorm veroorzaakt een compilatiefout aan de native kant.

class DeviceInfoModule(reactContext: ReactApplicationContext) :
    NativeDeviceInfoSpec(reactContext) {

    // Retourtype afgedwongen door gegenereerde NativeDeviceInfoSpec
    override fun getDeviceModel(): String {
        return Build.MODEL
    }

    override fun getBatteryLevel(): Promise<Double> {
        val bm = reactContext.getSystemService(Context.BATTERY_SERVICE)
            as BatteryManager
        val level = bm.getIntProperty(
            BatteryManager.BATTERY_PROPERTY_CAPACITY
        ).toDouble()
        return Promise.resolve(level)
    }
}

Deze aanpak elimineert het parsen van ReadableMap en NSDictionary dat in de oude architectuur stille bugs door type-coercie veroorzaakte. Raadpleeg voor een dieper inzicht in het native module-systeem de sollicitatievragen over native modules.

Generieke data-fetching met getypeerde API-hooks

Een herbruikbaar patroon voor getypeerde hooks voorkomt het dupliceren van fetch-logica over schermen heen, terwijl de volledige type-inferentie behouden blijft:

import { useQuery, UseQueryOptions } from '@tanstack/react-query';

interface ApiResponse<T> {
  data: T;
  meta: { page: number; totalPages: number };
}

export function useApiQuery<T>(
  key: readonly string[],
  endpoint: string,
  options?: Omit<UseQueryOptions<ApiResponse<T>>, 'queryKey' | 'queryFn'>
) {
  return useQuery<ApiResponse<T>>({
    queryKey: key,
    queryFn: async () => {
      const response = await fetch(`${API_BASE}${endpoint}`);
      if (!response.ok) throw new ApiError(response.status);
      return response.json() as Promise<ApiResponse<T>>;
    },
    ...options,
  });
}

// Gebruik — T wordt afgeleid als Article[]
interface Article {
  id: string;
  title: string;
  publishedAt: string;
}

const { data, isLoading } = useApiQuery<Article[]>(
  ['articles', 'latest'],
  '/articles?sort=latest'
);
// data.data is Article[] — volledig getypeerd
// data.meta.totalPages is number

De generieke parameter T stroomt door de hele keten: van de aanroepplek van de hook, via de query-functie, tot de component die het resultaat consumeert. Geen as-casts, geen any-types.

Discriminated unions voor state machines

Complexe schermtoestanden, laden, fout, leeg, geladen, modelleer je het best als discriminated unions in plaats van een verzameling optionele velden:

type ScreenState<T> =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'error'; error: string; retryCount: number }
  | { status: 'empty'; message: string }
  | { status: 'loaded'; data: T; refreshedAt: Date };

// components/DataScreen.tsx
function renderContent<T>(state: ScreenState<T>, renderItem: (data: T) => ReactNode) {
  switch (state.status) {
    case 'idle':
      return null;
    case 'loading':
      return <LoadingSpinner />;
    case 'error':
      // state.error is hier string — TypeScript versmalt automatisch
      return <ErrorBanner message={state.error} retries={state.retryCount} />;
    case 'empty':
      return <EmptyState message={state.message} />;
    case 'loaded':
      // state.data is T — volledig getypeerd
      return renderItem(state.data);
  }
}

Dit patroon maakt onmogelijke toestanden onrepresenteerbaar. Een loading-toestand kan niet per ongeluk verouderde data meedragen, en een error-toestand bevat altijd context om te debuggen.

Sollicitatievragen over React Native en TypeScript

Deze vragen weerspiegelen wat senior mobile-engineeringteams in sollicitatiegesprekken van 2026 stellen, nu de New Architecture en TypeScript de standaard zijn.

Hoe dwingt Codegen type-veiligheid af over de grens tussen JavaScript en native?

Codegen leest TypeScript- (of Flow-)specificatiebestanden en genereert daaruit interfacecode in C++, Objective-C++ en Java/Kotlin. De gegenereerde native interfaces dwingen exact de methodesignaturen, parametertypes en retourtypes af die in de specificatie zijn gedefinieerd. Wijkt de native implementatie af, door Int terug te geven waar de specificatie Double declareert, of een veld uit een struct weg te laten, dan weigert de native compiler de build. Dit verplaatst type-fouten van runtime-crashes naar fouten tijdens de build.

Wat is de Strict TypeScript API en waarom is die belangrijk?

De Strict TypeScript API genereert types direct uit de broncode van React Native in plaats van handgeschreven .d.ts-bestanden te onderhouden. In 0.87 werd het de verplichte standaard. Het beperkt imports tot het root-pakket react-native en deprecieert diepe imports. Daarmee definieert het een stabiel publiek API-oppervlak: interne refactors kunnen consumer-code niet breken zolang consumers alleen strikte types gebruiken. Een tijdelijke opt-out via customConditions blijft beschikbaar tot 0.88.

Hoe type je React Navigation-params over geneste navigators heen?

Definieer per navigator een ParamList-type en stel ze samen met NavigatorScreenParams. Voor een tab-navigator genest in een stack verwijst de param list van de stack naar die van de tab: type RootStack = { Main: NavigatorScreenParams<TabParamList>; Modal: { id: string } }. Elke navigate()-aanroep wordt dan typegecontroleerd door de volledige nestingshiërarchie, en vangt verkeerde schermnamen of ontbrekende params tijdens compilatie op.

Welk probleem lossen discriminated unions op in het state-management van React Native?

Discriminated unions modelleren elkaar uitsluitende toestanden (laden, fout, geladen) als afzonderlijke takken van een union-type, gekenmerkt door een status-veld. TypeScript versmalt het type in elke tak van een switch-statement, zodat toegang tot state.data alleen mogelijk is wanneer state.status === 'loaded'. Dit voorkomt onmogelijke toestanden zoals een laadindicator die naast foutdata wordt getoond, een categorie bugs die optionele velden en booleaanse flags niet kunnen voorkomen.

Leg het verschil uit tussen TurboModules en het oude Native Modules-systeem.

Native Modules communiceerden via de asynchrone bridge en serialiseerden alle data naar JSON. TurboModules gebruiken JSI (JavaScript Interface) voor synchrone, directe C++-aanroepen, zonder serialisatie-overhead. Ze laden bovendien lazy (bij het eerste gebruik in plaats van bij het opstarten van de app, wat de koudestarttijd verkort) en gebruiken Codegen om type-veilige interfaces te genereren uit TypeScript-specificaties. Het oude systeem leunde op het parsen van ReadableMap / NSDictionary met type-coercie tijdens runtime; TurboModules dwingen types af tijdens compilatie.

Welke API's zijn verwijderd in React Native 0.87?

0.87 verwijderde InteractionManager (gebruik requestIdleCallback), de types NativeMethods / NativeMethodsMixin (gebruik HostInstance) en verschillende StatusBar-props. Diepe imports naar src/private/-paden zijn nu type-fouten. De useTurboModules-flag is ook verwijderd omdat TurboModules nu altijd ingeschakeld zijn.

Voor meer sollicitatievragen over React Native behandelt de complete gids architectuur, performance en debugging-onderwerpen.

Bronnen

• React Native 0.87 Release Notes — Strict TypeScript API als standaard, toolchain-vereisten, API-verwijderingen
• React Native TypeScript-documentatie — Officiële TypeScript setup-gids
• React Navigation TypeScript-gids — Getypeerde navigatiepatronen
• TanStack Query-documentatie — Data fetching met type-inferentie

Onthouden over React Native TypeScript in 2026

• De Strict TypeScript API (verplicht in 0.87) beperkt imports tot het stabiele publieke oppervlak en voorkomt breuk door interne wijzigingen. De opt-out voor verouderde diepe imports is alleen beschikbaar tot 0.88
• Codegen genereert native interfaces uit TypeScript-specificatiebestanden en verplaatst type-fouten over de grens tussen JS en native van runtime-crashes naar fouten tijdens de build
• Toolchain-minimums in 0.87: Node.js 22.13+, Kotlin 2.0+, AGP 9, compileSdk 34+
• Getypeerde navigatie-params via RootStackParamList en NativeStackScreenProps vangen verkeerde schermnamen en ontbrekende params op voordat de app draait
• Discriminated unions modelleren schermtoestanden als elkaar uitsluitende takken en maken onmogelijke toestanden op typeniveau onrepresenteerbaar
• TurboModules met getypeerde specificaties vervangen het oude parsen van ReadableMap / NSDictionary en dwingen volledige type-veiligheid af van JavaScript via C++ tot platform-native code
• Generieke API-hooks met TanStack Query behouden de type-inferentie van endpoint tot component zonder handmatige casts