前端进阶：Javascript类型系统缺陷与解决方案

已注销
834 阅读12分钟

前言：博主2020.3正式进军前端，目标高级前端工程师，经验尚浅，文章内容如若有误，欢迎指正。

一：编程语言的类型系统

1.强类型语言 与 弱类型语言

语言类型的强弱之分，业界并没有权威的对比概念，所以网上有很多种不同的说法。但大部分说法的意思都在说明强类型语言有更强的类型约束，而弱类型中几乎没有什么约束。

以下个人学习课程之后对强类型与弱类型的理解：

  • 强类型语言：程序运行时变量类型不允许任意的隐式类型转换（类型安全）。
  • 弱类型语言：程序运行时变量类型允许任意的隐式类型转换（类型不安全）。

最简单的代码理解案例：

// 强类型语言：java、python等
100 - '50' //报语法错误

// 弱类型语言：javaScript
100 - '50' // 50

2.静态类型语言 与 动态类型语言

以下个人学习课程之后对静态类型类型与动态类型的理解：

静态类型：程序开发时变量类型声明后，不允许再修改（编译阶段检查类型）。 动态类型：程序开发时变量类型声明后，可以随时发生变化（运行阶段检查类型）。

最简单的代码理解案例：

// 静态类型语言：java
int a = 100;
a = '100';  // 报语法错误

// 动态类型语言:javascript
var a = 100;
a = '100';  // typeof(a) 输出 'string'

3.主流编程语言分类

二：Javascript类型系统缺陷

1.程序健壮性差

JavaScript语言本身是一种动态弱类型的解释型语言。在具体探讨它的类型缺陷之前，我们先看日常开发当中的几个JavaScript常见类型错误示例：

let fn, name, age = 10, inputAge = '1';
fn()			// 运行时报错，undefined不能当作函数对象不能调用
const fn1 = fn; // 潜在错误：fn1并不是一个方法

age = age + inputAge;// 运行不准确，但age计算不准确，同时类型转为string也是一个潜在错误
<p> {name} </p> 	// 运行不准确，用户看到undefined

从上述代码我们可以感觉到，我们平常写的JavaScript程序发生的很多错误其实都是类型错误，我们在找到这些错误并且调试解决它花了不少时间，尽管如此，程序中依然还有很多潜在的类型错误没有发现，下面思考一波发生这些错误的原因：

  • JavaScript是动态类型：意味着在程序开发阶段，开发者开发出的源代码没有经过类型检查就直接交给解释器执行。

  • JavaScript是弱类型：意味着程序在运行阶段碰到开发者造成的类型问题时，程序会自作主张的进行隐式类型转换，无法转换则报错，转换成功则返回运算结果（有时候不是开发者所期望的运行结果，即运行不准确）。

  • JavaScript既是动态类型又是弱类型，这使得JavaScript程序在运行期间很容易发生类型错误、隐藏潜在错误、以及错误不被识别为错误导致程序运行不准确。

2.原始解决方案

程序很容易发生类型错误、隐藏潜在错误、以及错误不被识别为错误而运行不准确，一个好的开发者绝对无法认同这些事情的存在，所以我们在日常JavaScript开发中，经常会加上一些类型判断代码来避免错误的发生，如下代码示例：

// 案例1
const obj = {};
// obj.foo();	// error
if(obj.foo){	// 防错处理
	obj.foo();
} else {
  // xxx  
}

// 案例2
function sum (a, b) {
   return a + b
}
function sum (a, b) {	// 防错处理
    if (!(typeOf(a)=== 'int' && typeOf(b)=== 'int')){
        throw new TypeError('arguments should be number');
    } 
   return a + b
}

在写JavaScript时，我们会经常有意的写这些代码来避免或者解决类型错误，但是我们分析一下这样解决类型问题的缺点：

  • 更大的开发成本：开发者除了需要编写代码的核心逻辑之外，还需要花费更多的时间精力去编写避免类型问题的代码，尤其在封装给别人使用时，这个问题尤其显著。
  • 只能解决部分问题：我们不可能在每次变量使用前都做一次类型判断，所以这种方案只能解决部分类型错误。
  • 大量类型判断代码：这种方案需要在程序中编写大量类型判断代码来避免错误，这容易导致代码量变大、核心业务代码被隐藏、代码不够清晰等问题。
  • 性能问题：在运行阶段需要运行这些类型判断逻辑代码，肯定需要消耗更多的运行时间。

上述解决方案虽然比较丑陋，但是这就是我们平常写JavaScript代码避免类型问题的默选方案。

先是讲到JavaScript的类型系统这么多缺陷，后是讲到原始解决方案还这么敷衍，有没有突然有一种用JavaScript语言编程好差劲的感觉，难怪往前这么多人称呼JavaScript为小丑语言，难堪大任！

JavaScript在运行期间出现的这么多类型问题，其实都是源于JavaScript本身对变量类型没有约束，开发阶段无法进行类型检查，从而使得开发者编写出的JavaScript代码容易出现编程错误导致的。

借鉴其它语言的做法，我们可能会想到，开发阶段的类型约束会是类型判断之外的解决JavaScript类型错误的另一种方案。实现上，这种思想现在有两种主流的解决方案，即Flow 和 Typescript。它们都是通过在源代码上加上类型声明来实现的类型约束和类型检查，然后通过编译得到一份类型严谨的JavaScript代码交给JavaScript解释器执行的方式来解决的类型问题，这主要涉及到开发、检查、编译三个过程：

  • 开发阶段：开发阶段根据规则为变量加上合适的类型声明。
  • 检查阶段：使用检查工具根据变量的类型声明和变量值进行匹配检查。分为编码时检查（代码提示）、编码后检查、编译时检查三种。
  • 编译阶段：使用编译工具为变量移除类型声明而后得到一份类型严谨的JavaScript代码。

3.Flow解决方案

Flow是JavaScript的静态类型检查工具，它定义了一套类型约束与检查规则，在检查通过之后可以编译出一套类型严谨也没有Flow类型声明的JavaScript代码，解决JavaScript类型问题。下面从开发、检查到编译三个阶段简单说明Flow提供的解决方案是如何解决JavaScript类型问题的，具体的使用细节查阅官方文档即可。

1):开发阶段添加类型声明

添加类型声明涉及到三个部分，即自己代码中的类型注解、环境下api（window / node）的类型注解以及第三方库（引入的lib）中的类型注解。环境下api以及第三方库的文件中缺乏类型注解时，我们通常会通过引入类型声明文件的方式来解决。

下面是给自己代码中加上类型声明的案例：

// @flow
// test.js
function sum(m: number, n: number): number {
	return m + n
}

2):检查阶段进行类型匹配

类型检查分为编码时检查、编码后检查、编译时检查三种，编码时检查工具通常是IDE提供的插件，编码后以及编译时检查通常是使用官方提供的检查工具。

Flow的编码时检查工具此处不做探讨，下面简单说明一下Flow编码后检查的工作流：

  • 安装检查工具flow-bin
yarn add flow-bin --dev
  • 写入检查配置信息：.flowconifg
# 生成.flowconifg配置文件，在这里可以配置检查源、检查规则、检查输出位置等
yarn flow init
  • 读取配置执行检查
yarn flow
  • 控制台输出检查结果
  • 根据检查报告修改代码中类型错误

3):编译阶段移除类型声明

Flow源代码中的类型注解并不符合JavaScript语法，直接丢给JavaScript解释器执行会报错，所以我们需要对源代码进行编译移除类型声明，得到能够被JavaScript解释器执行的JavaScript代码，解决JavaScript类型问题。

移除JavaScript文件中的Flow类型注解有两种方案：

  • 使用工具库flow-remove-types移除
# 安装
yarn add flow-remove-types --dev
# 移除:命令参数，编译输入代码的位置、编译输出代码的位置
yarn flow-remove-types src -d dist
  • 使用Babel插件@babel/preset-flow移除
# 安装
npm install --save-dev @babel/core @babel/cli @babel/preset-flow
# 配置：.babelrc文件配置preset-flow插件
{
  "presets": ["@babel/preset-flow"]
}
# 转换：命令参数，编译输入代码的位置、编译输出代码的位置
yarn babel src -d dist

三：Typescript终极解决方案

和Flow一样，TypeScript也是JavaScript的类型检查器。不同的是，Typescript功能上更强大更完善，生态上也更加健全。在语法上，Typescript是Javascript的超集，它与JavaScript的关系如下图： 在这里插入图片描述

以下是除官话外，个人对Typescript的认识：

Typescript这门语言其实并不能和C、C++、Java、JavaScript这些语言相谈并论，它只能算是JavaScript的切面语言，因为它的变量类型和语法规则只涉及到开发和编译阶段，在编译之后转换为JavaScript交给JavaScript解释器执行。这也意味着，我们在学习typescript这门语言的类型和语法时，完全不必要关注它的运行机制与存储规则，而是只需要理解它与JavaScript类型和语法的映射关系即可。

下面我们从开发编译两个阶段简单说明Typescript提供的解决方案是如何解决JavaScript类型问题的，具体的使用细节查阅官方文档即可。

1.开发阶段使用Typescript语法

从上图我们也可以看到，Typescript除了支持静态类型之外，还支持ES6语法。接下来我们主要关注它是怎么解决JavaScript的类型问题的。 与Flow一样，Typescript的类型声明也涉及到到三个部分，即自己代码中的类型注解、环境下api（window / node）的类型注解以及第三方库（引入的lib）中的类型注解。环境下api以及第三方库的文件中缺乏类型注解时，我们通常会通过引入类型声明文件的方式来解决。

下面是给自己代码中加上类型声明的案例：

// test.ts
function sum(m: number, n: number): number {
	return m + n
}
编码时检查

typescript可以归属于静态语言，IDE对其代码具备很强的感知能力，所以IDE可以为开发者提供很强大的编码时检查、代码提示、错误提示等功能。

2.编译阶段转换Typescript语法

与Flow一样，Typescript源代码也不能直接交给JavaScript解释器执行。我们需要使用官方提供的tsc工具将typescript代码编译为JavaScript代码，解决Javascript的类型问题。

以下简要说明Typescript的编译工作流：

  • 安装typescript
yarn add typescript --dev
  • 写入编译配置：tsconfig.json
# 1.生成.flowconifg配置文件，在这里可以配置检查源、检查规则、检查输出位置等
yarn tsc --init

# 2.修改tyscript配置文件，主要涉及到编译输入文件位置、输出文件位置、编译规则等
# xxx
  • 读取编译配置执行编译
yarn tsc
  • 编译结束，成功得到JavaScript代码，失败则根据编译报错信息修改代码。

3.Typescript类型系统

这里简单提一提Typescript的类型系统，Typescript官网文档对它的类型划分为以下几类：

类型含义示例
basic Types基本类型number、Tuple、Void...
Interfaces接口类型{ x : 'xx' } / interface xxx { x 'xx'}
Unions and Intersection Types并集、交集类型object | null
Literal Types字面量类型1 | 2 | 3
Enums枚举类型Enum x { x '1' }
Functions函数类型function (m: number): Void { // xxx,no return }
Classes类类型完整的java类，访问控制，单继承多实现
Generics泛型值泛型：Array<number>，函数泛型、类泛型

Typescript作为新出现的静态语言，它的类型系统吸收了很多其它语言中优秀的类型，尤其是Java。其实对于这些各种类型约束，我们也可以等同的使用原始解决方案为代码加上类型判断来解决类型问题。使用typescript虽然会造成初期开发增加，但是它可以让我们不用大量的类型判断就可以写的一手类型严谨、性能更好、维护性更好的JavaScript代码。如果想做一位JavaScript的优秀coder，不用我说也会拥抱Typescript吧！

对于typescript的学习成本，其实它的学习成本很低，特别是对于有静态语言使用经验的开发者来说，因为它只涉及到开发和编译阶段，我们只需要理解它的各种类型含义并熟悉运用就可以写的一手好Typescript代码。

本文结束，观众老爷您慢走，欢迎下次光临。

avatar
文章
阅读
粉丝