Комментарии 6
Не совсем понимаю смысл с StrictOmit, на выходе то-же самое, но компиляционные расходы выше...
https://github.com/ts-essentials/ts-essentials#strictomit
Вот разница.
Вопрос в том хотите ли вы получить ошибку сборки или просто пустой тип в случае несуществующих свойств.
Почему пустой-то? Исключили то, чего там и так не было – т.е. получим исходный тип, нет?
Вообще вижу два совершенно разных сценария использования, в одном StrictOmit добавит чуть спокойствия (подстрахует от опечаток и т.п.), а в другом (когда он использован не по делу) с ним просто не скомпилируется.
Пример с датой — это грязный хак. На одной стороне нужно все время использовать явное приведение типов, на другой — получаем непонятную ошибку. А самое печальное — на практически любых операциях (строковые функции для строк, математические операторы для чисел) branding слетает и остается только базовый тип. В результате у нас остается гора бойлерплейт-кода, которая не дает существенной защиты от ошибок.
При этом для работы с датами в JS есть встроенный тип Date (довольно ущербный, но все же), есть MomentJS / Luxon, и есть всякие JSON-декодеры типа io-ts для превращения прилетающих строк в объекты нормальных типов.
Не отрицаю что возможно это удобно, но по мне, большая обертка с типизацией, усложняет код.
Публикации
Рекомендации по работе с TypeScript