Паттерны типизации в TypeScript напрямую влияют на технический долг — накопление неоптимального кода (костылей), которое замедляет разработку, увеличивает риски ошибок и повышает затраты на поддержку. Осознанный выбор паттерна минимизирует эти проблемы, обеспечивая предсказуемость и масштабируемость кода, что ускоряет адаптацию новых разработчиков и сокращает время на отладку. Ниже приведены исходные типы для дальнейшей демонстрации.

// Определение возможных типов сегментов как литерального массива для строгой типизации
const segmentTypes = [
  'line',
  'quadratic',
] as const;
type SegmentType = typeof segmentTypes[number]; // Union-тип: 'line' | 'quadratic'

// Условный тип для координат, зависящий от типа сегмента (discriminated по T)
type SegmentCoords<T extends SegmentType> =
  T extends 'line' ? [x: number, y: number] :  // Для 'line' — две координаты
  T extends 'quadratic' ? [controlX: number, controlY: number, x: number, y: number] :  // Для 'quadratic' — четыре координаты

Эти определения служат базой для четырех вариантов типизации PathSegment, которые я разберу ниже.

Обзор вариантов

Вариант 1: Mapped Types с Indexed Access

Этот подход использует mapped types для создания объекта, где ключи — типы сегментов, а значения — структуры с соответствующим type и coords. Indexed access формирует discriminated union. Подход опирается на декларативный маппинг TypeScript, где типы генерируются автоматически из базового union, обеспечивая строгую связь между type и coords без дублирования.

// Mapped type: для каждого T в SegmentType создает объект { type: T; coords: SegmentCoords<T> }
type PathSegment1 = {
  [T in SegmentType]: {  // Итерация по union SegmentType
    type: T;  // Discriminant: строка-литерал для сужения типа
    coords: SegmentCoords<T>;  O// Координаты, зависящие от T
  };
}[SegmentType];  // Indexed access: union всех значений mapped type

Типобезопасность достигается через полное сужение типа: TypeScript автоматически проверяет coords на основе type, предотвращая ошибки, например, передачу четырех координат для 'line'. Читаемость страдает из-за вложенного синтаксиса mapped types, который требует понимания продвинутых возможностей TypeScript, но это окупается в крупных проектах, где автоматическая генерация типов упрощает масштабирование при добавлении новых значений в исходный union. Производительность компиляции может замедляться при большом числе типов из-за рекурсивного маппинга, но runtime не затрагивается.

С точки зрения менеджмента, паттерн снижает техдолг в долгосрочных проектах, минимизируя ошибки в типах, но в командах с джунами может вызвать лишнюю возню, приводя к фрустрации и временным решениям, например, использованию any для быстрого исправления.

Вариант 2: Record Utility Type

Здесь используется утилита Record для создания объекта-типа с ключами из SegmentType со значениями в виде общих структур, но с coords, зависящими от SegmentType (union). Union извлекается через keyof. Это похоже на mapped types из первого варианта, но Record упрощает декларативную типизацию, но жертвует строгостью, так как не обеспечивает точного соответствия между конкретными ключами и их значениями, допуская объединение типов без строгого сужения.

// Record: объект с ключами SegmentType и значениями {type: SegmentType; coords: SegmentCoords<SegmentType>}
type PathSegmentRecord = Record<SegmentType, {  // Ключи — 'line' | 'quadratic'
  type: SegmentType;  // Union для type, без строгого сужения внутри Record
  coords: SegmentCoords<SegmentType>;  // Union coords, менее строгий
}>;
type PathSegment2 = PathSegmentRecord[keyof PathSegmentRecord];  // Union значений Record

Типобезопасность ниже, чем в mapped types, из-за union в coords внутри Record, что снижает строгость сужения типа без дополнительного кода. Читаемость улучшается за счет знакомой утилиты Record, но требует двух шагов (Record + keyof), что усложняет восприятие. Масштабирование эффективно, так как изменения в segmentTypes автоматически отражаются, но рост union в coords увеличивает риски. Компиляция быстрая для малого числа типов, runtime без накладных расходов.

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

Вариант 3: Generic Type with Default

Подход использует generics с параметром по умолчанию, где PathSegment — параметризованный тип. Default T=SegmentType создает union. Акцент на гибкости generics, где сужение типа происходит естественно через conditional types в SegmentCoords, без явного union.

// Generic: T constrained SegmentType, default — union
type PathSegment5<T extends SegmentType = SegmentType> = {  // Parameterized, default union
  type: T;  // Discriminant с generic T
  coords: SegmentCoords<T>;  // Зависимые coords
};

Типобезопасность высока благодаря generics, обеспечивающим сужение типа, но требует явного указания T. Читаемость хороша из-за простоты generics, знакомых многим разработчикам. Добавление типов в segmentTypes расширяет default union, что позволяет масштабировать эффективно. Компиляция быстрая, runtime без потерь.

Менеджменту это выгодно для быстрого онбординга разработчиков, снижая техдолг. Джуны меньше фрустрированы, так как generics — базовая концепция.

Вариант 4: Interface Inheritance

Метод использует базовый interface с type, затем extends для переопределением type и coords. Union объединяет все варианты. Упор на ООП-подобное наследование в TypeScript, где явные интерфейсы обеспечивают четкое сужение типа через discriminant.

// Base: общий type
interface BaseSegment {
  type: SegmentType;  // Union discriminant
}
// Line: extends с override type и specific coords
interface LineSegment extends BaseSegment {
  type: 'line';  // Литерал для сужения типа
  coords: [x: number, y: number];  // Две координаты
}
// Quadratic: аналогично
interface QuadraticSegment extends BaseSegment {
  type: 'quadratic';  // Литерал
  coords: [controlX: number, controlY: number, x: number, y: number];  // Четыре
}
type PathSegment4 = LineSegment | QuadraticSegment;  // Явный union

Типобезопасность максимальна благодаря явному сужению типа. Читаемость высока из-за знакомого синтаксиса интерфейсов. Масштабирование требует добавления новых интерфейсов, что предсказуемо, но трудоемко. Компиляция эффективна, runtime идеален.

Для менеджмента это минимизирует техдолг, так как джуны комфортно работают с интерфейсами из-за того, что это еще более базовая база, чем generics, но при росте команды добавление новых интерфейсов может привести к дублированию, конфликтам при слиянии.

Техническая таблица

Сравнительный анализ

Типобезопасность: Варианты 4 (Interface Inheritance) и 1 (Mapped Types with Indexed Access) лучшие благодаря строгому сужению типа. Вариант 4 использует явные интерфейсы с конкретными литералами, исключая ошибки соответствия type и coords. Вариант 1 достигает того же через mapped types, автоматически связывая type с SegmentCoords.

Читаемость: Вариант 4 (Interface Inheritance) лучший благодаря ООП-подобному синтаксису интерфейсов, понятному даже самым далеким леймам.

Масштабирование: Варианты 1 (Mapped Types with Indexed Access), 2 (Record Utility Type) и 3 (Generic Discriminated Union) автоматически адаптируются к изменениям в segmentTypes благодаря декларативной природе (mapped types, Record, default union). Вариант 4 требует накаченных рук и рутины.

Рекомендации по применению

Для проектов преимущественно с junior-разработчиками вариант 4 (Interface Inheritance) подходит лучше всего — он минимизирует фрустрацию и техдолг. В командах с опытными разработчиками вариант 1 (Mapped Types с Indexed Access) предпочтителен из-за автоматического масштабирования, для фетишистов подойдет и вариант 3 (Generic Type with Default). Вариант 2 это подлива в белые трусы, как и любые фокусы с Utility Types.

Я использую исключительно вариант 1 (Mapped Types with Indexed Access), потому что это реальный автобот. Я никуда не спешу, поэтому и скорость компиляции меня не волнует. Если кто-то в команде не понимает как это работает, то я включу ему бесконечную версию "Давай! давай давай давай давай давай❤️ ты сможешь?верь в себя?зайка?верь?давай давай!! поднажми)) ☝?еще чуть-чуть...прошу тебя?не здавайся?поднажми?ты все сможешь!! ?".