Шаблонные литеральные типы: вычисление, разворачивание и разбор строковых типов

Интерполяция и декартово произведение объединений

Зачем генерировать строковые типы вместо того, чтобы просто перечислить их? Потому что набор допустимых строк часто растёт вместе с моделью данных — локаль вида "en-US" должна выводиться из типов Lang и Region, которые вы уже поддерживаете: добавьте "fr" в Lang — и "fr-US", "fr-GB" появятся автоматически без правки типа локали.

Шаблонный литеральный тип выглядит как строка-шаблон JS, но оперирует типами. Интерполяция одного литерала предсказуема; интерполяция объединения разворачивается в каждую комбинацию — полное декартово произведение:

type Greeting = `Hello, ${string}!`;     // любая строка "Hello, ...!"
type Hi = Greeting & "Hello, Sam!";      // ^? "Hello, Sam!"  (это член)

type Lang = "en" | "ru";
type Region = "US" | "GB";
type Locale = `${Lang}-${Region}`;
// ^? "en-US" | "en-GB" | "ru-US" | "ru-GB"   — 2 x 2 = 4 члена

Каждый слот интерполяции умножает число членов. Два двухчленных объединения дают 4; добавьте третье трёхчленное — и получите 12; рост мультипликативный. Это главный подвох: шаблон над несколькими большими объединениями может породить тысячи членов и замедлить или застопорить проверщик.

Встроенные манипуляторы регистра

Четыре встроенных (реализованных компилятором) строковых типа меняют регистр, и определения для них на уровне библиотеки вы написать не смогли бы:

type U = Uppercase<"hello">;     // ^? "HELLO"
type L = Lowercase<"HELLO">;     // ^? "hello"
type C = Capitalize<"hello">;    // ^? "Hello"
type N = Uncapitalize<"Hello">;  // ^? "hello"

Это кусочки за переименованием ключей (get${Capitalize<K>} из прошлого урока) и за типизированными построителями имён событий.

Разбор через infer внутри шаблонного образца

Настоящая мощь: поместите infer внутрь шаблонного литерала в части extends условия, чтобы вытащить подстроки. Чтобы извлечь параметр маршрута:

type RouteParam<S extends string> =
  S extends `${string}:${infer Param}/${string}`
    ? Param
    : S extends `${string}:${infer Param}`
      ? Param
      : never;

type P1 = RouteParam<"/users/:id">;        // ^? "id"
type P2 = RouteParam<"/users/:id/posts">;  // ^? "id"

Для нескольких параметров вы рекурсируете, собирая каждый в объединение — строительный блок для полностью типизированных роутеров. Разбиение строки с разделителями — та же идея:

type Split<S extends string, D extends string> =
  S extends `${infer Head}${D}${infer Tail}`
    ? [Head, ...Split<Tail, D>]
    : [S];

type Parts = Split<"a-b-c", "-">;
// ^? ["a", "b", "c"]

Вывод нежадный на первом разделителе

Когда образец имеет ${infer Head}<разделитель>${infer Tail}, Head сопоставляется как можно меньше — до первого вхождения разделителя, не до последнего:

type FirstSeg<S extends string> =
  S extends `${infer Head}-${infer Tail}` ? [Head, Tail] : [S];

type R = FirstSeg<"a-b-c">;
// ^? ["a", "b-c"]   — Head останавливается на ПЕРВОМ '-', Tail берёт остальное

Поэтому Split выше отслаивает по одному сегменту за рекурсию слева. Если бы вы предположили, что Head жадно проглотит "a-b", разрешённый тип вас удивил бы — правило нежадности с самым левым разделителем и делает рекурсивный разбор слева направо работающим.

Цена: парсер в системе типов — это парсер, который вы не можете отладить

Шаблонные литералы — это точка, где TypeScript перестаёт быть type-checker’ом и становится языком обработки строк, и именно здесь нужна наибольшая дисциплина. Стоимость декартова произведения реальна и крута: один шаблон, интерполирующий четыре сегмента, каждый по алфавиту, — это 26⁴ ≈ 457 000 членов, далеко за потолком в 100 000 членов, так что tsc либо выдаёт Expression produces a union type that is too complex to represent, либо, при добавлении рекурсии, исчерпывает кучу и падает с OOM (дефолт Node 2–4 ГБ). Даже не доходя до потолка, рекурсивный Split/парсер над длинной строкой — это нехвостовая рекурсия, упирающаяся в стену глубины инстанцирования (50 уровней) и откатывающаяся к string, молча отбрасывая точность, ради которой вы писали тип.

Senior-критерий: разобранный шаблонный тип даёт сквозную строковую безопасность — :id в роуте проверяется против req.params обработчика без стоимости в рантайме и без дублирования объявления. Это многого стоит на границе библиотеки, где формат строки — это API (роутер, типизированный i18n-ключ, SQL-подобный DSL). Внутри прикладного кода это редко оправдано: 40-строчный рекурсивный шаблонный парсер нечитаем для следующего инженера, порождает сообщения об ошибках, указывающие на машинерию типов, а не на ошибку человека, и облагает налогом каждое нажатие в редакторе. Когда вы ловите себя на разборе нетривиальной грамматики на уровне типов, это сигнал перенести её в шаг сборки/кодогенерации — сгенерируйте карту роутов, объединение i18n-ключей или типы запросов как плоские именованные типы из источника истины. Сгенерированный type Routes = "/users/:id" | ... грепается, чисто наводится и компилируется мгновенно; рекурсивный шаблон, его выводящий, — парсер, через который не пройдёт ни один отладчик. Тянитесь к шаблонам, когда сама строка — это контракт; тянитесь к кодогенерации, когда строку нужно разбирать.