TypeScript Безопасность типов в приложениях Node

Question

В учебном пособии по NodeJS я заметил, что инструктор всегда пытается определить свои переменные таким образом, чтобы не было никаких удивительных присвоений или значений, таких как этот:

p.name = typeof (coinPair.name.toUpperCase()) === 'string' ? coinPair.name.toUpperCase() : false

Я начал использовать этот метод во многихиз моих кодов, чтобы гарантировать, что если значение не будет назначено должным образом, лучше присвоить значение false (или другое конкретное значение по умолчанию), чтобы было легче обнаружить причины сбоя приложения и избежать непредвиденного поведения.

Когда я начал использовать TypeScript, я осознал его «встроенные функции обеспечения безопасности типов», что заставило меня спросить: все ли разумно использовать метод, описанный выше, при статической строгой типизации моих переменных?Будет ли это полезно, когда TypeScript уже не допустит изменения типа во время выполнения?

Разработчик, с которым я обсуждал, спорил, что TypeScript переносится в JavaScript в конце дня, и утверждал, что его «безопасность типов толькополезен для отладки и что во время выполнения он все еще javaScript без безопасности TypeScript.Он утверждал, что переменная, определенная как строка с TypeScript, все еще может принимать число (возможно, даже принудительное?).

Сейчас я в замешательстве.Должны ли меры безопасности TypeScript быть достаточными, или я все еще должен использовать вышеуказанный метод по мере необходимости?

Answer 1

Если вы используете свой код только для себя или своей команды, и все, что вы или ваша команда создаете, написано на TypeScript, тогда вам не нужны такие проверки. В противном случае, если вы делитесь или планируете поделиться своим кодом, ему понадобятся границы. Даже код, который вы не пишете, должен иметь границы. Где эти границы находятся и является решением для проектирования и разработки. Некоторые библиотеки имеют большие границы (например, стандартная библиотека языка), а другие имеют очень маленькие контролируемые границы.

На этих границах вы можете выполнить вышеуказанные проверки. Как утверждает ваш коллега, ничто в TS не защитит вас во время выполнения. Если вы создали модуль TS и опубликуете его в NPM, вы должны опубликовать JS. Разработчик JS может импортировать / запрашивать ваш модуль, использовать его в своем коде JS и передавать все, что пожелает.

Кроме того, даже если вы уверены, что ваши вызывающие абоненты также будут использовать TypeScript, у вас все равно могут возникнуть проблемы с проверкой границ. Например, проверка того, являются ли объекты неопределенными или нулевыми, проверка правильности передачи JSON из веб-запроса и т. Д. Однако JS - такой свободный язык, что он требует довольно полных проверок границ, поэтому неудивительно, что вы увидите они в обучающих программах по TS, как разработчики JS, которые мигрировали, привыкли делать это.

На данный момент это, вероятно, основано на мнении. Например, я знаю многих разработчиков, которые исчерпывающе разбрасывают пустые проверки по всей базе кода. Вообще я лично вижу в этом симптом плохого дизайна и неосведомленности о границах. Лично я категорически против идеи проверки и подтверждения достоверности, чтобы ошибка обнаруживалась раньше. Такие проверки усложняют читабельность кода и сокращают его обслуживание.