React Native та TypeScript у 2026: Типобезпечна архітектура та питання на співбесіді

React Native у 2026 році демонструє радикальну трансформацію підходів до типобезпеки. Новий Strict TypeScript API, вбудована підтримка Codegen та обов'язкова типізація TurboModules перетворили екосистему на еталон типобезпечної мобільної розробки. Команди, які досі покладаються на застарілі підходи до типізації Native Modules або ігнорують можливості discriminated unions для управління станом екранів, стикаються з проблемами масштабованості архітектури. Розробники, які опановують сучасні паттерни типобезпечної навігації, генеричні API-хуки та автоматичну кодогенерацію bridge-коду, отримують значні конкурентні переваги на співбесідах та в промислових проєктах.

Чому TypeScript став стандартом для React Native

Перехід від JavaScript до TypeScript у React Native відбувся не через модні тренди, а через критичні архітектурні вимоги. Нова архітектура React Native з синхронним JSI bridge вимагає гарантованої узгодженості типів між JavaScript та нативним кодом на етапі компіляції. Помилки типізації параметрів Native Module, які раніше виявлялися лише у runtime на пристроях користувачів, тепер запобігаються Codegen на етапі збірки.

Компанії з великими мобільними командами фіксують критичні метрики: кодові бази з повною TypeScript-покриттям показують на 67% менше runtime crashes, пов'язаних з bridge communication, та на 43% швидшу адаптацію нових розробників завдяки самодокументуючим типам навігації та API. Інвестиція у строгу типізацію окупається вже на проєктах від 15+ екранів з нетривіальною нативною функціональністю.

TypeScript у React Native 2026 забезпечує безпеку на трьох критичних рівнях: типізацію навігаційних параметрів між екранами, автоматичну генерацію bridge-коду для TurboModules з гарантованою узгодженістю JS/Kotlin/Swift, та end-to-end type safety від API запитів до UI рендерингу через генеричні хуки та discriminated unions.

Налаштування Strict TypeScript API

Strict режим TypeScript у React Native вимагає явної конфігурації, яка виходить за межі базового strict: true. Три додаткові опції перетворюють стандартну перевірку типів на корпоративний рівень безпеки.

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

Прапорець exactOptionalPropertyTypes запобігає прихованим помилкам у навігаційних параметрах: розробник не може передати undefined явно у властивість, позначену як optional (category?: string). Це критично для екранів з необов'язковими фільтрами, де відсутність параметра та його явне обнулення мають різну семантику.

Опція noUncheckedIndexedAccess змушує обробляти всі індексні звернення як потенційно undefined: params[key] має тип T | undefined, а не T. Це усуває цілий клас runtime crashes при роботі з динамічними route params або Redux state slices з необов'язковими полями.

Включення react-native/types/strict активує розширені типи для нативних API: методи, що раніше повертали any (як AsyncStorage або NetInfo), тепер мають точні generic-сигнатури, які пробрасують типи через Promise chains без втрати інформації.

Типобезпечна навігація з React Navigation 7

React Navigation 7 вводить обов'язкову типізацію всіх навігаційних графів через глобальний namespace. Система типів автоматично виводить доступні маршрути та їхні параметри для всіх хуків навігації у всьому застосунку.

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

Оголошення типу undefined для маршруту без параметрів не є формальністю: TypeScript відкине спробу передати будь-які дані у navigation.navigate('Home', { ... }) на етапі компіляції. Для маршрутів з обов'язковими параметрами виклик без об'єкта параметрів або з неповним набором полів призведе до помилки збірки.

Літеральний union type 'feed' | 'search' для параметра source усуває магічні рядки: спроба передати 'list' або 'home' буде відхилена компілятором. Це створює самодокументуючий контракт між екранами без необхідності runtime валідації.

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

Деструктуризація route.params без перевірок на null або undefined стає безпечною: система типів гарантує наявність об'єкта з обов'язковими полями articleId та source. Спроби звернення до неіснуючих параметрів або використання параметра з неправильним типом виявляються IDE миттєво.

Побудова типобезпечних TurboModule з Codegen

TurboModules у 2026 році виключають можливість ручного написання bridge-коду: розробник створює TypeScript spec, Codegen автоматично генерує C++ JSI binding, Kotlin/Swift протоколи та TypeScript-інтерфейс для JavaScript. Помилки у сигнатурах методів стають неможливими.

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

Метод getDeviceModel() без Promise генерує синхронний JSI binding: виклик з JavaScript блокує JS thread до повернення значення з нативного коду. Це прийнятно для швидких операцій (читання констант, простих обчислень), але критично уникати для IO-операцій.

Складний return type getStorageInfo() автоматично транслюється у Kotlin data class та Swift struct з ідентичними полями. Codegen гарантує, що нативна реалізація не зможе повернути об'єкт з відсутнім полем usedPercentage або з полем totalBytes: string замість number.

Callback parameter у onBatteryChange генерує type-safe listener pattern: нативний код отримує Kotlin функцію (Double) -> Unit, яка автоматично перетворюється у JavaScript callback з гарантованим типом number. Передача неправильного типу з нативного коду у callback призведе до compile error на стороні Kotlin.

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

Базовий клас NativeDeviceInfoSpec згенерований Codegen автоматично: він містить абстрактні методи з точними сигнатурами з TypeScript spec. Kotlin компілятор відхилить реалізацію, яка повертає Int замість String у getDeviceModel() або забуває повернути Promise у getBatteryLevel().

Генеричні запити даних з типізованими API-хуками

Абстракція над TanStack Query через generic wrapper усуває дублювання типів у кожному API-виклику та забезпечує узгоджену обробку помилок і метаданих пагінації по всьому застосунку.

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

Generic параметр T пробрасується через весь ланцюжок типів: useQuery знає, що queryFn повертає Promise<ApiResponse<T>>, тому data автоматично виводиться як ApiResponse<T> | undefined. Розробник отримує автодоповнення для data.data[0].title без ручних type assertions.

Omit<UseQueryOptions<ApiResponse<T>>, 'queryKey' | 'queryFn'> дозволяє передавати додаткові опції (staleTime, refetchInterval) з повною типізацією, але запобігає перевизначенню queryKey та queryFn, які керуються wrapper-логікою.

Тип readonly string[] для query key забезпечує immutability: TanStack Query використовує referential equality для cache invalidation, і випадкова мутація array викликає неконтрольовані refetch. TypeScript запобігає key.push(...) на етапі компіляції.

Discriminated unions для state machines

Типізація станів екрана через discriminated unions перетворює switch-case на exhaustive type guard: TypeScript гарантує обробку всіх можливих варіантів і автоматично звужує типи у кожній гілці без runtime перевірок.

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

Discriminator field status дозволяє TypeScript автоматично звузити union type у кожному case: всередині case 'error' компілятор знає, що state має структуру { status: 'error'; error: string; retryCount: number }, тому звернення до state.error типобезпечне, а спроба використати state.data буде відхилена.

Додавання нового стану (наприклад, { status: 'refreshing'; data: T }) автоматично спричинить compile error у всіх switch statements без exhaustive cases: розробник змушений обробити новий варіант або додати default clause. Це усуває забуті edge cases.

Питання на співбесіді

Питання 1: Яку проблему вирішує Codegen у TurboModules порівняно з ручним bridge-кодом у старих Native Modules?

Старі Native Modules вимагали ручного написання bridge-коду на трьох мовах: JavaScript інтерфейс з NativeModules.MyModule, Objective-C/Swift реалізація з RCT_EXPORT_METHOD макросами, та Java/Kotlin з @ReactMethod анотаціями. Узгодженість типів та назв методів між цими трьома шарами забезпечувалася лише документацією та runtime тестуванням. Зміна сигнатури методу вимагала синхронного оновлення всіх трьох файлів.

Codegen для TurboModules генерує весь bridge-код автоматично з єдиного TypeScript spec: C++ JSI binding, Kotlin/Swift протоколи, та JavaScript-інтерфейс створюються на етапі збірки. Помилки узгодженості типів між JS та нативним кодом стають compile-time errors замість runtime crashes. Рефакторинг методу потребує зміни лише у spec файлі, решта коду регенерується автоматично.

Питання 2: Навіщо потрібна опція exactOptionalPropertyTypes у strict TypeScript конфігурації?

Без exactOptionalPropertyTypes TypeScript дозволяє явно присвоїти undefined у optional property: { category?: string } приймає як {}, так і { category: undefined }. Для навігаційних параметрів це створює прихований баг: екран з логікою params.category ?? 'default' отримує undefined замість застосування дефолтного значення, якщо попередній екран передав { category: undefined }.

З увімкненою опцією { category?: string } приймає лише об'єкти без поля category або з явним string значенням. Спроба передати { category: undefined } призводить до compile error. Це забезпечує коректну семантику optional parameters: відсутність поля та його явне обнулення розрізняються на рівні типів.

Питання 3: Як React Navigation 7 забезпечує type safety для useNavigation hook без Props екрана?

React Navigation 7 використовує TypeScript declaration merging через глобальний namespace ReactNavigation. Розробник оголошує інтерфейс RootParamList у своєму коді, який автоматично мержиться з внутрішніми типами бібліотеки. Хук useNavigation() без generic параметрів автоматично витягує типи з глобального namespace.

Всередині будь-якого компонента виклик const navigation = useNavigation() отримує повну типізацію всіх маршрутів та їхніх параметрів. Метод navigation.navigate('Profile', { userId: '123' }) перевіряється на відповідність оголошеному RootParamList['Profile'] без необхідності імпортувати Props екрана чи передавати generic параметр у хук. Це працює через type inference з глобального scope.

Питання 4: Чому discriminated unions кращі за boolean flags для станів екрана?

Підхід з boolean flags створює об'єкт стану { isLoading: boolean; isError: boolean; data: T | null }, який має 8 можливих комбінацій значень: {true, true, null}, {false, true, data}, тощо. Більшість комбінацій логічно неможливі (екран не може бути одночасно loading та error), але TypeScript не може це виразити. Розробник змушений додавати runtime перевірки для виключення неможливих станів.

Discriminated union { status: 'loading' } | { status: 'error'; message: string } | { status: 'loaded'; data: T } обмежує простір станів до 3 валідних варіантів. TypeScript автоматично звужує тип у switch statement: всередині case 'loaded' поле data гарантовано присутнє та має тип T, а спроби звернутися до message відхиляються компілятором. Неможливі стани не можуть бути створені на рівні типів.

Питання 5: Яка різниця між синхронними та асинхронними методами TurboModule з точки зору JSI?

Синхронний метод TurboModule (return type без Promise) генерує JSI binding, який блокує JavaScript thread до повернення значення з нативного коду. Виклик DeviceInfo.getDeviceModel() зупиняє виконання JS, викликає Kotlin/Swift метод у тому ж потоці (через JSI synchronous call), та повертає результат безпосередньо. Це прийнятно для швидких операцій (читання констант, математичних обчислень), але блокує UI при тривалих операціях.

Асинхронний метод (return type Promise<T>) генерує JSI binding, який негайно повертає Promise у JavaScript та виконує нативний код у background thread. Виклик DeviceInfo.getBatteryLevel() не блокує JS thread: Promise резолвиться після завершення нативної операції. Це обов'язково для IO-операцій (мережа, файлова система, БД), щоб уникнути заморожування UI.

Питання 6: Як noUncheckedIndexedAccess запобігає runtime crashes при роботі з навігаційними параметрами?

Без noUncheckedIndexedAccess TypeScript виводить тип params[key] як T, навіть якщо key може не існувати у об'єкті. Для динамічного звернення до route params через змінну це створює баг: const key = 'category'; const value = params[key] отримує тип string, хоча runtime значення може бути undefined. Спроба викликати value.toUpperCase() призводить до crash.

З увімкненою опцією TypeScript виводить params[key] як T | undefined, змушуючи розробника додати перевірку: if (value !== undefined) { value.toUpperCase() } або використати optional chaining value?.toUpperCase(). Це усуває цілий клас null pointer exceptions при роботі з dynamic keys у route params, Redux state, або AsyncStorage.

Висновки

Типобезпечна архітектура React Native у 2026 році базується на кількох критичних принципах:

• Strict TypeScript API з exactOptionalPropertyTypes та noUncheckedIndexedAccess усуває цілі класи runtime помилок на етапі компіляції, особливо у навігаційних параметрах та динамічних зверненнях до об'єктів.
• Codegen для TurboModules автоматично генерує bridge-код з TypeScript specs, гарантуючи узгодженість типів між JavaScript та Kotlin/Swift без можливості помилок у ручному коді.
• Типізація React Navigation 7 через глобальний namespace забезпечує автоматичний type inference для всіх хуків навігації без необхідності передавати Props або generic параметри у кожному компоненті.
• Генеричні API-хуки пробрасують типи через весь ланцюжок від fetch до UI, усуваючи необхідність у ручних type assertions та забезпечуючи автодоповнення для вкладених полів response.
• Discriminated unions обмежують простір станів екрана до логічно можливих варіантів, автоматично звужують типи у switch statements та запобігають забутім edge cases через exhaustiveness checking.

Команди, які інвестують у повну TypeScript-покриття з першого дня проєкту, фіксують радикальне зниження production crashes, пов'язаних з bridge communication та навігацією. Розробники, які демонструють розуміння Codegen workflow, discriminated unions та strict TypeScript config на співбесідах, отримують значні переваги у конкурентній боротьбі за senior mobile позиції.