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

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 (архив)