为什么要使用状态机？

如果一个交互只简单地涉及到布尔状态或者是多选一，这类只通过一个状态变量即可确认当前状态的场景确实没必要使用状态机，毕竟无非只是使用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

概览

整体设计

这是一套比较激进的可视化搭建方案（激进体现在适用场景和技术栈的选择上），核心思想就是极致的内聚；因此可以看到除了必要的组件配置，其他所有相关的配置都砍掉了，理由就是这些配置完全可以通过内聚使其成为内部参数，而减少不必要的参数暴露（这一点可以参照现有的一些比较流行的可视化搭建方案，它们都尽可能实现对组件框架的所有语法的完全映射，以便达到最大的自由度）；从可视化搭建业务的角度来说，一般就是封装的程度越高，其自由度越低，而搭建效率就越高^[1]；而这套设计就是为了提高业务搭建效率，所以自然就倾向于内聚；

预期适用场景

• 面向人群：前端编程人员；
• 预期解决的问题：减少花在拼接组件的过程中写胶水代码的时间，更加直接直观地去搭积木；
• 内聚：业务和组件/代码区块的内聚程度越高，复用和可视化搭建的效率也就越高；
• 面向项目：Vue3（≥3.2，用于支持setup模式） + TS；