Что такое Pick в TypeScript

Pick это встроенный utility type в TypeScript. Он берет исходный тип и список ключей. Затем строит новый тип только с этими ключами.

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

type UserPreview = Pick<User, "id" | "name">;

const preview: UserPreview = {
  id: "u1",
  name: "Alex",
};

На интервью можно сказать так. Pick<Type, Keys> выбирает свойства из Type. Keys должен быть ключом или union ключей этого типа. Если написать ключ с ошибкой, TypeScript остановит это на проверке типов.

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

Pick это утилитарный тип TypeScript для создания нового типа из части полей существующего типа. Например, если у меня есть User, но компоненту нужны только id и name, я могу написать Pick<User, "id" | "name">. Так я не дублирую типы полей и сохраняю связь с исходной моделью.

После этого добавьте практический нюанс. Pick не фильтрует реальные данные. Если в объекте есть password, token или внутренняя роль, тип Pick сам по себе не удалит их перед отправкой в API, лог или аналитику.

Выбор зависит не от вкуса, а от границы в коде. Если вы делаете пропсы для маленькой карточки пользователя, Pick часто уместен. Если описываете публичный контракт API, payload формы, событие аналитики или данные для localStorage, отдельный тип и явный маппер могут быть безопаснее.

Сильный ответ показывает этот trade-off. Pick уменьшает дублирование, но усиливает связность. Иногда это плюс, иногда риск.

Типичный frontend-сценарий такой. Есть большой тип пользователя, но карточке в списке нужны только несколько полей.

type User = {
  id: string;
  name: string;
  avatarUrl?: string;
  email: string;
  role: "user" | "admin";
};

type UserCardProps = Pick<User, "id" | "name" | "avatarUrl">;

function UserCard({ id, name, avatarUrl }: UserCardProps) {
  return (
    <article>
      {avatarUrl ? <img src={avatarUrl} alt={`Avatar of ${name}`} /> : null}
      <h3>{name}</h3>
      <a href={`/users/${id}`}>Open profile</a>
    </article>
  );
}

Практический плюс такой. Если тип avatarUrl в User изменится, пропсы карточки обновятся вместе с ним. Практический риск тоже есть. Компонент становится связан с User. Если карточка должна показывать не только пользователей, но и авторов из другого API, лучше описать отдельный тип пропсов. Еще один frontend-нюанс. Pick не проверяет, что URL картинки безопасен или что текст подходит для доступности. Это решают в коде компонента и при валидации данных.

Первое ограничение. Pick работает только с типами. Ниже плохой пример, если вы думаете, что так очищаете данные:

type PublicUser = Pick<User, "id" | "name">;

const publicUser = user as PublicUser;
sendAnalytics(publicUser);

Это плохой пример, потому что as PublicUser не удаляет лишние поля из объекта. Если user содержал email, token, password или role, они могут остаться в runtime-объекте и попасть в аналитику или сетевой payload. Безопаснее собрать новый объект явно.

const publicUser: PublicUser = {
  id: user.id,
  name: user.name,
};

Второе ограничение. Pick не делает глубокий выбор.

type User = {
  id: string;
  profile: {
    city: string;
    phone: string;
  };
};

type UserProfile = Pick<User, "profile">;
type UserCity = Pick<User["profile"], "city">;

UserProfile содержит весь объект profile, включая phone. Если потом передать такой объект в дочерний компонент, лог или запрос, лишнее поле останется в данных. Если вам нужен только city, применяйте Pick к User["profile"] и собирайте объект с нужными полями явно.

На интервью не нужно перечислять все utility types. Лучше показать, что вы понимаете назначение Pick, границы его работы и практические последствия.

Сильный ответ состоит из трех частей. Что делает Pick, где вы применяли бы его во frontend-коде, и чего он не делает. Например, он помогает типизировать пропсы, формы и DTO. Но он не фильтрует реальные данные перед сетью, логами или аналитикой и не выбирает вложенные поля сам.