Типобезопасные паттерны

Все паттерны этой темы — вариации одного хода: взять проверку, которая иначе всплыла бы багом в рантайме (переименованное событие, ответ API без одного поля, чужой id в репозитории), и переложить её на компилятор. Механизм у них общий. Объявляется один тип-реестр, сопоставляющий строковый ключ его значению — interface Registry { "user.created": UserCreatedPayload; "order.paid": OrderPaidPayload }, — а всё остальное выводится из него: keyof Registry даёт объединение допустимых ключей, Registry[K] — значение конкретного ключа, а обобщённая сигнатура <K extends keyof Registry>(key: K, value: Registry[K]) превращает несовпадающую пару в ошибку компиляции. Один источник истины, ноль дублирования между «списком имён» и «списком форм», которые в наивном коде живут порознь и расходятся.

Ловушка, общая для всей темы, — граница с внешним миром. Типы в TypeScript стираются: до рантайма не доживает ни реестр, ни keyof, ни один параметр типа. Поэтому обёртка над fetch, чей тип результата «выводится по эндпоинту», на деле лишь переименовывает any, который вернул res.json(); протокол WebSocket, размеченный по полю type, — это утверждение о том, что придёт по проводу, а не его проверка; дополнение NodeJS.ProcessEnv до string — прямая ложь, если переменная не выставлена. Компилятор проверяет согласованность внутри кода — что emit и его обработчик не разъедутся, — но не может проверить данные, которых он не видел. Честная версия каждого паттерна валидирует ровно на входе (см. Валидацию в рантайме) либо отдаёт unknown и заставляет вызывающего сузить тип самому. Сами по себе эти решения — прикладное применение mapped-, условных и template-literal-типов из Продвинутых типов; здесь важно не как они устроены, а куда их прикладывают.

Карта темы

• Реестры типов «ключ → payload» — один interface, сопоставляющий строковый ключ его payload, и вывод всего остального через keyof и Registry[K].
• Обёртка над fetch с выводом по эндпоинту — почему res.json() возвращает any и чем типизированная обёртка отличается от честной валидации на границе.
• Типизация request/response — реестр эндпоинтов, вывод тела и params из строки маршрута и почему типизированный req.body в Express — лишь утверждение.
• Типизированный event emitter — обобщение по реестру событий, сигнатуры on/emit и variadic-кортеж для событий без payload.
• Типизация протокола — вывод размеченного объединения сообщений из реестра, switch с проверкой на never и корреляция запрос/ответ.
• Типизация middleware — накопление контекста в типе через обёртку против глобального дополнения Request, навсегда делающего req.user необязательным.
• Обобщённые репозитории — Omit/Partial/Pick как защита от чужого id и вывод типа проекции select по выбранным ключам.
• Плагинные системы — два механизма расширения (declaration merging против обобщённой композиции) и их компромисс.
• Типизация process.env — почему любое чтение даёт string | undefined и почему разбор схемой на старте честнее, чем дополнение ProcessEnv.

Частые ошибки и ловушки

Значение для собеседований

Тему спрашивают, чтобы отделить кандидата, который на «типизируй мне это» тянется к перегрузкам, дублированию и any, от того, кто видит за девятью задачами один приём: один реестр плюс индексный доступ по обобщённому ключу. Первый на каждое новое событие дописывает пару перегрузок вручную; второй объявляет interface, а keyof и E[K] делают остальное. Второй, более тонкий срез — понимание границы: сильный кандидат сам скажет, что «тип результата выводится по эндпоинту» и «протокол размечен по type» — это утверждения о данных, а стирание типов означает, что проверить их может только валидатор в рантайме, а не аннотация.

Что обычно проверяют:

• Что keyof Registry — это объединение имён, а Registry[K] — значение ключа, и как один обобщённый K связывает пару.
• Почему res.json() — это Promise<any> и чем api<T> отличается от schema.parse(await res.json()).
• Где на самом деле проверять req.body, чтобы объявленный тип перестал быть ложью.
• Как из одного реестра вывести и объединение сообщений, и карту обработчиков, и зачем ветка never.
• Почему глобальное дополнение Request ослабляет гарантию даже при необязательном user, и что даёт накопление контекста в типе.
• Как Omit/Partial/Pick не дают задать серверный id и как проекция select сужает тип результата.
• Разницу между расширением через declaration merging и обобщённой композицией плагинов.
• Почему process.env.FOO — это string | undefined и почему разбор схемой на старте честнее дополнения ProcessEnv.

Типичный неверный ответ: «Обёртка api<User>(url) делает ответ типобезопасным». Отсюда весь разговор и разворачивается: параметр типа T не порождает никакой проверки — as T внутри обёртки стирается, а res.json() как был any, так и остаётся, только теперь под именем User. Обёртка не перенесла ни одной проверки в компилятор, она лишь переклеила ярлык. Второй классический провал — «типизированный req.body защищает от плохого запроса»: в рантайме Express не сверяет тело ни с чем, объявленный тип — это обещание, а не валидация, и единственное место, где обещание становится проверкой, — явный вызов схемы на входе.