TS TypeScript · 30 вопросов · ~85 мин · ⏱ Таймер 25:00 · Сложный ·

Брендированные типы и доменные идентификаторы

Профессиональный тест по теме «Брендированные типы и доменные идентификаторы»: сложные фрагменты кода, архитектурные компромиссы, диагностика и надёжность. Вопросы требуют читать код, сопоставлять статические гарантии с поведением JavaScript и выбирать решение, которое не рассыплется при развитии проекта.

Отвечено: 0 из 30

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 30 вопросов отведено 85 минут. Код читайте построчно: часть заданий проверяет не результат JavaScript, а то, что TypeScript способен доказать до запуска.

Вопрос 1 из 30

Почему две переменные структурно совместимы, хотя относятся к разным сущностям?

type UserId = string;
type OrderId = string;

let userId: UserId = "u-1";
const orderId: OrderId = "o-9";
userId = orderId;

TypeScript сравнивает только имена переменных OrderId неявно наследуется от UserId Псевдонимы типов проверяются только при запуске Присваивание разрешено из-за let Оба псевдонима раскрываются в один и тот же структурный тип string

Вопрос 2 из 30

Что именно отличает два интерфейса в этом примере?

interface UserRef { readonly value: string }
interface OrderRef { readonly value: string }

const order: OrderRef = { value: "o-1" };
const user: UserRef = order;

Присваивание возможно лишь из-за const Ничто: одинаковая структура делает присваивание допустимым Имена интерфейсов всегда создают номинальные типы Интерфейсы совместимы только внутри одного файла readonly запрещает совместимость

Вопрос 3 из 30

Какой приём создаёт различие, не добавляя обычное поле в runtime-объект?

declare const userIdBrand: unique symbol;
type UserId = string & { readonly [userIdBrand]: true };

Переименование string через type alias Добавление необязательного поля brand?: string Объявление enum с тем же именем Использование String вместо string Пересечение с приватным для модуля свойством на unique symbol

Вопрос 4 из 30

Когда структурная совместимость полезнее номинальной?

Когда значение должно быть создано одной фабрикой Когда вход прошёл конкретную бизнес-проверку Когда API различает метры и секунды Когда два строковых идентификатора нельзя путать Когда важна роль объекта по форме, а не происхождение

Вопрос 5 из 30

Почему не стоит брендировать каждую строку в проекте?

Бренды заметно замедляют JavaScript Любой бренд делает тип mutable unique symbol запрещён в прикладном коде Бренд нужен лишь при реальном риске подмены Брендированные строки нельзя хранить в массиве

Вопрос 6 из 30

Почему OrderId нельзя передать вместо UserId?

declare const userBrand: unique symbol;
declare const orderBrand: unique symbol;
type UserId = string & { readonly [userBrand]: "UserId" };
type OrderId = string & { readonly [orderBrand]: "OrderId" };

declare const orderId: OrderId;
function loadUser(id: UserId) {}
loadUser(orderId);

Литералы UserId и OrderId сравниваются по длине У типов разные обязательные символьные свойства Параметр функции автоматически invariant Строковые пересечения нельзя передавать в функции declare делает значение unknown

Вопрос 7 из 30

Какой недостаток у общедоступного текстового поля __brand?

type UserId = string & { readonly __brand: "UserId" };

TypeScript запрещает строковые маркеры Строковый ключ превращает значение в number Поле будет автоматически добавлено к строке во время выполнения Структуру бренда можно воспроизвести через утверждение типа Такой бренд совместим со всеми объектами

Вопрос 8 из 30

Что получится у массива ids после map?

declare const brand: unique symbol;
type UserId = string & { readonly [brand]: true };
declare const ids: UserId[];

const normalized = ids.map(id => id.toLowerCase());

Array<UserId | undefined> readonly UserId[] string[] UserId[] never[]

Вопрос 9 из 30

Как назвать бренд, чтобы он был полезен в диагностике?

Случайным хешем без описания По типу носителя, например BrandedString По имени файла По доменному смыслу и проверяемому инварианту Всегда Brand1

Вопрос 10 из 30

Какая модель лучше для денежных величин в разных валютах?

Любая строка вида 100 USD без парсинга Бренд только для положительных сумм, но без валюты Один number с комментарием Доменный Money<C>, связывающий сумму и валюту Два независимых параметра amount: number и currency: string во всех функциях

Вопрос 11 из 30

Почему фабрика возвращает UserId | undefined?

declare const brand: unique symbol;
type UserId = string & { readonly [brand]: true };

function parseUserId(raw: string): UserId | undefined {
  return /^u-[0-9]+$/.test(raw) ? raw as UserId : undefined;
}

Бренд нельзя вернуть без undefined Все функции-парсеры должны быть асинхронными Она связывает утверждение бренда с фактической проверкой формата UserId существует только внутри условного оператора Регулярное выражение меняет тип строки автоматически

Вопрос 12 из 30

Какой дефект у этой фабрики?

type Positive = number & { readonly __brand: "Positive" };
function positive(value: number): Positive {
  return value as Positive;
}

Параметр должен иметь тип unknown Бренд должен быть optional number нельзя пересекать с объектом Она не проверяет value > 0 Функция обязана возвращать Promise<Positive>

Вопрос 13 из 30

Почему assert-функция может быть удобна на границе CLI?

function assertPort(value: number): asserts value is Port {
  if (!Number.isInteger(value) || value < 1 || value > 65535) {
    throw new RangeError("invalid port");
  }
}

Успех сужает значение до Port, ошибка прекращает запуск Она заменяет все number в области видимости Проверка диапазона становится необязательной Функция выполняется только во время компиляции asserts сохраняет бренд в JSON

Вопрос 14 из 30

Какой результат фабрики удобнее, если интерфейс должен показать причину отказа?

Просто false Размеченный результат: бренд либо структурированная ошибка UserId с пустой строкой при ошибке Любая string с предупреждением в журнале Бесконтрольное исключение без типа

Вопрос 15 из 30

Где должны находиться небезопасные утверждения бренда?

В файле деклараций без реализации Только в компонентах интерфейса В каждом месте использования В небольшом модуле-фабрике рядом с проверкой В случайных вспомогательных функциях

Вопрос 16 из 30

Почему параметр raw должен быть unknown, а не UserId?

async function readUserId(response: Response): Promise<UserId> {
  const raw = await response.json();
  // ...
}

Бренд автоматически восстанавливается после JSON.parse Ответ сети ещё не доказал ни строковый тип, ни доменный формат Promise стирает тип результата unknown нужен только для чисел Response.json всегда возвращает UserId

Вопрос 17 из 30

Что теряется после JSON.stringify/parse?

declare const id: UserId;
const restored = JSON.parse(JSON.stringify(id));

JSON добавит символьный ключ бренда Статическая гарантия бренда UserId превратится в never Ничего: тип сохраняется в JSON Строковое значение обязательно изменится

Вопрос 18 из 30

Почему функция repository.find принимает UserId, а не string?

interface UserRepository {
  find(id: UserId): Promise<User | undefined>;
}

Чтобы не принять ID другой сущности или непроверенную строку string нельзя использовать в интерфейсах Promise работает только с branded types База данных хранит TypeScript-бренд Это ускоряет индексный поиск

Вопрос 19 из 30

Нужно ли экспортировать функцию unsafeUserId(raw: string): UserId из публичного пакета?

Обычно нет Да, но только под коротким именем Да, иначе бренд нельзя использовать Всегда экспортируют вместе с каждым типом Нет, потому что функции не могут возвращать intersections

Вопрос 20 из 30

Как передать брендированное значение в SQL-драйвер, ожидающий string?

Сначала привести к unknown Передать его как string Отключить типы драйвера Создать объект { brand, value } для каждого запроса Сериализовать символьный бренд

Вопрос 21 из 30

Какую гарантию должен удерживать типовой тест фабрики parseUserId?

declare const userIdBrand: unique symbol;
type UserId = string & { readonly [userIdBrand]: true };
declare function parseUserId(raw: string): UserId | undefined;

Фабрика обязана бросать исключение для каждого неверного значения После успешной проверки возвращается UserId, а не обычная string UserId перестаёт быть совместимым с параметром string Любая строка автоматически становится UserId Бренд присутствует в JSON после сериализации

Вопрос 22 из 30

Какой отрицательный пример точнее всего проверяет раздельность доменных идентификаторов?

declare const userBrand: unique symbol;
declare const orderBrand: unique symbol;
type UserId = string & { readonly [userBrand]: true };
type OrderId = string & { readonly [orderBrand]: true };
declare function loadUser(id: UserId): void;

Проверка пустой строки до создания бренда Передача OrderId в функцию loadUser(UserId) с @ts-expect-error Сравнение двух UserId через === Сериализация UserId в JSON Передача UserId в функцию, принимающую string

Вопрос 23 из 30

Почему после JSON.parse нельзя сразу считать поле id значением UserId?

declare const raw: unknown;
// raw получен из JSON.parse(responseText)

TypeScript проверяет содержимое JSON во время выполнения После JSON остаётся строка без доказанного бренда Бренд превращается в enumerable-свойство объекта После parse строка получает тип never JSON.parse восстанавливает unique symbol автоматически

Вопрос 24 из 30

Фабрика идентификатора стала принимать строки без префикса usr_. Какой тест важнее всего обновить или восстановить?

Runtime-тесты допустимых и недопустимых строк Только снимок declaration-файла Только тест присваивания UserId переменной string Проверку размера JavaScript-бандла Компиляцию с выключенным strict

Вопрос 25 из 30

Какой набор проверок лучше всего защищает функцию, принимающую UserId?

Только сериализация и обратный parse Только проверка регулярного выражения UserId допустим, OrderId запрещён, фабрика проверена Только один вызов с UserId Только @ts-expect-error для обычной string

Вопрос 26 из 30

Какой публичный контракт оставляет реализации больше свободы?

export interface UserReader {
  find(id: UserId): Promise<UserSummary | undefined>;
}

Функция принимает UserId и возвращает UserSummary, не раскрывая способ хранения записи Интерфейс публикует cacheKey и sqlRowId Функция принимает ORM-сущность вместе с внутренним контекстом API возвращает объект с закрытым символом бренда как обычным полем Потребитель передаёт строку и сам ставит as UserId

Вопрос 27 из 30

Что в этом типе сильнее всего связывает потребителя с внутренней реализацией?

export interface UserView {
  id: UserId;
  displayName: string;
  ormEntity: object;
  cachePartition: number;
}

Поля ormEntity и cachePartition Само поле id типа UserId Экспорт интерфейса из модуля Readonly-модификатор у id Строковый тип displayName

Вопрос 28 из 30

Формат идентификаторов меняется с usr_123 на UUID. Как безопаснее эволюционировать публичный API?

declare function parseUserId(raw: string): UserId | undefined;
declare function formatUserId(id: UserId): string;

Заменить UserId на string во всех публичных сигнатурах Привести старые строки к новому бренду через as Раскрыть регулярное выражение формата в каждом потребителе Добавить новый бренд без миграции сохранённых значений Сохранить UserId, обновить фабрику и проверить старые данные

Вопрос 29 из 30

Как проверить, что новая версия библиотеки не сломала потребителей UserId?

Собрать старые сценарии создания, передачи и сериализации Убедиться, что имя UserId не изменилось Запустить formatter на типах Проверить только внутренние unit-тесты фабрики Сравнить число строк в d.ts

Вопрос 30 из 30

Какой признак показывает, что система брендов стала неудобной для потребителя?

В проекте есть два разных доменных идентификатора Бренды объявлены через unique symbol Обычный сценарий требует цепочки as unknown as Фабрики возвращают Result вместо исключения Идентификатор можно передать функции, принимающей string

Ответьте на все 30 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу