React Native i TypeScript w 2026: Typobezpieczna Architektura i Pytania Rekrutacyjne

React Native z TypeScriptem stał się standardem branżowym w 2026 roku, szczególnie dla zespołów budujących skomplikowane aplikacje produkcyjne wymagające wysokiego poziomu bezpieczeństwa typów. Nowa architektura React Native, w połączeniu z TypeScript Strict API i Codegen dla TurboModules, umożliwia deweloperom tworzenie aplikacji mobilnych z gwarancjami bezpieczeństwa typów na poziomie kompilatora — od warstwy interfejsu użytkownika, przez nawigację i zarządzanie stanem, aż po natywne moduły platformowe. Architektura typobezpieczna redukuje liczbę błędów runtime, poprawia jakość sugestii IDE i ułatwia refaktoryzację baz kodu na dużą skalę. Znajomość wzorców zaawansowanego TypeScripta w kontekście React Native stała się kluczowym wymogiem podczas rozmów rekrutacyjnych na stanowiska senior mobile developer.

Dlaczego TypeScript jest standardem dla React Native

React Native oficjalnie przyjął TypeScript jako domyślny język w 2023 roku, a w 2026 większość bibliotek ekosystemu dostarcza pełną obsługę typów out-of-the-box. TypeScript zapewnia trzy kluczowe korzyści dla deweloperów mobilnych: wykrywanie błędów w czasie kompilacji (szczególnie ważne dla aplikacji działających na fizycznych urządzeniach, gdzie debugging jest kosztowny), inteligentne autouzupełnianie w IDE (zwiększające produktywność podczas pracy z komponentami natywnymi i API platformy) oraz bezpieczną refaktoryzację (krytyczną dla długoterminowej konserwacji projektów). Strict TypeScript API wprowadzone w React Native 0.76 dodało typy dla wszystkich natywnych modułów rdzenia, eliminując potrzebę korzystania z definicji any podczas pracy z Camera API, Geolokalizacją czy systemem uprawnień. Zespoły, które przyjęły TypeScript, raportują redukcję błędów produkcyjnych o 40-60%, szczególnie w obszarach integracji platform i komunikacji bridge.

Konfiguracja TypeScript Strict API dla React Native

Konfiguracja TypeScript Strict API dla React Native wymaga użycia specjalnej konfiguracji kompilatora, która aktywuje najsurowsze sprawdzanie typów dostępne w ekosystemie. Kluczowym elementem jest opcja exactOptionalPropertyTypes, która wymusza ścisłą różnicę między właściwościami niezdefiniowanymi a jawnie ustawionymi na undefined, oraz noUncheckedIndexedAccess, która dodaje automatyczne oznaczenie | undefined do każdego dostępu tablicowego i obiektowego. Te opcje wykrywają potencjalne błędy runtime związane z dostępem do nieistniejących właściwości, które są powszechne w aplikacjach mobilnych podczas parsowania odpowiedzi API lub obsługi danych użytkownika. Tryb moduleResolution: "bundler" zapewnia zgodność z Metro bundlerem używanym przez React Native, podczas gdy typy react-native/types/strict aktywują ścisłe definicje typów dla wszystkich natywnych modułów platformy.

{
  "compilerOptions": {
    "strict": true,
    "exactOptionalPropertyTypes": true,
    "noUncheckedIndexedAccess": true,
    "moduleResolution": "bundler",
    "jsx": "react-jsx",
    "types": ["react-native/types/strict"]
  },
  "extends": "@react-native/typescript-config/tsconfig.json"
}

Konfiguracja ta stanowi fundament dla typobezpiecznego developmentu w React Native. Dziedziczenie z @react-native/typescript-config zapewnia kompatybilność z oficjalnymi standardami frameworka, podczas gdy niestandardowe opcje kompilatora dodają dodatkową warstwę bezpieczeństwa. Wiele zespołów początkowo napotyka problemy z kompilacją po włączeniu strict API — najczęstsze błędy dotyczą dostępu do właściwości opcjonalnych bez sprawdzenia nullish, używania indeksowania obiektów bez guard clause oraz niespójności typów między parametrami nawigacji. Rozwiązanie tych błędów zazwyczaj wymaga refaktoryzacji istniejącego kodu, ale rezultatem jest znacznie bardziej stabilna baza kodu.

Typobezpieczna Nawigacja z React Navigation 7

React Navigation 7 wprowadził pełną integrację TypeScript z systemem routingu, umożliwiając deweloperom definiowanie map parametrów dla każdego ekranu i otrzymywanie automatycznego sprawdzania typów podczas nawigacji. System ten eliminuje cały klasę błędów runtime związanych z przekazywaniem nieprawidłowych parametrów do ekranów, brakującymi parametrami wymaganymi przez komponent docelowy czy błędnymi nazwami tras. Definicja typu RootStackParamList działa jako pojedyncze źródło prawdy dla całej struktury nawigacyjnej aplikacji — zmiany w tej definicji automatycznie propagują się do wszystkich miejsc, gdzie używane są metody nawigacyjne, zapewniając spójność w całej bazie kodu. TypeScript wymusza, aby każde wywołanie navigation.navigate dostarczyło poprawne parametry zgodne z definicją typu dla ekranu docelowego.

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;
};

Typowanie komponentów ekranowych wykorzystuje helper type NativeStackScreenProps, który automatycznie wywnioskuje typy dla route.params i wszystkich metod nawigacyjnych na podstawie pozycji ekranu w mapie parametrów. Eliminuje to potrzebę ręcznego rzutowania typów lub sprawdzania runtime podczas dostępu do parametrów trasy. TypeScript gwarantuje, że dostęp do route.params.articleId zwraca string, a route.params.source jest ograniczony do literalnych typów 'feed' | 'search', co umożliwia używanie discriminated unions w logice biznesowej bez dodatkowych guard clause. Wywołania nawigacyjne są sprawdzane podczas kompilacji — próba nawigacji do Profile bez parametru userId lub z nieprawidłowym typem parametru powoduje błąd kompilatora przed uruchomieniem aplikacji.

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 — guaranteed by the type
  // route.params.source is 'feed' | 'search' — no runtime check needed
  const { articleId, source } = route.params;

  // navigation.navigate('Profile', { userId: '123' }) — type-checked
  // navigation.navigate('Profile', {}) — compile error: missing userId
  return (
    <ArticleView id={articleId} referrer={source} />
  );
}

Budowanie Typobezpiecznych TurboModules z Codegen

TurboModules w React Native wykorzystują Codegen do automatycznego generowania kodu bridge między JavaScriptem a natywnymi platformami na podstawie specyfikacji TypeScript. System ten zapewnia gwarancje bezpieczeństwa typów end-to-end — typy zdefiniowane w specyfikacji TypeScript są automatycznie egzekwowane w kodzie natywnym Kotlin/Swift, eliminując całą klasę błędów związanych z niezgodnością typów między warstwami. Interface Spec działa jako kontrakt między JavaScriptem a kodem natywnym, definiując sygnatury metod, typy parametrów i wartości zwracane. Codegen analizuje tę specyfikację podczas build time i generuje boilerplate kod dla obu platform, zapewniając, że implementacja natywna musi respektować typy zdefiniowane w specyfikacji — próba zwrócenia nieprawidłowego typu z metody natywnej powoduje błąd kompilacji na poziomie Kotlin/Swift.

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');

Implementacja natywna dziedziczy po wygenerowanej klasie bazowej NativeDeviceInfoSpec, która egzekwuje sygnatury metod zdefiniowane w specyfikacji TypeScript. Kotlin compiler weryfikuje, że metoda getDeviceModel zwraca String, getBatteryLevel zwraca Promise<Double>, a struktura zwracana przez getStorageInfo zawiera wszystkie wymagane pola z poprawnymi typami. System ten działa dwukierunkowo — jeśli deweloper zmieni typ zwracany w specyfikacji TypeScript, kod natywny przestanie się kompilować, dopóki implementacja nie zostanie zaktualizowana, zapewniając synchronizację kontraktu między warstwami. Takie podejście jest szczególnie cenne podczas refaktoryzacji lub dodawania nowych funkcjonalności do modułów, gdzie ryzyko wprowadzenia niezgodności typów między platformami jest wysokie.

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

    // Return type enforced by generated 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)
    }
}

Generyczne Pobieranie Danych z Typowanymi Hookami API

Generyczne hooki do pobierania danych łączą moc TypeScript generics z bibliotekami zarządzania stanem jak TanStack Query, zapewniając pełne bezpieczeństwo typów dla operacji sieciowych bez duplikacji kodu. Hook useApiQuery przyjmuje parametr typu T, który reprezentuje strukturę danych oczekiwaną z endpointu — TypeScript automatycznie wywnioskuje ten typ na podstawie interfejsu przekazanego podczas wywołania hooka, propagując go przez cały pipeline zapytania. Rezultatem jest w pełni typowany obiekt data, gdzie data.data jest typu T, a data.meta zawiera pola metadanych z gwarantowanymi typami. Ten wzorzec eliminuje potrzebę ręcznego rzutowania typów po każdym zapytaniu API i zapewnia, że zmiany w strukturze odpowiedzi API są natychmiast wykrywane przez TypeScript w miejscach użycia.

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,
  });
}

// Usage — T is inferred as Article[]
interface Article {
  id: string;
  title: string;
  publishedAt: string;
}

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

Typ Omit<UseQueryOptions<ApiResponse<T>>, 'queryKey' | 'queryFn'> w parametrze options umożliwia przekazywanie dowolnych opcji konfiguracyjnych TanStack Query (jak staleTime, refetchInterval, enabled) przy jednoczesnym zablokowaniu nadpisywania queryKey i queryFn, które są zarządzane wewnętrznie przez hook. TypeScript gwarantuje, że opcje przekazane podczas wywołania hooka są kompatybilne z typem generycznym T — na przykład, przekazanie select: (data) => data.invalid spowoduje błąd kompilacji, ponieważ invalid nie istnieje w typie ApiResponse<T>. Wzorzec ten jest szczególnie wartościowy w dużych aplikacjach z dziesiątkami endpointów API, gdzie ręczne typowanie każdego zapytania byłoby kosztowne i podatne na błędy.

Discriminated Unions dla Maszyn Stanów

Discriminated unions w TypeScript są idealnym narzędziem do modelowania stanów ekranu w aplikacjach React Native, gdzie komponent może znajdować się w jednym z kilku wzajemnie wykluczających się stanów: idle, loading, error, empty lub loaded. Użycie pola status jako discriminatora umożliwia TypeScriptowi automatyczne zawężanie typów w blokach switch — gdy state.status === 'error', TypeScript wie, że state.error i state.retryCount są dostępne i poprawnie typowane, podczas gdy w przypadku state.status === 'loaded' dostępne jest pole state.data typu generycznego T. Ten wzorzec eliminuje całą klasę błędów związanych z dostępem do właściwości, które nie istnieją w danym stanie — próba dostępu do state.data w stanie 'loading' powoduje błąd kompilacji.

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 string here — TypeScript narrows automatically
      return <ErrorBanner message={state.error} retries={state.retryCount} />;
    case 'empty':
      return <EmptyState message={state.message} />;
    case 'loaded':
      // state.data is T — fully typed
      return renderItem(state.data);
  }
}

Discriminated unions są szczególnie wartościowe podczas zarządzania złożonymi przepływami danych, gdzie stan ekranu zależy od wielu czynników — połączenia sieciowego, uprawnień użytkownika, dostępności lokalnej pamięci cache. Zamiast zarządzać wieloma booleanami (isLoading, hasError, isEmpty, hasData), które mogą prowadzić do niespójnych stanów (np. isLoading=true i hasData=true jednocześnie), discriminated union zapewnia, że stan jest zawsze reprezentowany przez dokładnie jeden z możliwych wariantów. TypeScript wymusza obsługę wszystkich przypadków w wyrażeniu switch — brakująca obsługa któregokolwiek wariantu powoduje błąd kompilacji, co gwarantuje, że interfejs użytkownika poprawnie reaguje na każdy możliwy stan aplikacji.

Pytania Rekrutacyjne: React Native i TypeScript

1. Jak działa Codegen w TurboModules i jakie gwarancje typów zapewnia między JavaScriptem a kodem natywnym?

Codegen analizuje specyfikacje TypeScript (Spec interface) podczas build time i generuje kod bridge dla iOS (Objective-C++) i Android (Kotlin/Java), który egzekwuje typy zdefiniowane w specyfikacji. Gdy deweloper definiuje metodę getBatteryLevel(): Promise<number> w interfejsie Spec, Codegen generuje klasę bazową dla implementacji natywnej, która wymusza zwracanie wartości typu Promise<Double> w Kotlinie lub NSNumber* w Swift. Gwarancje typów działają dwukierunkowo — zmiany w specyfikacji TypeScript powodują błędy kompilacji w kodzie natywnym, jeśli implementacja nie jest zgodna, a zmiany w kodzie natywnym są ograniczone przez kontrakty typów generowane przez Codegen. System eliminuje cały klasę błędów runtime związanych z przekazywaniem danych między warstwami, takich jak wysyłanie stringa zamiast liczby lub brakujących pól w obiektach zwracanych. Codegen również obsługuje złożone typy (obiekty, tablice, unie) i automatycznie serializuje/deserializuje je podczas przekazywania przez bridge.

2. Czym różni się konfiguracja TypeScript Strict API od standardowej konfiguracji React Native i dlaczego noUncheckedIndexedAccess jest krytyczna?

Strict API włącza najsurowsze sprawdzanie typów dostępne w TypeScript, szczególnie exactOptionalPropertyTypes i noUncheckedIndexedAccess, które nie są domyślnie aktywne w standardowej konfiguracji React Native. Opcja noUncheckedIndexedAccess dodaje automatyczne | undefined do każdego dostępu tablicowego (array[0]) i indeksowania obiektów (obj[key]), wymuszając sprawdzanie nullish przed użyciem wartości. Jest to krytyczne w aplikacjach mobilnych, gdzie dostęp do nieistniejących elementów tablicy lub kluczy obiektów jest powszechny podczas parsowania danych API, obsługi parametrów nawigacji czy pracy z AsyncStorage. Bez tej opcji TypeScript zakłada, że dostęp do users[index] zawsze zwraca User, nawet jeśli index jest poza zakresem tablicy, co prowadzi do błędów runtime. Strict API również aktywuje typy react-native/types/strict, które zapewniają ścisłe definicje dla wszystkich natywnych modułów rdzenia, eliminując potrzebę używania any podczas pracy z Platform API.

3. Jak React Navigation 7 zapewnia bezpieczeństwo typów dla parametrów ekranów i jakie są najczęstsze błędy podczas typowania nawigacji?

React Navigation 7 wykorzystuje TypeScript mapped types i conditional types do automatycznego wywnioskowania typów parametrów na podstawie RootStackParamList. Gdy deweloper definiuje Profile: { userId: string } w param list, wszystkie wywołania navigation.navigate('Profile', params) są sprawdzane podczas kompilacji, aby zapewnić, że params zawiera userId typu string. Helper type NativeStackScreenProps<RootStackParamList, 'Profile'> automatycznie typuje route.params i metody nawigacyjne dla komponentu ekranu. Najczęstsze błędy obejmują: używanie useNavigation() bez typowania (co prowadzi do typów any), definiowanie opcjonalnych parametrów jako { userId?: string } zamiast { userId: string } | undefined (co zmienia semantykę podczas strict checking), oraz mieszanie różnych typów navigatorów (Stack, Tab, Drawer) bez prawidłowej kompozycji typów param list. Kolejnym błędem jest ręczne rzutowanie route.params, co obchodzi system typów i może prowadzić do runtime errors.

4. Jak działa zawężanie typów (type narrowing) w discriminated unions i dlaczego jest to lepsze niż używanie wielu flag booleanowskich dla stanów ekranu?

Type narrowing w discriminated unions wykorzystuje pole discriminatora (np. status) do automatycznego zawężania typu w blokach warunkowych. Gdy TypeScript widzi if (state.status === 'loaded'), zawęża typ state do wariantu { status: 'loaded'; data: T; refreshedAt: Date }, sprawiając, że pola data i refreshedAt są dostępne i poprawnie typowane wewnątrz bloku. To działa automatycznie w wyrażeniach switch, if-else i operator ternary. W przeciwieństwie do flag booleanowskich (isLoading, hasError, hasData), które mogą prowadzić do niespójnych stanów (np. isLoading=true i hasError=true jednocześnie), discriminated union zapewnia, że stan jest zawsze reprezentowany przez dokładnie jeden wariant. TypeScript wymusza wyczerpujące sprawdzanie wszystkich wariantów w switch — brakująca obsługa któregokolwiek przypadku powoduje błąd kompilacji. Dodatkowo, discriminated unions są łatwiejsze do rozszerzania (dodanie nowego wariantu automatycznie powoduje błędy kompilacji we wszystkich miejscach, które wymagają obsługi) i eliminują potrzebę synchronizacji wielu flag podczas zmiany stanu.

5. Jakie są zalety używania generycznych hooków do pobierania danych (useApiQuery<T>) w porównaniu do dedykowanych hooków dla każdego endpointu?

Generyczne hooki eliminują duplikację kodu i zapewniają spójne bezpieczeństwo typów dla wszystkich operacji API bez potrzeby pisania dedykowanego hooka dla każdego endpointu. Parametr typu T jest automatycznie wywnioskowany na podstawie interfejsu przekazanego podczas wywołania, propagując typ przez cały pipeline zapytania — TypeScript gwarantuje, że data.data jest typu T, a wszystkie transformacje danych (przez select, transform) są typowane zgodnie. Generyczny hook umożliwia również współdzielenie logiki biznesowej (error handling, retry logic, caching) między wszystkimi endpointami przy jednoczesnym zachowaniu pełnego typowania specyficznego dla każdego endpointu. W porównaniu do dedykowanych hooków, które wymagają powielania boilerplate code dla każdego API call, generyczny hook centralizuje logikę i redukuje powierzchnię błędów. Typ Omit<UseQueryOptions<ApiResponse<T>>, 'queryKey' | 'queryFn'> zapewnia, że opcje konfiguracyjne są dostępne dla wywołującego, ale kluczowe parametry (query key, fetch function) pozostają pod kontrolą hooka, zapobiegając niespójnościom w cache management.

6. Czym różnią się TurboModules od starych Native Modules i jakie korzyści z TypeScript przynosi nowa architektura?

TurboModules ładują się leniwie (on-demand) w przeciwieństwie do starych Native Modules, które były inicjowane podczas startu aplikacji, znacznie redukując czas uruchamiania. Kluczową różnicą z perspektywy TypeScripta jest system Codegen — TurboModules wymagają specyfikacji TypeScript, która jest używana do automatycznego generowania kodu bridge, podczas gdy stare Native Modules polegały na ręcznym pisaniu bridge code bez gwarancji typów między warstwami. Nowa architektura umożliwia synchroniczne wywołania metod natywnych (gdzie ma to sens), eliminując callback hell dla operacji takich jak odczyt wartości z Secure Storage. TypeScript w TurboModules zapewnia end-to-end type safety — typy zdefiniowane w JavaScript są automatycznie egzekwowane w implementacji Kotlin/Swift, a zmiany w specyfikacji powodują błędy kompilacji na obu platformach, jeśli implementacja nie jest zgodna. Dodatkowo, TurboModules wspierają typy złożone (obiekty, tablice, unie, generyki) out-of-the-box, podczas gdy stare Native Modules wymagały ręcznej serializacji i deserializacji.

Podsumowanie: Typobezpieczna Architektura React Native w 2026

Typobezpieczna architektura w React Native połączyła moc TypeScript strict checking z natywną wydajnością platform mobilnych, tworząc ekosystem, który minimalizuje błędy runtime i maksymalizuje produktywność deweloperów. Kluczowe wnioski:

• TypeScript Strict API z opcjami exactOptionalPropertyTypes i noUncheckedIndexedAccess zapewnia najsurowsze sprawdzanie typów dostępne w ekosystemie, eliminując całą klasę błędów związanych z dostępem do nieistniejących właściwości i indeksów tablicowych.
• React Navigation 7 oferuje pełne bezpieczeństwo typów dla parametrów ekranów, automatycznie wywnioskując typy na podstawie param list i wymuszając poprawność wywołań nawigacyjnych podczas kompilacji.
• TurboModules z Codegen zapewniają gwarancje typów end-to-end między JavaScriptem a kodem natywnym, generując bridge code, który egzekwuje kontrakty typów na poziomie Kotlin/Swift.
• Generyczne hooki do pobierania danych eliminują duplikację kodu przy jednoczesnym zachowaniu pełnego typowania dla każdego endpointu API, centralizując logikę zarządzania stanem i error handlingu.
• Discriminated unions są idealnym narzędziem do modelowania stanów ekranu, wykorzystując automatic type narrowing TypeScripta do zapewnienia, że interfejs użytkownika poprawnie reaguje na każdy możliwy stan aplikacji.
• Znajomość zaawansowanych wzorców TypeScript w kontekście React Native — od specyfikacji TurboModules, przez typowanie nawigacji, po generyczne hooki i maszyny stanów — stała się kluczowym wymogiem podczas rozmów rekrutacyjnych na stanowiska senior mobile developer w 2026 roku.

Adopcja tych wzorców wymaga inwestycji w learning curve i refaktoryzację istniejących projektów, ale długoterminowe korzyści — redukcja błędów produkcyjnych, lepsza jakość sugestii IDE, bezpieczniejsza refaktoryzacja i zwiększona produktywność zespołu — sprawiają, że TypeScript strict architecture stała się standardem branżowym dla profesjonalnych aplikacji React Native.