前端模板仓库
现在在职的这家公司，主要做一些供应链的后台管理系统，比如采购侧的采购管理系统，供应商侧的接单生产系统，质检部门的质检系统等等。为了让整个系统运转更高效，同时避免不同业务逻辑间耦合，我们采用的是每个系统独立开发，独立部署的方案。
对于前端来说，独立开发部署带来很多重复编码的问题。在后台管理系统中，每个功能每个界面都是差不多的。一般一个列表页会包括一个头部的header区，左侧的导航栏，内容区域，如下图：
针对各个系统的这个基础框架，我们采用别的方式进行优化，暂且抛开不谈，后续单独写一篇详细讲讲。我们先来看看内容区域。
其实后台管理系统的页面大家应该都知道基本长什么样，相信每家公司的管理后台其实长的都差不多，这也是为什么像element-ui、ant-design这种UI框架能够长久不衰的原因。
基本上每个系统的列表页面板都长上面这个模样，但是第三方的UI框架只会给我们提供了组成这个页面的每个单独元素，如输入框，按钮，table，切换页码组件等。所以每当来一个列表管理页面的需求，我们要新建一个类似的页面，一般会有两个选择：
- 一个是从旧的代码中复制一份，然后删删改改。
- 第二是重新自己再写一次。
这两种办法都有一些弊端，如果选择copy旧代码，那么很容易就会产生一些未删除干净的旧代码，同时如果你copy的代码本身也是从更老之前的代码copy过来的，那代码会变得一团糟。而如果选择自己写，则会浪费更多的时间与精力，同时也更容易遗漏掉一些过去曾经解决的过的通用性的问题，比如点击下一页时表格需要回到头部。
解决问题
针对这种情况，有两种解决方案：
- 将内容区域写成一个组件。
- 将内容区域写成一个模板。
先对比一下这两者的区别与优劣：
- 如果写成一个组件，我们使用起来会更加便捷，同时更新也更加方便。
- 使用上：理想情况下，我们仅需要配置一份页面的
config object，该组件即可以为我们渲染出大概的layout页面，但自定义的逻辑没有那么方便。 - 更新上：我们只需要发布一个新的版本，然后其他各系统同步升级即可。但是这样做也有一个问题，那就是组件代码会比较混乱，毕竟每个列表页的结构都差不多并不意味着没有差异，而有时为了兼容那小小的差异只能在组件内增加if判断，当这种差异足够多的时候，这个组件维护起来将相当麻烦。
- 如果写成一个模板，将获得更大的自由。
- 使用上：通过集成命令行工具，选择往当前目录注入模板，模板中已经写好基本的页面结构以及相应的基本逻辑等共用代码。
- 更新上: 更新模板只能让后续开发的页面收益，更新前的页面需要逐个手动修改。
模板方案
在更新方面上说，组件的方案更加方便，但是理论上已经完成的功能，一般不会出现需要同步修改的功能点。而其他方面无疑模板更加方便，尤其是组件方式在后期将面临复杂的特异化兼容是使我打消使用组件的念头的主要原因。
下面是模板注入方案的流程图示意：
可以比较清晰的看到，整个流程和架构都是比较简单的。核心只有一个模块，那就是模板注入命令工具，模板仓库只需要新建一个git仓库即可。
上面的架构图更加清晰，整体技术含量并不高，但是能够很好的解决UI高度重复的项目的开发，有效的提升编码效率。
由于整体内容比较简单，实现起来困难也不大，对代码细节就不做讨论了。
不足之处
模板的方案有一个比较明显的缺点，那就是只能对那些比较大的功能集成模板。
假如我有一个输入框是每个系统都有用到的，代码也不多，没有必要抽离出组件，那么这种共用的代码则不适合单独抽离出文件夹作为模板集成。
针对这种不足，我们采用了另外一种方案 – vscode 插件集成，可以直接在vscode中通过插件功能往代码中注入代码碎片。这个方案就先不展开了。
总结
模板注入的方案可能只是业界内众多解决方案中比较粗浅的，简单粗暴的方案。但是这是目前最适合我们的方案，俗话说的好，没有最好的方案，只有最合适的方案。