Как не забыть вариант объединения
Вопрос
Как вы обрабатываете все варианты объединения и защищаетесь от того, что кто-то добавит новый вариант и забудет его обработать?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Моделирую состояния дискриминированным объединением с литеральным тегом
`switch` по тегу, в каждом `case` тип сужен до одного варианта
В `default` присваиваю значение переменной типа `never` или вызываю `assertNever(x)`: новый вариант даст ошибку компиляции
Альтернатива: объект-обработчик `Record<Tag, Handler>` через `satisfies`, пропущенный ключ тоже ловится
Флаг `noFallthroughCasesInSwitch` и правило линтера `switch-exhaustiveness-check`
Что могут спросить следом
- Почему не хватает
default: return null? - Что вернёт
assertNeverв рантайме? - Как быть, если тег приходит с сервера и может быть неизвестным?
Разбор
Варианты данных я описываю дискриминированным объединением: у каждого есть поле kind или status с литеральным типом. Обрабатываю через switch по этому полю, и в каждом case компилятор уже знает точный вариант. Чтобы не забыть новый вариант, в default пишу assertNever(x), где параметр имеет тип never. Пока всё обработано, туда попадает never, и код компилируется. Добавили вариант и не обработали, получаем ошибку компиляции прямо в этом месте. Просто default: return null такой защиты не даёт, он молча проглотит новый случай. Если тег приходит с сервера, в рантайме может прийти и незнакомое значение, поэтому assertNever бросает исключение или логирует, а сами данные стоит проверять на входе схемой.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.