在一个普通的NodeJS教程中,我注意到讲师总是试图以一种方式来定义他的变量,以确保没有像这样的令人惊讶的赋值或值:
p.name = typeof (coinPair.name.toUpperCase()) === 'string' ? coinPair.name.toUpperCase() : false我开始在我的许多代码中使用这种方法,以保证如果值没有像预期的那样被赋值,最好将其赋值为false (或其他一些特定的默认值),以便更容易检测应用程序崩溃的原因并避免意外的行为。
当我开始使用TypeScript时,我意识到了它的原生类型安全特性,这让我不禁要问:当我使用静态严格类型时,上面使用的方法还合理吗?当TypeScript已经不允许在执行过程中更改类型时,它会有用吗?
与我讨论过的一位开发人员认为TypeScript最终会转换为JavaScript,并声称它的类型安全性只对调试有用,在运行时它仍然是javaScript而没有TypeScript安全性。他声称,使用TypeScript定义为字符串的变量仍然可以接受数字(可能强制为偶数?)。
我现在很困惑。TypeScript类型安全措施是否足够,或者我仍然应该在必要时使用上述方法?
发布于 2019-05-09 05:12:02
如果您只为自己或您的团队使用代码,并且您或您的团队创建的所有内容都在TypeScript中,那么您就不需要这些类型的检查。否则,如果你正在分享,或者计划分享你的代码,它将需要边界。即使不是你写的代码也应该有界限。这些边界在哪里,这是一个设计和开发决策。一些库有很大的边界(例如,一种语言的标准库),而另一些库有非常小的受控边界。
在这些边界处,您可以选择执行上述检查。正如你的同行所声称的那样,TS中的任何东西都不会在运行时保护你。如果您创建了TS模块并将其发布到NPM上,则应该发布JS。JS开发人员可以导入/请求你的模块,并在他们的JS代码中使用它,并传递他们想要的任何东西。
此外,即使您确定您的调用者也将使用TypeScript,您仍然可能遇到此类边界检查问题。例如,检查对象是否未定义或为空,确保从web请求传入的JSON是有效的,等等。然而,JS是一种松散的语言,它往往需要相当详尽的边界检查,所以你在TS教程中看到它们也就不足为奇了,因为迁移的JS开发人员非常习惯于这样做。
在这一点上,它可能是基于意见的。例如,我知道许多开发人员在整个代码库中详尽地散布null检查。总的来说,我个人认为这是糟糕的设计和缺乏边界意识的症状。我个人非常反对执行有效性检查&断言,以便更早地检测到bug。这样的检查会使代码的可读性变得复杂,并减少代码的维护。
https://stackoverflow.com/questions/56048731
复制相似问题