ipa-document
the documentation webpage for IPA.js
写ipa的动机
最初想写IPA的动机其实是来自两方面的。
一方面可能跟我是学设计出身的，思维习惯上一直比较在乎用户体验。代码本身作为一种产品的话，他的直接用户是他的维护者。从交互设计角度，怎样降低后来的维护者未来的自己在理解这段代码时的成本是我一直关注的。现在的前端开发得益于成熟的组件化工程结构，代码的理解成本已经非常低了。在组件化的工程中，一个组件的代码的理解成本主要成本是来自两方面的：一是对上下游的数据结构的认知成本；二是当前组件的业务逻辑的认知成本。对于javascript语言而言，在业务复杂的时候前者往往是难以降下来的，因为它没有静态类型和声明，我们往往需要翻看上下游很多个组件的代码或者依赖console.log才能对当前组件正在处理的数据结构有个认识。而后者的理解成本往往就是看我们所说的代码是否“优雅”了，这通常需要对设计模式的一些深刻理解以及整个团队较高的素养。
另一方面是因为我在数据组，我发现对数据组的大量的复杂的数据结构而言，前端的代码其实一直是在刀刃上走：kibana上的很多报错都是由于后端的数据异常造成的。也就是说前端的代码的稳定性强依赖于后端返回数据的合法性。而对于一个具有较大数据量和较深数据层级关系的后端响应数据，要校验它的合法性势必是丑陋、啰嗦而易错的。
这两方面结合起来让我有了开发一个声明式的数据校验保障工具的想法。一方面它通过一种声明式的语法创建实例，方便维护者清楚当前的组件正在处理什么样的数据。另一方面，它让数据的校验和保证过程只通过一行代码完成，非常优雅，同时增强了代码的稳定性，让模块与模块之间、前端与后端之间在鲁棒性上解耦。除此之外我还为IPA设计了一个mock方法，使得他不仅能处理数据还能随机生成数据，令模块、端之间在开发和测试层面上也解耦。我认为IPA在保留了js自身灵活性的前提下给予代码一定的数据类型保证。
IPA跟TS是完全不同的：IPA是一个运行时的数据保障、校验和生成工具而非一种真正的语法，声明只是他创建时的一种形式。而TS是开发阶段的一种语言，他的数据类型和声明本质上是IDE和编译器推演出来的。TS可以保证数据在同一套代码内传递时不出错，但在面对运行时其他来源的数据的时候，校验和保障是绕不开的。