Comments 3
Чтобы не прыгать с проверкой типа DTO нужно прикручивать валидацию ответа. yup/zod - чуть дольше, но гарантированно на выходе правильный тип. Тема с satisfies раскрыта слабо
Спасибо за комментарий, по сути согласен.
Для данных с внешней границы schema-валидация действительно более надёжный путь: zod/yup позволяют один раз разобрать ответ на входе и дальше уже работать не с «DTO, которому поверили», а с проверенным значением. Именно это я и пытался показать в части про границу приложения: снаружи unknown, дальше parse/schema, внутри — нормальный тип.
Единственное, я бы чуть уточнил формулировку про «гарантированно правильный тип»: гарантия появляется, когда схема становится источником истины и тип выводится из неё, например через z.infer. Если DTO и схема живут отдельно, между ними тоже возможен drift.
А про satisfies замечание принимаю. В статье я затронул его скорее как замену as для конфигов, карт, палитр и похожих объектов, но тему действительно можно раскрыть шире: где он помогает сохранить литеральные типы, где проверяет полноту ключей, а где не заменяет runtime-валидацию. Возможно, вынесу это в отдельный материал или дополню пример.
спасибо за статью.
не до конца понял, почему не запретили использовать any на уровне линтера/тсконфига? есть очень маленький процент кейсов, когда использование any оправдано: при миграции с js на ts, при использовании сторонних библиотек написанных на js (даже тут можно написать свои d.ts)
возможно я не сталкивался с другими случаями, когда any оправдано, но они существуют
Точно ли здесь нужен `any`? 13 сценариев из TypeScript-код-ревью — от `unknown` до границы приложения