Magento 2 Experten — Hyvä Theme, Tailwind CSS & SEO aus einer Hand ›

TypeScript zum Expo-Projekt hinzufügen

TypeScript zum Expo-Projekt hinzufügen

~13 Min. Lesezeit Zuletzt aktualisiert am 8. August 2026

Ab hier migrieren wir produktkatalog-app schrittweise zu TypeScript – GENAU wie in "React für Profis" Kapitel 40-43 behandeln die nächsten vier Kapitel AUSSCHLIESSLICH die React-Native-INTEGRATION von TypeScript (Props/Hooks/Navigation/API typisieren), nicht die TypeScript-Sprache selbst – die ist Thema des separaten, eigenständigen TypeScript-Tutorials.

Expo hat TypeScript-Unterstützung bereits eingebaut

Anders als beim reinen Vite-Setup aus "React für Profis" Kapitel 40 (wo tsconfig.json von Hand angelegt werden musste) erkennt Expo TypeScript-Dateien AUTOMATISCH, sobald sie im Projekt auftauchen – der einzige nötige Schritt ist, die passenden Pakete zu installieren:

npx expo install typescript @types/react

tsconfig.json generieren lassen

Benennen Sie App.js in App.tsx um (noch OHNE Typen hinzuzufügen – reines Umbenennen reicht als erster Schritt) und starten Sie die App neu (npx expo start). Expo erkennt die fehlende tsconfig.json automatisch und legt eine BASIS-Version an:

tsconfig.json
{
  "extends": "expo/tsconfig.base",
  "compilerOptions": {
    "strict": true
  }
}

"extends": "expo/tsconfig.base" übernimmt Expos eigene, sorgfältig auf React Native abgestimmte Basis-Konfiguration (JSX-Modus, Modul-Auflösung, React-Native-spezifische Typen) – deutlich weniger manuelle Konfiguration als beim reinen Vite-Setup. "strict": true fügen wir selbst hinzu – wie in "React für Profis" Kapitel 40 erklärt, ist das für ein neues Projekt IMMER empfehlenswert.

TypeScript-Fehler prüfen: der eigenständige Check

Anders als bei Vite (wo noEmit: true genügte, weil esbuild die Typprüfung ignoriert) hat Metro (Expos Bundler) KEINE eingebaute Typprüfung – ein TypeScript-Fehler verhindert NICHT automatisch das Starten der App. Prüfen Sie manuell mit:

npx tsc --noEmit

Achtung: Das ist ein wichtiger Unterschied zu "React für Profis": dort meldete der Vite-Entwicklungsserver TypeScript-Fehler oft direkt im Browser-Overlay. Bei Expo bleibt npx tsc --noEmit der zuverlässigste Weg, den GESAMTEN Typ-Zustand des Projekts zu prüfen – idealerweise als eigener Schritt in einer CI-Pipeline (siehe Kapitel 16, Testing) oder als Editor-Integration (VS Code zeigt TypeScript-Fehler ohnehin live im Editor an, unabhängig vom laufenden Bundler).

Die erste Datei migrieren: store/cartStore.js

Analog zu "React für Profis" Kapitel 40 beginnen wir mit einer Datei OHNE JSX – store/cartStore.js wird zu cartStore.ts:

store/cartStore.ts
import { create } from 'zustand';
import { persist, createJSONStorage } from 'zustand/middleware';
import AsyncStorage from '@react-native-async-storage/async-storage';

export interface CartItem {
  sku: string;
  name: string;
  price: number;
}

interface CartState {
  cart: CartItem[];
  addProduct: (product: CartItem) => void;
  removeProduct: (sku: string) => void;
}

export const useCartStore = create<CartState>()(
  persist(
    (set, get) => ({
      cart: [],

      addProduct(product) {
        set({ cart: [...get().cart, product] });
      },

      removeProduct(sku) {
        set({ cart: get().cart.filter((item) => item.sku !== sku) });
      },
    }),
    {
      name: 'cart-storage',
      storage: createJSONStorage(() => AsyncStorage),
    }
  )
);

Achtung: Beachten Sie create<CartState>()(persist(...)) – die ZUSÄTZLICHEN, leeren Klammern () direkt nach <CartState> sind KEIN Tippfehler. Zustands TypeScript-API nutzt dieses "curried"-Aufrufmuster (zwei aufeinanderfolgende Funktionsaufrufe statt einem), damit TypeScript den generischen Typ korrekt durch die persist-Middleware hindurch ableiten kann – ohne die zweiten Klammern würde TypeScript den State-Typ nicht zuverlässig erkennen. Diese Eigenheit tauchte in "React für Profis" Kapitel 42 nicht auf, da dort kein persist verwendet wurde.

Das Muster ist ansonsten identisch zu "React für Profis" Kapitel 40/42: export interface CartItem als wiederverwendbarer Typ, den wir in den nächsten Kapiteln in mehreren Dateien importieren werden.

Tipp: Migrationsreihenfolge wie in "React für Profis" empfohlen: kleine, isolierte Dateien (Stores, Utility-Funktionen) zuerst, komplexe Screens mit vielen Abhängigkeiten (wie ProductListScreen) zuletzt – der Rest der App bleibt während der schrittweisen Migration lauffähig, .js- und .tsx-Dateien koexistieren problemlos.