Что такое дженерики

Дженерик можно воспринимать как переменную для типа. Обычная переменная хранит значение, а generic-параметр хранит тип, который TypeScript подставит при использовании.

Самый простой пример показывает не саму функцию, а связь между входом и выходом:

function identity<T>(value: T): T {
  return value;
}

const name = identity("Ada"); // string
const count = identity(3); // number

Здесь функция одна, но TypeScript не теряет конкретный тип. Если бы вместо T был any, редактор хуже подсказывал бы свойства, а ошибки могли бы пройти до runtime.

Можно ответить так:

Дженерики это способ параметризовать код типом. Я могу написать универсальную функцию или интерфейс, а конкретный тип передать или вывести при использовании. Это помогает не дублировать код и не уходить в any, потому что TypeScript сохраняет связь между аргументами, результатом и полями объекта.

После этого добавьте пример из своей практики. Для frontend-разработчика удобно говорить про API-ответ, хук, форму, таблицу или список. Так ваш ответ звучит не как определение из учебника, а как рабочее понимание инструмента.

Частый пример - общая оболочка ответа API. Структура ответа одинаковая, но поле data бывает разным.

type ApiResponse<T> = {
  data: T;
  status: "success" | "error";
  message?: string;
};

type User = {
  id: string;
  name: string;
};

async function fetchJson<T>(url: string): Promise<ApiResponse<T>> {
  const response = await fetch(url);

  if (!response.ok) {
    throw new Error("Request failed");
  }

  return response.json() as Promise<ApiResponse<T>>;
}

const result = await fetchJson<User>("/api/me");
result.data.name;

Польза в том, что ApiResponse не нужно копировать для каждого ресурса. Но есть важная граница: fetchJson<User> не проверяет, что сервер реально вернул User. Приведение типа после response.json() только сообщает TypeScript, чему вы доверяете. Оно не защищает UI от пустого ответа, HTML вместо JSON или поля другого формата. В реальном компоненте также обработайте loading, error и empty state. Если ответ приходит из внешнего API или влияет на деньги, права доступа или важный UI, добавьте runtime-валидацию.

Generic без ограничений может быть чем угодно. Поэтому TypeScript не даст обратиться к свойству, которое не гарантировано.

Плохой пример:

function getId<T>(item: T) {
  return item.id;
}

Такой код не пройдет строгую проверку TypeScript. Если обойти ошибку через as any, в runtime можно получить undefined, неверный ключ в списке React или запрос на URL с пустым id. Правильнее описать минимальный контракт:

function getId<T extends { id: string }>(item: T): string {
  return item.id;
}

getId({ id: "u1", name: "Ada" });

Теперь функция все еще универсальная. Она принимает любой объект с дополнительными полями, но требует id. Это хорошая формулировка для интервью: generic не означает "любой без правил", он может быть ограничен контрактом.

На интервью не стоит говорить, что дженерики нужны везде. Они нужны там, где тип должен подставляться и сохраняться. Если у вас фиксированный список значений, union обычно проще. Если разные сигнатуры ведут себя по-разному, иногда честнее описать перегрузки.

Пример, где union лучше generic:

type LoadStatus = "idle" | "loading" | "success" | "error";

Здесь нет смысла делать абстрактный параметр типа. Вам нужна не универсальность, а строгий список допустимых состояний. Это снижает риск опечаток, лишних состояний и неправильной обработки UI.

В сильном ответе держите три шага. Сначала дайте определение: параметр типа для универсального кода. Потом покажите пользу: сохраняется связь между типами без any. Затем назовите границу: для свойств нужен extends, а для данных из runtime нужна отдельная проверка.

Если вы пишете код на React и TypeScript, дженерики часто встречаются в хуках, компонентах списков, формах, таблицах и типах API. Но хороший frontend-код не обязан быть максимально абстрактным. Он должен быть понятным для команды и достаточно строгим, чтобы ловить ошибки до запуска приложения.