Перейти к основному содержимому

TypeScript

Быстрый переход к обучению

  1. TypeScript — учебный модуль
  2. Все учебные модули

Что нужно знать

  1. Базовые типы и сужение типов: unknown, any, never, user-defined type guards.
  2. Контракты: type vs interface, расширение, композиция, declaration merging.
  3. Generics: ограничения extends, вывод типов, reusable API и безопасные абстракции.
  4. Discriminated unions: моделирование состояний UI и API без набора optional полей.
  5. Utility types: Pick, Omit, Partial, Readonly, Record и контроль эволюции контрактов.

Что уметь объяснить на собеседовании

  1. Почему unknown безопаснее any в командном коде.
  2. Когда использовать type, а когда interface.
  3. Как generic помогает избегать дублирования и скрытых ошибок.
  4. Почему union-модели устойчивее набора optional-полей.
  5. Как сохранить backward compatibility при изменении API-типов.

Грейд-фокус

  1. Junior: базовые типы, функции, интерфейсы, типизация простых объектов и массивов.
  2. Middle: generics, unions, utility types, типизация API-слоя и state-моделей.
  3. Senior: границы строгости, стратегия типизации монорепы, миграции legacy-кода с any.

Глубокие кейсы собеседования

  1. UI-state как union: вместо { loading?: boolean; data?: T; error?: string } используем { status: 'idle' | 'loading' | 'success' | 'error'; ... }. Это исключает невозможные состояния и снижает количество багов в рендеринге.

  2. API-клиент и ложная уверенность: если endpoint типизирован как any, ошибки структуры данных всплывают только в проде. Сильный ответ: fetchJson<T>(), runtime-validation на критичных границах, error mapping.

  3. Exhaustive-check: в switch по union новый статус может тихо не обработаться. Нужен never-assert для гарантии полноты.

Практический минимум

  1. Типизировать API-клиент с generic-оберткой fetchJson<T>().
  2. Смоделировать асинхронный экран через discriminated union.
  3. Добавить never-проверку в switch для exhaustiveness.
  4. Переписать any-heavy модуль в строгую типизацию.
  5. Зафиксировать, где строгая типизация реально снизила риск багов.

Типовые ловушки

  1. Быстрый переход на any при первой сложности.
  2. Чрезмерно сложные типы, которые не читаются командой.
  3. Utility types без ясного контекста применения.
  4. Путаница compile-time safety и runtime-validation.

Self-review перед собеседованием

  1. Я могу объяснить разницу any и unknown на реальном баге.
  2. Я умею показать, когда interface удобнее type, и наоборот.
  3. Я могу за 2 минуты набросать union-модель для async-экрана.
  4. Я понимаю, где типизация должна быть строгой, а где прагматичной.

Связанные материалы

  1. React
  2. JavaScript
  3. Middle JavaScript и React
  4. Senior Frontend

Архивный монолит

Полный старый материал: TypeScript (архив)