Комментарии 7
Э... А не проще в примере с Card/BankTransfer просто убрать default? Раз уж у нас есть строгая типизация – было б неплохо ей пользоваться.
Или это подстраховка на случай кривых значений, пришедших из JavaScript? Но ведь они могут быть и ещё более кривыми.
Тут же используются switch statement, а не switch expression (последнего и в языке-то нет). А switch statement никак не проверяет полноту вариантов.
Иными словами, вот такой код совершенно корректен:
function fn(x: 'foo' | 'bar' | 'baz') {
switch (x) {
case 'bar': return;
case 'baz': return;
}
}Ну и как тут без default отследить, что одного варианта не хватает?
А, тогда понятно. Хотя вроде в примере из статьи, когда возвращается не undefined –автоматом отследится.
А так – если вы готовы везде писать exhaustive switch, то удобнее https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/switch-exhaustiveness-check.md – всё лучше, чем явные заглушки в default.
Не легче – ведь тут же речь о том, чтобы разработчику не приходилось держать в голове/искать все использования Union'а при его изменении, а переложить эту ответственность на TS – и именно благодаря default case с exhaustive check TS сам подсветит все места, нуждающиеся во внимании/в поддержке.
По идее в проекте у разработчика под полным контролем TS всё, за исключением двух источников неопределённых данных – пользовательский ввод и данные с бэка (хотя на них можно накинуть валидаторы схем – как раз для подстраховки).
А можно, не надо, подход с onMsg рекомендовать. Это примерно антипатерн «Божественный метод». Давайте нормальные абстракции для компонентов продумывать а не костыли, маскирующие проблему, городить. Всем добра.
Frontend Talks: усиливаем TypeScript с помощью switch + notReachable