今天小编给大家分享一下原生JS以后也支持类型注解的意义是什么的相关知识点,内容详细,逻辑清晰,相信大部分人都还太了解这方面的知识,所以分享这篇文章给大家参考一下,希望大家阅读完这篇文章后有所收获,下面我们一起来了解一下吧。
为什么需要原生类型注解?
根据20年、21年state of JS的统计,静态类型高票当选JS中当前最欠缺的功能。
同时,在Github报告中,TS
被列为第四大最常用的语言
所以,对前端工程师来说,类型注解需求很大。
那么,既然已经有了TS
,为什么还需要原生JS
支持类型注解呢?
通常来说,从开发者编写的源代码到线上生产环境代码间需要经过代码编译。
代码编译主要包括两个步骤:
降级编译(包括高级语法转换为低级语法,高级方法的
polyfill
)代码转译(比如压缩、混淆、tree-shaking、类型擦除)
所谓类型擦除,是指擦除代码中的类型注解,让其变成符合原生JS
规范的代码,比如:
// 擦除前function add(a: number, b: number): number { return a + b;}// 擦除后function add(a, b) { return a + b;}
随着时间的推移,各主流浏览器兼容性越来越好,步骤1在可预见的未来重要性会逐渐降低。
对于TS
开发者,从源代码到线上生产环境代码间可能只需要类型擦除。
如果原生JS
支持类型注解,就能省去类型擦除对应的编译流程,让代码更容易在宿主环境执行。
和TS的关系
这份提案的目的,并不是另起炉灶,独立实现一套原生JS
的类型注解。而是与TS团队合作,提出一套合适的规范。
新的规范与TS规范的关系类似下图:
一方面,Type Annotations
提案从TS
中借鉴了很多特性,这就是图中相交的部分。
你可以到grammar-conventions看到规范当前定义的类型
另一方面,TS
迭代速度很快,新的特性产出很快。而Type Annotations
作为JS
语言的一部分,迭代会更加保守,所以TS
中一些特性在Type Annotations
中并不支持。
此外,TS
中一些结构(比如Enums
、Namespaces
)存在运行时的语义,Type Annotations
也不会支持。
这些就是TS
中存在,而Type Annotations
中不存在的部分。
最后,Type Annotations
设计的初衷并不是与TS
强绑定,而仅仅是提供一套类型规范,开发者编写代码时的类型检查还是由各种类型检查器(比如TS
、Flow
)实现。
所以,Type Annotations
还有一部分特性是TS
当前未定义的,这也是为了规范更广泛的适用性考虑的,也就是图中Type Annotations
存在,而TS
不存在的部分。
这部分特性需要TS
后续实现,这也是为什么Type Annotations
要与TS
团队合作的一大原因。
对开发者意味着什么
如果Type Annotations
最终出现在ES20xx
版中,届时开发者编写代码的步骤是:
选择合适的类型检查器(比如
TS
),这个类型检查器需要完全遵循Type Annotations
规范(而不是自己的规范,比如TS
规范)编写带类型声明的原生
JS
代码类型检查器会检查类型错误,并给予报错或提示
对于如下原生JS
代码,如果开发者传入了错误的类型,JS
会报错么?
function add(a: number, b: number): number { return a + b;}// 错误的类型传参add('KaSong', 123);
答案是:不会。
Type Annotations
仅仅是一套规范,该规范由各种类型检查器执行。
JS
的宿主环境(比如浏览器)在执行带类型声明的JS代码时,会忽略类型声明。
以上就是“原生JS以后也支持类型注解的意义是什么”这篇文章的所有内容,感谢各位的阅读!相信大家阅读完这篇文章都有很大的收获,小编每天都会为大家更新不同的知识,如果还想学习更多的知识,请关注编程网行业资讯频道。