开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第1天，点击查看活动详情
背景
相信大部分前端同学在每当有一个新页面或者页面上有一个新功能上线的时候，应该都接收到过这样的需求：
PM：我们需要在页面的这个位置添加一个这样的引导
而作为一个成熟的前端，我们也会一边毫不犹豫的回答：这个需求做不了可以；一边在心里默念：真麻烦（不是。然后默默地打开搜索引擎，找到driver.js、intro.js开始执行
npm install xxx
但是，前端的同学们有没有想过，我们是不是可以把对于新功能的引导配置这件事情甩锅的主动权完全交给产运的同学来做呢。甚至可以凭他们自己的需求，来配置不同形式的引导。
前期调研
既然决定进行引导帮助配置化系统的开发，那么肯定不满足于只支持一种类型的引导配置，所以针对业务侧进行了一个常用引导类型的调研。调研过后，对于产运需求中常用的引导类型做一个大概的汇总。
1、单步骤、非高亮引导
2、多步骤/单步骤高亮引导
3、蒙层类引导
感兴趣的可以看一下如何用React实现简易Swiper
4、问答类引导
目前在所有业务场景中，可能较为常用的就是这四种引导方式，用来对用户进行新功能的展示与教学。那么接下来，我们该如何围绕着四种引导方式来进行系统的搭建呢。
整体规划
模块划分
1、配置后台
为用户提供整体的「系统接入」、「页面展示」、「引导配置」、「人员权限管理」、「引导预览」、「引导上线」等基础功能。
同时，这也是引导生成与管理的唯一途径。
2、引导组件（plugin）
组件开发方向
既然需要支持不同类型引导的配置与展示，那么理所当然的需要我们首先拥有不同的引导组件才可以。
这里的选择其实有很多，比如可以选择现有的组件库进行二次封装或者选择不同的组件库中的组件进行组合，但是如果选择了这两种方式都会不可避免的遇到一些小问题。
-
如果用户已经引入了相同组件库的不同版本或者基于相同组件库进行了二次封装的基础上，那么不可避免的会由于版本差异而引起一些报错。
-
又或者我们直接按需引入一些组件库中的组件，但是却不可避免的使我们的引导组件体积变大。
所以，不如我们就按照自己的想法来自己进行组件的开发，这样既满足了我们完全定制化我们自己的功能与样式，又可以在一定程度上避免依赖版本冲突。
技术选型
既然需要自己来搭建自己的组件，那么不可避免需要选择一个合适的框架。
如果我们的目标是单一的React或者Vue的话，那么其实只需要我们做好合适的版本控制，找到合适的peerDependencies限制，就可以。
但是，格局打开友友们！我们已经做了这样一个平台，那么为什么还要局限于框架呢？ 所以这里我们的方向就变成了：
- 使用原生来开发
- 问题是仍然需要手动来操作dom，和当前主流框架的开发习惯相差较大
- Web Component
- 虽然目前三大主流前端框架：Angular、React、Vue 都已经提供官方的 Web Component 转换工具，我们利用这些转换工具，就可以轻松的将各技术栈的 UI 组件，全部包裹成 Web Component，然后当做 HTML 原生组件显示到画布上，可是仍然会或多或少为我们带来一些问题，比如：React组件中class组件的问题
- 选择React与Vue外的第三个小型框架
- 这毫无疑问会增大我们的项目体积，但是具体多少，仍然要视具体的技术选型而定
所以，我选择使用Svelte，无他，唯新鲜尔。
3、引导调度模块（SDK）
功能规划
- 支持管理平台配置时进行元素选择功能，以及所选元素的上报；
- 支持获取当前页面路由与所在应用的唯一标识；
- 获取当前页面已配置且生效的引导条目；
- 页面已生效引导条目的计数与是否展示；
- 调度不同的引导组件，并判断何时展示在什么位置
实现形式
既然需要实现以上功能。那么首先，需要目标应用系统引入我们的调度模块，我们后面都称之为SDK。其次需要进行SDK的初始化后，在路由守卫中调用我们上报路由的方法。
而剩下的事情，就是我们的SDK引入我们的引导组件（plugin） 并进行判断与展示的工作。这里的选择是多样的：
- 对于React，我们可以选择ReactDOM的
render或者createRoot来进行组件挂载； - 对于原生或者其他Web Component，我们可以选择使用原生的
appendChild方法等操作dom； - 对于我亲爱的Svelte，也可以直接使用
new关键字进行挂载
4、server与data
既然我们要支持在不同系统间的配置与引导展示，那么有自己的服务端对我们来说无疑是最优解。
也有使用简单的json配置的形式这种选择，但是个人认为，如果我们需要其他权限控制的时候，这无疑会变成我们的累赘；同样的，当我们不断扩充与完善功能的路上，缺少自己的Server会让我们不能走的更远，大大增加了我们系统的局限性。
技术选型
作为一个前端码仔，Nodejs毫无疑问是我们最好的选择；而在数据量并不大的时候，直接用mysql作为我们唯一的数据存储，后期数据量大的时候再上Redis作缓存。（看看！这okr不就来了吗！）
整体项目框架，我选择了express+NestJs+sequelize+nest/swagger+mysql的一个搭配，进可攻，退可守。（这也是为什么，前面会有这样的一个踩坑记录)
由此，整体的大思路就奠定好了，剩下的就是要进行系统各个模块的详设以及数据库表的设计。
小结
作为整个系统规划的第一个章节，其实本文意在理清整体系统的大方向与模块划分。
无论在进行任何系统的开发过程中，整体规划都是最重要的第一个章节，只有我们先将整体思路理清，将模块划分清楚，接下来才能一个模块一个模块的去做详细设计、去开发、去实现。
凡事要一步一步去完成，心急吃不了热豆腐。 ——非著名前端开发工程师·我
