--- theme: vuepress --- ## 前言去年年底，我写了一篇《[如何做好一款管理后台框架](https://juejin.cn/post/7181256996443095099)》的文章，这是我对开发 [Fantastic-admin](https://fantastic-admin.github.io/) 这款基于 Vue 的中后台管理系统框架两年多时间的一个思考与总结。很意外这么一篇标题平平无奇的文章能收获 30k 的浏览以及 600 多个收藏，似乎大家对这种非干货的文章也挺感兴趣。于是在这个三年的时间点上（没错，也就是1100天），我打算继续出来和大家唠唠，这一年我又做了些什么事，或者说，**如何把一款好的后台框架变得通用？** 题外话：如果你对我以前的文章感兴趣，可以点我头像进入主页查看；如果你期待我以后的文章，也可以点个关注。 ## 痛点因为 [Fantastic-admin](https://fantastic-admin.github.io/) 是基于 Element Plus 这款 UI 组件库进行开发的，于是今年我陆陆续续被问到一些问题： * 以后会有 Ant Design Vue 版本么？会有 Naive UI 版本么？会有 …… 版本么？ * 我们公司/团队有一套内部的 UI 组件库，可以在 Fantastic-admin 里使用么？会和 Element Plus 有冲突么？ * 我们有一些老项目希望迁移到 Fantastic-admin 上来，但 UI 组件库用的不是 Element Plus ，有什么办法么？ * … 类似的问题一多，我也在思考一个问题：**我的这款框架是不是被 Element Plus 绑架了**？如果开发者在做技术选型的时候，因为 UI 组件库不符合预期，而将我的框架筛掉，这是我不希望看到的结果。基于这个潜在隐患，我开始计划对框架进行转型。 ## 方案 ### 方案一既然开发者对 UI 组件库有各自的偏好，我又想拉拢这部分开发者，那**是不是多出几套不同 UI 组件库版本的就可以了呢**？没错，这是我最开始冒出来的念头。我参考了一些同类产品的做法，尽管它们把不同 UI 组件库版本做得很像，但在使用体验过程中，还是会带来操作上的割裂感。并且因为无法抹平不同 UI 组件库在 API 上的差异，导致在框架功能上，不同版本之间也会有一些差异。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/24d7a0870eff481f8e6fde56034e04ec~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=5748\&h=3916\&s=1528258\&e=png\&b=e0e0e0) 你可以分别对比左右或者上下两张图，包括左侧导航栏的样式、导航收起/展开按钮的位置、右侧项目配置中提供的功能等，都能明显发现它们的差异。虽然这可能不是什么大问题，但我认为**视觉风格上的统一是能帮助产品提高识别度的**。就比如上面 4 款基于不同 UI 组件库开发的后台框架，虽然它们属于同一个产品，但如果我不告诉你，你未必能通过图片确定它们师出同门。其次就是后台框架提供的功能不统一，这里面有一定的原因是因为 UI 组件库导致的。试想一个场景，如果你要从 Element Plus 版本的后台，迁移到 Ant Design Vue 版本的后台，框架的配置文件是否能原封不动的复制过去？如果导航(路由)数据是后端返回的，数据结构能否保持完全一致，后端无需做任何修改？因为不同 UI 组件库对菜单组件的使用方式是完全不同的，比如 Element Plus 是需要手动拼装的，而 Naive UI 则是数据驱动的，只需要传入一个树形结构的数据给组件即可。如果数据结构无法保证一致，就会增加迁移和学习的成本。最后就是我的一点私心，因为多一个 UI 组件库的版本，势必会占据我更多的业余时间，如果同时维护 4、5 个版本，那我大概下班后的所有时间都要投入到其中，并且如果未来又有新的 UI 组件库成为流行，那就又多一个版本的维护，这并不是一个可持续发展的方案。 ### 方案二既然上一个方案不符合我的期望，于是我开始思考，**框架本身能不能不依赖这些 UI 组件库**？如果框架本身不依赖于三方的 UI 组件库，那开发者不就可以根据需要自行引入想要的组件库了么。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ce7f2a40541649c9ad20788705f8ce91~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=2810\&h=1471\&s=174206\&e=png\&b=dcdada) 就如上图，主/次导航和顶栏是属于框架的部分，而这部分其实并没有用到太多 UI 组件库提供的组件，以 Element Plus 举例，我统计了一下目前 [Fantastic-admin](https://fantastic-admin.github.io/) 用到的组件： * Menu 菜单（主/次导航） * Breadcrumb 面包屑（顶栏） * Popover 气泡卡片（顶栏右侧的工具栏） * Dropdown 下拉菜单（顶栏右侧的工具栏） * Drawer 抽屉（应用配置） * Message 消息提示 * Button 按钮 * Input 输入框 * Radio 单选框 * Select 选择器 * Switch 开关 * …（等等表单类组件）可以看到，虽然抽屉组件里用了很多表单类的组件，但这部分组件都是在应用配置里使用的，而应用配置这个模块，主要是方便在线测试框架提供的各种功能，在实际业务开发中，是完全不需要这个模块的。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3a02632df73c4ca1ae87d9c75907e167~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=3596\&h=2024\&s=1130025\&e=png\&b=7e7e7e) 所以初步算下来，后台框架真正依赖于 Element Plus 实现的组件就只有 4 个： * Menu 菜单 * Breadcrumb 面包屑 * Popover 气泡卡片 * Dropdown 下拉菜单那我为什么不找一些独立的第三方插件替代呢？是的，这是我第二个方案，就是**找一些独立的插件替换 UI 组件库中的组件**。但问题也立马迎面而来，就是偌大一个 Github ，居然找不到符合我需求和审美的插件。比如菜单插件，我希望它和 Element Plus 里的菜单组件在功能上没有太大差异，支持水平/垂直模式、支持折叠收起、支持设置默认激活菜单、支持默认展开等。比如面包屑插件，或许是因为这个插件功能太简单，并且大部分 UI 组件库都有提供，在 Github 能搜到独立的面包屑插件很少，搜到的也基本上是 N 年前的上传的，既没有人维护，风格样式也很丑。这个方案似乎也行不通……吗？ ### 方案三虽然方案二在实施的第一步就扑街了，但有一点思路还是正确的，就是**让框架本身不依赖于三方 UI 组件库**。既然网上搜不到合适的插件，那我为什么不自己写一个呢。比如面包屑，这是一个很简单的功能，任何前端初学者应该都可以写一个面包屑组件。而气泡卡片和下拉菜单我没有计划自己写，因为找到了一个还不错的插件 [Floating Vue](https://floating-vue.starpad.dev/)，它由 Vue 团队核心人员开发并维护，并且最重要的是它支持自定义样式，意味着我可以将它魔改成想要的样子，尽可能和我的框架在视觉风格上保持统一。最后一个比较难啃的骨头就是菜单，因为找不到合适的替代品，自己写的话又比较有挑战，虽然我有一点实现思路，但不多。当然最终还是决定自己写一个，因为觉得三方 UI 组件库这么多，实在写不出来我就去读他们源码，总不能每一个源码我都读不懂吧。这 4 个组件的替换方案确定后，剩下就是抽屉组件和它里面的一些表单组件了，这些要怎么解决呢？这会我想到了 [Headless UI](https://headlessui.com/) ，它是完全无样式的 UI 组件库，通过与 Tailwind CSS / UnoCSS 集成使用，可以快速构建出属于自己风格的组件。但是 Headless UI 提供的组件非常有限，并不能覆盖我需要的表单组件。不过它的设计给了我启发。表单组件我并不需要非常复杂的功能，原生的表单控件其实就能满足我的使用需求，只是原生的样式比较丑，和我想要的风格不统一，那我只需要给他们定制一套统一的风格就可以了，也就写一套原子化的 CSS 样式。于是，方案敲定，开始实操。 ## 实操 **我决定从易到难开始处理，因为这样在初期能快速看到进度推进，也避免一上来就被一个菜单功能卡住好几天，甚至十几天都没有进展，打击到自己的信心。** ### 1. 面包屑和预期一样，并没有什么难度，很轻松就实现了。只不过目前还是保持和 Element Plus 一样的使用方式，就是需要手动拼装，后期计划改成数据驱动的使用方式。 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/db527b26e04e420b959332039927bbef~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=1100\&h=200\&s=30135\&e=png\&b=fefefe) ### 2. 气泡卡片 & 下拉菜单这部分参考了 [nuxt/devtools](https://github.com/nuxt/devtools) 中 [Floating Vue](https://floating-vue.starpad.dev/) 的自定义样式，以及 [nuxt/ui](https://github.com/nuxt/ui) 中下拉菜单的样式风格，最终形成了我自己满意的风格 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3d13e4d1ced140d8b4f433d1d3a01d6c~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=694\&h=1236\&s=100206\&e=png\&a=1\&b=fbfbfb) ### 3. 抽屉使用了 Headless UI 中的 [Dialog](https://headlessui.com/vue/dialog) 组件，因为它和抽屉组件有相同的交互方式，它们都是在遮罩层上展示内容，只不过 Dialog 更多时候是居中展示，而抽屉则是在左右两侧展示。其次在使用过程中，发现 Headless UI 中的 [Transition](https://headlessui.com/vue/transition) 组件是一个惊喜。虽然 Vue 本身就有提供 `` 组件用于处理过渡动画，但有一个场景会比较难处理，官方的描述是： > This technique is needed when you want to coordinate different animations for different child elements – for example, fading in a Dialog's backdrop, while at the same time sliding in the contents of the Dialog from one side of the screen. > 当您要为不同的子元素协调不同的动画时，就需要使用这种技术，例如，在淡入对话框背景的同时，从屏幕的一侧滑入对话框的内容。这说的不就是抽屉组件么？于是按照官方的示例，修改了整体风格，最终效果也就出来了。 ![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a60d2d1f52b2404cbb07999420781921~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=1260\&h=676\&s=884028\&e=gif\&f=46\&b=f3f3f3) ### 4. 表单组件之前的计划是修改原生表单控件的样式，但在开发过程中发现会有一定的局限性。比如 `