JS是一个动态数据类型的语言，所谓动态数据类型，是指在程序运行过程中，一个变量的数据类型可以随时改变。这有好处也有坏处，好处是灵活性，坏处不言而喻，就是输入输出的不可控。为了解决这个问题，TypeScript应运而生，它可以通过撰写数据类型的接口、范型等，对程序中的数据类型做一个规定，在编译时，根据代码的上下文对这些类型进行检查，比如你声明了一个原本为数值型的变量，想要传入到一个规定为字符型参数的函数中，编译时就会提示错误。
但是TypeScript无法做到运行时数据类型检查。运行时数据类型问题主要是在和api接口交互时发生，比方说，有个接口要求一定要有哪些字段，即使为空也行，也比如，有些接口返回的格式和你本地代码预期的格式不同，或者数据类型不一样，你预期得到一个数字，但是接口返回给你的是这个数字的字符串形式。
为了解决运行时数据类型的问题，我写了hello-type这个包。（看来我要把hello系列坚持到底了。）
想法
如何解决运行时的类型（甚至是object的格式）检查呢？在比较原始的编程习惯里面，是在业务代码里面实时进行检查，比如：
fetch(api_url).then(res => res.json()).then((data) => {
if (typeof data === 'object' && data.code === 0) {
// 表明正常返回数据
}
if (Array.isArray(data.list)) {
data.list.forEach((item) => {
// 利用列表进行下一步操作
})
}
})
但是很显然，这样做的不足之处在于：1.需要在每处业务代码里面进行检查，耗时耗力，而且可能会出现重复代码；2.对于特定的数据，可能会出现很多if嵌套的问题。
于是我想，针对第一点，只要写出一个数据检查工具，在要进行数据检查时调用某些接口就好了，不必重复写逻辑。针对第二点，能不能让这个工具支持object嵌套检查？
出于这种想法。我先写下了我希望这个工具的代码怎么去写（说到这里，我们在开发一个工具的时候，不必马上去写工具本身的实现代码，可以反过来，先把我要怎么使用这个工具的代码先写出来，然后按照写出来的这些规则方式去实现）。
// 我想要对含有name和age的object进行检查，要求name是字符串，而age必须是数字
const PersonType = new Type({
name: String,
age: Number,
})
// 接下来用SomeType去进行数据类型判断
和TypeScript不同，因为我要实现的工具完全就是ES的语法，TypeScript可以自己制造语法，比如interface之类的，但是我的代码是在运行时执行的，所以不能自己造语法，只能利用ES语法，写出一种模式。最初，我想用name: 'string'这种形式，但是这就意味着我要自己定义每一种数据类型的实际意义，因为'string'这个字符串，虽然字面意思是字符串，但我内部可以认为它是另一种形式。而且，这样的话，我无法做到两件事：a）假如我想规定某个变量的值只能是字符串'string'，我该怎么办？b）假如我希望检查某个变量是否是另一种数据类型（某个类的实例）怎么办？考虑到java里面自己规定数据类型的前车之鉴，我直接用js里面现有的一些接口作为数据类型检查的规则。
怎么进行检查呢？我想来想去，想到了前端单元测试里面的语法，主要有assert, expect, should这类于是我想，干脆采用这种方式比较好，让数据类型检查和单元测试一样，而且它们感觉上也非常接近，于是：
PersonType.assert(person)
把上面这段代码放在函数的开头，对函数的参数person进行检查，如果person的格式和内部字段的数据类型不符合，就直接抛出错误，这样，函数就不会被执行。
在很多文章里面指出，最好不要在代码里面使用throw new Error这个模式抛出错误。我的观点则相反，throw出来的错误非常有利于debug，而且可以通过window.onerror对错误信息进行收集，将收集后的错误信息发送到服务端进行分析。而且，从另外一个角度来看，throw出来的错误，是可以被catch的，对于编程而言，如果确实需要对throw型错误做进一步判别，可以通过catch捕获，根据捕获到的信息决定是否要继续程序往下执行。
PersonType.test(person)
这个方法则主要用于判断，返回一个boolean结果，这肯定是需要的，在很多情况下，开发者自己根据数据类型是否符合预期，自己决定该让程序如何走向。
PersonType.trace(person).with(fn)
这个方法则在执行到这个位置的时候啥也不干，只是对person这个变量进行数据类型追踪，并且通过with传入的函数捕获可能发现的不符合要求而抛出的错误。而且它真的是完全的异步，所谓完全的异步，和Promise的默认表现都不一样，Promise会在一开始被调用时，执行传给它的函数，但这里的trace方法，完全是在异步环境下去做的。不过有一个点就是，在函数内部，决不允许修改person这个变量的属性，你不能传进来的时候person.name = 12344，但是在函数执行过程中又改为person.name = 'xxx'，这种改动会导致追踪不准确。
不过这种方式就要求用户异步捕获，而不能在检查报错时即时进行调整，而assert方法又会阻断程序，test方法又不能获得报错的内容和追踪信息，于是需要提供一个同步的方法，返回检查报错信息：
let error = PersonType.catch(person)
if (error) {
// error是一个new Error
// 检查到传入的person不符合PersonType
// 开发者在这里可以做一些异常提示的界面，但不阻断程序继续
}
我有想过在trace被调用的时候进行person的deep clone，但是后来觉得太消耗资源，异步的目的反而不能达到。
以上就是我一开始的想法，在后来的代码撰写里面，慢慢又加入了新想法，比如ES7的装饰器方式调用，或者用一个更加统一的方式调用，这样当我进行代码检查的时候，直接用编辑器的搜索功能就可以找到所有进行类型断言的代码：
HelloType.expect(PersonType).toBe.typeof(person)
就像一个全局的调用一样，非常好看，所有的代码都可以得到统一，比PersonType.assert()的方式漂亮多了。
基本类型
有了想法之后，开始开发基本的类型容器。和前面的new Type一样，可以创建一个数据类型，这个数据类型的容器拥有一系列方法，也就是上面提到的那些，利用这些方法，就可以去检查某个具体的变量是否是这个数据类型。
const SomeType = new Type({
name: String,
age: Number,
})
let obj = {
name: 'tomy',
age: 10,
}
SomeType.test(obj) // true
let yep = {
name: 'dota',
height: 123,
}
SomeType.test(yep) // false
let doge = {
name: 'gofi',
age: 'unknow',
}
SomeType.test(doge) // false
Type接受任意的内容，比如你可以传入一个Number或String形成一个单独的值：
const NumberType = new Type(Number)
之所以做这种看上去傻的事，是因为你现在可以用NumberType检查一个变量是否为数字。
也可以传入嵌套的对象，这样，在检查的时候，还会进行嵌套检查，如果深层嵌套位置的类型不匹配，也会抛出错误：
const SomeType = new Type({
name: String,
body: {
head: Object,
foot: {
count: Number,
size: String,
},
}
})
你可以看到，SomeType这个类型规定了三层的嵌套模型，如果你检查的object不符合这样的模型结构，就会抛出错误，而且，即使模型结构符合，底层的某一个类型不符合，也会抛出错误。
另外，自己创建的类型，可以被其他类型创建时引用：
const BookType = new Type({
name: String,
author: String,
})
const RoomType = new Type({
book: BookType,
desc: String,
})
在内部实现的时候，如果遇到一个数据类型是Type的实例的话，就调用这个实例对该节点的值进行检查，这样就可以做到层层嵌套。
不过，目前我还不能实现自引用，因为js在一个变量声明的时候，是无法使用自己已经完成的定义的。
扩展类型
我总共扩展出五种类型：Dict, List, Tuple, Enum, Range。
先来看下它们的使用方法：
const DictType = Dict({ name: String })
const ListType = List(Number)
const TupleType = Tuple(Object, ListType)
const EnumType = Enum('red', 'blue', 'yellow')
const RangeType = Range(0, 1)
这几个类型都是通过上面的函数实现创建的。
- Dict（字典）类型实质就是对应object，只是一种更简便的写法。
- List（列表）类型对应的是数组，但是它要求数组的每一个元素具有相同的数据类型。
- Tuple（元组）在js里面没有，它要求传入的一组变量具有固定顺序和固定个数，每一个元素类型可以不同。
- Enum（枚举）在js里面也没有，它要求传入的变量的值只允许从规定的几个值中间进行选择。
- Range（值域）传入两个值，一个最大值，一个最小值，如果要用来断言的数值在这个区间，就通过
Dict和js原生的Object有区别，原生的Object只要求顶层是一个纯对象即可，而Dict则会对对象的里面结构以及属性的类型进行检查。List和原生的Array的区别是，Array里面的每个元素的类型是随意的，只要满足顶层是数组就通过，而List不仅要求数组里面每个对应元素是相同数据类型，而且还会对每一个元素内部的结构进行检查。
当然了，它们都是可以嵌套的，所以，和基本类型new Type组合起来，你可以创造出任何形式的数据类型检查。
检查规则
数据类型也有了，拿到数据，如何验证数据与类型是否相符呢？对于开发者，可以不用深入追究，但是这里作为探讨，可以把一些内部的方法拿来讨论一下。
比如，NumberType.assert(12)怎么确定是通过NumberType.assert('xx')怎么确定不符合？其实很简单：
- 在new Type的时候把期望数据类型存起来
- assert的时候，取出来，进行对比即可
但是js原生的数据类型有很多坑，例如'xxx' instanceof String是false，new Boolean(true) !== true，typeof NaN为number等等。因此，要在内部实现的时候，把这些js里面的坑都填平。
对于嵌套的object的类型检查则要复杂一些，我需要把所有列出来的层级的路径算出来，再和传入的变量的路径去对比，并且要保证路径对应的类型相同。
自定义规则
为了增加灵活性，我还提供自定义规则的能力，不过需要借助一个Rule构造器，通过传入一个处理函数来进行判别，比如我想检查一个值是否只要typeof为object即可：
const ObjectRule = new Rule(function(value) {
return typeof value === 'object'
})
然后用这个rule作为类型进行传入：
const MyType = new Type({
a: ObjectRule,
})
这样，在用MyType进行检查的时候，就能使用自己创建的一个检查规则来对数据类型进行检查。注意，ObjectRule不是数据类型，没有assert等方法，不具备对值进行检查的能力。
HelloType
经过几天的撰写，这个工具就写完了，名字取名HelloType纯粹是因为我已经写了好几个hello系列的包了，实在找不到要怎么取名，就用这种浅显易懂的名字比较好。你可以在这里读到它的说明文档，本文就不详细介绍了，只说一些我觉得需要说的东西。
使用HelloType进行数据检查要分两步走，第一步是创建数据类型，第二部是调用数据类型容器的方法进行检查。在编程上第一步的代码会比较多，如果写在业务代码里面，反而和文章最前面说的那种情况没有两样，除非是即时检查，比如突然兴起，写一个：
(new Type(Number)).assert(arg)
这还可以接受，但是如果想大面积的确定一些类型，比较好的建议，还是专门设立一个文件（夹）把数据类型的创建都放在这些文件里面，在具体的业务代码里面import进来，然后再进行检查：
|-types | |-person | |-book | | |-book.js | |-benifit |-controllers | |-return.js
// book.js
import { Dict } from 'hello-type'
export const BookType = Dict({
name: String,
author: String,
})
// return.js
import HelloType from 'hello-type'
import { BookType } from '../types/book/book.js
export default class ReturnController {
sell(book) {
HelloType.expect(BookType).typeof(book)
// 具体的业务逻辑代码
}
}
在真正写代码的时候，数据检查不仅仅限于某个函数的输入处，也可以在函数结尾return之前对要return的数据进行检查，在调用其他函数之后，对该函数执行结果进行数据类型检查等等。
HelloType不会对原有的项目代码产生任何侵入，即使是老项目，也只是通过加入几行代码来检查，而不会要求修改项目代码的写作模式。但是即使这样，我仍然觉得在函数内，或者程序进程中进行代码注入有违和感，因为HelloType.expect这句代码跟我本身的业务逻辑没有半点关系，也就是说，要在业务逻辑里面加入一些冗余代码，作为有洁癖的程序员，还是会有一点点不舒服。我想到来ES7的新特性：装饰器。
// return.js
import HelloType from 'hello-type'
import { BookType } from '../types/book/book.js
export default class ReturnController {
@HelloType.decorate.with(book => BookType.assert(book))
sell(book) {
// 具体的业务逻辑代码
}
}
装饰器语法用@开头，它对正常的业务逻辑代码没有侵入，只是在类的方法名前面加一句修饰语，类似注释一样，不对方法本身的代码造成任何负担。
TODO
HelloType是一个运行时的数据类型检查工具，运行时的缺点就是占用内存，它在你的程序运行时，需要花资源去进行计算。这也是没办法的，虽然从感觉上讲，其实并不会觉得慢了，毕竟纯计算还是很快的，但是作为有追求的程序员，还是希望后期对类型检查算法进行更深入的优化，以提高性能，即使面对上万条数据，也可以更高效的处理。
另外，装饰器只能作用于类，而不能在普通声明的函数上使用，这也是个坑，能不能有更优雅的方法，让HelloType不侵入普通函数呢？
最后就是报错信息优化，当检查到传入的值与类型不匹配时，要提供更准确的报错信息，帮助开发者或者用户更准确的定位具体是在哪一个数据节点上出现了问题。
