传统请求库的痛点

传统请求库（如 axios或浏览器的 fetch API）专注于请求本身，这一点上它们的职责其实很专注，在请求这一功能上已经做得挺不错了；不过实际业务和项目中跟请求相关的一些常用的功能，这种请求库通常不会提供，虽说我们可以根据自身业务需求自己抽象出一些常用的功能，形成自己的请求策略库或者类似的工具，但偷懒是人之本性🙈（其实也是为了避免重复造轮子）。

为什么要使用状态机？

如果一个交互只简单地涉及到布尔状态或者是多选一，这类只通过一个状态变量即可确认当前状态的场景确实没必要使用状态机，毕竟无非只是使用if/switch就能简单切换状态。如果一个交互逻辑复杂到需要使用多个状态变量来共同确认具体的状态节点，那么在涉及到状态切换时，对于判断当前具体状态节点的相关工作量就会呈现指数级的增长；

关于 ts-morph

ts-morph是一层对TS编译API的封装^[1]，使得操作AST变得简单高效起来，且提供了开箱即用的项目级编译支持，因而可以很快的构建自己的TS项目编译上下文；除此以外，ts-morph基本上保留了所有原始TS AST节点类型的访问，因此如果有啥TS编译API目前还没封装暴露，可以完全退回到原始API进行相应的使用^[2]，所以不必担心ts-morph会有过度封装而导致无法使用一些底层API。

关于 TS 编译 API

顾名思义，就是用于TS编译的，通常用于获取和编辑TS AST（抽象语法树）信息，直接通过typescript这个包提供；关于TS编译流程、AST数据结构以及常用的编译API就不再赘述，更多可以参考——TS AST转换实例：从类型声明生成初始化数据 | snowdream；

关于 AST

简言之，AST可以获取到源码的所有（合法）语法信息，同时构造（或修改）AST也能得到对应的代码，可以理解为AST结构与代码之间是一种双射关系。

AST的用处很多，常见的language server都会借助AST信息来进行各种语言DX功能开发（如：自动补全、类型显示、语法诊断、代码格式化等等）；同时，由于AST结构可以转换为代码，所以修改AST结构可以从语法层面进行代码的修改（这比直接从文本替换来说效率高多了），因此AST也被来扩展语法的使用（前提是合法的语法，即从一种合法的语法转为另一种合法的语法，以便提高开发效率）；

P.s：如果修改AST已经不能满足你的语法需求了，那么是时候考虑进入诸如TC39这种语言标准化组织或者开辟自己的语言了😁。

业务背景

在前端对透视表数据导出为excel进行下载，透视表数据最高可到百万个单元格以上，因此在主线程内对大量数据进行excel导出时不可避免的会对主线程进行阻塞，而主线程阻塞对于用户感知来说就是页面卡顿；

显然，这种业务是一种典型的CPU密集型任务，如果可以放在主线程以外的线程进行执行那么就可以有效的避免对主线程的阻塞了；Worker 正是为此而生，通过创建worker来新建线程，就可以有效的分担主线程的压力；

关于storybook

storybook是什么？

Storybook is a tool for UI development. It makes development faster and easier by isolating components. This allows you to work on one component at a time. You can develop entire UIs without needing to start up a complex dev stack, force certain data into your database, or navigate around your application.

storybook可以干什么？

• 根据组件注释生成对应的文档信息
• 根据组件prop类型自动生成对应类型的交互控制
• 可以编写组件交互示例
• 可以进行组件测试
• etc

概览