Что такое Mapped Types

Mapped Type решает простую задачу. У вас уже есть объектный тип, и вы хотите получить другой тип с теми же ключами или с преобразованными ключами. Вместо копирования полей вручную вы описываете правило для каждого ключа.

type User = {
  id: number;
  name: string;
  isAdmin: boolean;
};

type FieldFlags<T> = {
  [K in keyof T]: boolean;
};

type UserFlags = FieldFlags<User>;
// {
//   id: boolean;
//   name: boolean;
//   isAdmin: boolean;
// }

В ответе полезно назвать три части. keyof T получает union ключей. K по очереди представляет каждый ключ. T[K] достает тип значения по этому ключу. Так вы показываете механику, а не просто вспоминаете название Partial.

Хороший короткий ответ может звучать так:

Mapped Types это механизм TypeScript для создания новых объектных типов по ключам существующего типа. Например, можно пройтись по keyof T и сделать все поля optional, readonly или заменить тип каждого значения. Так работают многие Utility Types, например Partial и Readonly. Это проверка типов на этапе компиляции, а не преобразование объекта в runtime.

Если хотите усилить ответ, добавьте пример из frontend-задачи. Это может быть тип тела PATCH запроса, состояние формы, readonly DTO из API или генерация геттеров для модели. Так ответ звучит практично, а не как пересказ документации.

Базовый синтаксис можно читать как цикл по ключам типа. Но важно не называть его runtime-циклом. Это правило для компилятора TypeScript.

type MyPartial<T> = {
  [K in keyof T]?: T[K];
};

type MyReadonly<T> = {
  readonly [K in keyof T]: T[K];
};

У mapped types есть управление модификаторами. Плюс обычно можно не писать. Добавление модификатора используется по умолчанию. Минус нужен, когда вы хотите явно снять модификатор.

type MutableRequired<T> = {
  -readonly [K in keyof T]-?: T[K];
};

type ApiUser = {
  readonly id?: number;
  readonly name?: string;
};

type EditableUser = MutableRequired<ApiUser>;
// { id: number; name: string }

Практический вывод простой. Если вы типизируете форму редактирования, случайно оставленный readonly помешает обновлять поля. Случайно оставленный ? разрешит пропустить значение, которое UI уже должен требовать.

На интервью не нужно сразу писать сложный generic. Часто сильнее выглядит простой тип под задачу. Если задача стандартная, используйте встроенную утилиту. Если есть проектное правило, пишите свой mapped type.

Самый понятный frontend-пример связан с DTO и запросами. Представьте, что у вас есть профиль. В PATCH запрос можно отправлять только редактируемые поля.

type ProfileDto = {
  id: string;
  name: string;
  email: string;
  createdAt: string;
};

type ProfilePatch = Partial<Pick<ProfileDto, "name" | "email">>;

async function updateProfile(userId: string, patch: ProfilePatch) {
  if (Object.keys(patch).length === 0) {
    return;
  }

  await fetch(`/api/users/${userId}`, {
    method: "PATCH",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(patch),
  });
}

Здесь Pick ограничивает набор полей. Partial разрешает отправить только измененную часть. Проверка на пустой объект не относится к mapped types, но нужна для UX. Иначе кнопка сохранения может отправить лишний запрос без изменений. Если заменить тип на Partial<ProfileDto>, он разрешит случайно отправить id или createdAt. Это может привести к ошибке API, конфликту данных или тихому игнорированию лишних полей. Безопаснее держать отдельный ProfilePatch и не отправлять запрос, если изменений нет.

Mapped Types часто появляются рядом с React-формами. Здесь важно не превратить удобный тип для запроса в слабый тип для всего экрана.

type ProfileDto = {
  id: string;
  name: string;
  email: string;
  createdAt: string;
};

type ProfileForm = Pick<ProfileDto, "name" | "email">;
type ProfilePatch = Partial<ProfileForm>;

type ProfileViewState =
  | { status: "loading" }
  | { status: "error"; message: string }
  | { status: "ready"; data: ProfileDto; form: ProfileForm };

Такой подход помогает UI не гадать, почему поля нет. Если экран еще грузится, это status: "loading". Если запрос упал, это status: "error". Если данные готовы, поля формы обязательны. Так меньше риска показать пустое имя, отправить лишний ключ или спрятать ошибку за optional свойством.

Более сильный уровень ответа это key remapping через as. Он позволяет не только менять значения свойств, но и создавать новые имена ключей или исключать часть ключей.

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

type UserGetters = Getters<{
  name: string;
  age: number;
}>;
// {
//   getName: () => string;
//   getAge: () => number;
// }

type WithoutId<T> = {
  [K in keyof T as K extends "id" ? never : K]: T[K];
};

Фильтрация работает через never. Если ключ переименован в never, он исчезает из итогового типа. В примере с геттерами используется string & K, потому что keyof может включать не только строки, но и числа или символы.