Ремаппинг ключей через as: переименование и фильтрация ключей в отображённом типе

Переименование ключей через as и шаблонные литералы

Когда нужно, чтобы все ключи типа следовали соглашению об именовании — добавить префикс get, суффикс Changed, привести к верхнему регистру — можно написать каждый вручную. Или указать отображённому типу вычислять ключ, а не переиспользовать его.

С TS 4.1 отображённый тип может добавить as <выражение> после части in. Для каждого K свойство выдаётся под ключом, в который разрешается <выражение>, а не под самим K. В сочетании с шаблонными литеральными типами и встроенным Capitalize это переименовывает ключи механически:

type Getters<T> = {
  [K in keyof T as `get${Capitalize<string & K>}`]: () => T[K];
};

type State = { name: string; age: number };
type G = Getters<State>;
// ^? { getName: () => string; getAge: () => number }

Capitalize<"name"> — это "Name" (встроенный тип манипуляции строкой — урок про шаблонные литералы в юните 05 разбирает их полностью), поэтому шаблон `get${...}` даёт "getName". Пересечение string & K несущее: keyof T может включать ключи number и symbol, но Capitalize принимает только string, поэтому string & K сужает каждый ключ до его строковой части перед интерполяцией.

Фильтрация ключей: ремаппинг в never, чтобы удалить их

Вот приём, который делает ремаппинг мощным. Если вычисленный ключ — never, это свойство полностью опускается. Соедините это с условием на тип значения — и получите фильтрацию по значению, без списка ключей для Pick/Omit:

// Убрать каждое свойство, чьё значение — функция
type DataOnly<T> = {
  [K in keyof T as T[K] extends (...a: any[]) => any ? never : K]: T[K];
};

type Model = { id: number; name: string; save(): void; load(): void };
type D = DataOnly<Model>;
// ^? { id: number; name: string }   — save и load ремаппнуты в never, удалены

Условие выполняется по ключам: ключи со значениями-функциями ремаппятся в never (и исчезают), остальные ремаппятся в самих себя (K) и выживают. Обратное — оставить только ключи, чьё значение совпадает — просто меняет ветки:

// Оставить только ключи, чьё значение — строка (Pick-по-типу-значения)
type StringKeysOnly<T> = {
  [K in keyof T as T[K] extends string ? K : never]: T[K];
};

type R = StringKeysOnly<{ a: string; b: number; c: string }>;
// ^? { a: string; c: string }

Два ограничения: допустимые типы ключей и потерянная гомоморфность

Вычисленный ключ должен быть совместим с PropertyKey — то есть string | number | symbol. Ремаппьте в что-то иное (объект, булево) — и TypeScript выдаст ошибку. Поэтому переименования идут через шаблонные литералы (которые дают строковые ключи), а фильтры — через never (пустой ключ).

Ремаппинг также ломает гомоморфность (прошлый урок): как только вы добавляете as, отображённый тип перестаёт быть голой формой { [K in keyof T]: ... }, поэтому связь с источником разрывается — модификаторы вроде readonly/? больше не копируются автоматически, а массивы/кортежи не сохраняются как контейнеры. Если нужны и переименование, и сохранение модификаторов, вы заново применяете модификаторы явно.

Цена: карта с переименованием ключей — это долг по сопровождению

Переименование ключей — самый магический из трюков с отображаемыми типами, а у магии есть цена. Первая цена — незаметная поломка: поскольку as рвёт гомоморфизм, Getters<T> молча сбрасывает модификаторы readonly и ?, которые нёс источник. Коллега, позже пометивший поле readonly в типе состояния, видит, как это ограничение исчезает из сгенерированных сеттеров — реальный баг без ошибки. Вторая цена — навигируемость: getName не существует нигде в источнике, поэтому Find-References, grep и ментальная модель нового читателя его не находят. Сгенерированный ключ не отлаживается текстовым поиском.

Senior-критерий: переименование уместно, когда правило переименования действительно единообразно, а исходный набор открыт — вывод интерфейса обработчиков событий из типа пропсов, где добавление пропса должно автоматически добавлять обработчик. Это неверный инструмент в момент, когда преобразование ключа кодирует бизнес-смысл, который читатель должен видеть, или когда у источника лишь горстка фиксированных полей. Для фильтрации по значению конкретно — взвесьте против рантайм-проверки: если цель — действовать над полями-данными в рантайме, обычный Object.entries(...).filter(...) читаем и тестируем, тогда как DataOnly<T> лишь сдвигает различение на этап компиляции и в рантайме не даёт ничего. А когда внешнему потребителю (SDK, публичному API) нужны эти переименованные формы, шаг кодогенерации, выписывающий interface StoreActions { setName(v: string): void } как настоящий исходник, лучше переименованного типа, который потребитель не может ни сгрепать, ни чисто навести, ни расширить — сгенерированный .d.ts — это артефакт; башня as — загадка.