关于前端:如何做好一款管理后台框架

序

2020 年 10 月 17 日，我正式公布了 Fantastic-admin 这款基于 Vue 的中后盾管理系统框架。在这两年多的工夫里，我陆续写了几篇我在开发这套框架中的一些心得和技术总结：

• 2020 年《我是如何设计后盾框架里那些精益求精的动画成果》
• 2020 年《一劳永逸，解决基于 keep-alive 的后盾多级路由缓存问题》
• 2021 年《在后盾框架同质化的明天，我是如何思考并做出差异化的》
• 2022 年《神奇！这款 Vue 后盾框架竟然不必手动配置路由》

然而往年，有大半年的工夫我简直匿影藏形，没有产出一篇文章。除了始终在保护和迭代框架外，我也在思考一个问题，那就是：

如何能力做好一款管理系统框架？

有手就行？

这是“VUE 后盾管理系统模板”网站上整顿的一些绝对做得比拟杰出，或者说有肯定知名度的框架。当然这也只是冰山一角，如果去 Gitee 或者 Github 搜寻“后盾”“admin”等关键词，你还能发现更多。仿佛写一个后盾框架对前端开发来说，有手就行？

的确，一个规范的后盾管理系统，大部分根底性能是绝对对立的，因为它不像 C 端产品须要高度定制化。一个侧边或者头部导航栏，通过配置主动生成；再预设几套主题，不便切换；而后写几个通用模块，比方用户治理、角色治理、字典治理；最初再加个登录页，欠缺下权限管制，根本就功败垂成了。

要实现这些难么？不难，对前端来说，的确有手就行。这也促使很多开发者抉择本人写，写完有兴致的还会推广宣传一番，反馈好就持续保护，没啥反馈可能就逐步变成了一个自用框架或者弃坑了。

这也是为什么网上有如此多后盾框架的起因，因为始终有新的框架呈现，也有大量框架曾经几个月，甚至超过半年工夫未更新，颇有一种「你方唱罢我退场」感觉。

给谁服务？

回归到主题，既然要做好一款管理系统框架，那谁来定义这个“好”呢，是客户吗？是，但又不全是。

任何一款技术框架或产品，最终肯定是服务于客户、服务于业务的，但做为一款管理系统框架，我认为更多还是服务于开发者，让开发者用更少的工夫，实现客户或业务需要，那就是一款好的管理系统框架。

然而一个有手就能写的框架，要让开发者抉择应用你的，而不是本人去写，想必必定不是实现下面那些性能那么简略，那要如何服务好开发者呢？

如何服务？

既然确定是给开发者服务，那就须要确定开发者的痛点。好在我自身也是开发者，在公司外部业务开发中就有理论在应用，所以开发中的痛点还是比拟好找的，无非以下几点：

• 通用业务组件少
• 类似业务模块须要频繁拷贝代码或文件
• 非凡场景短少对立解决方案
• 框架自身提供 API 少，扩展性差

针对以上整顿的几点，上面我会用几个理论的例子来介绍下我是怎么为开发者提供服务的，或者说我是怎么服务本人的。

毕竟只有我本人感觉用得爽了，其余开发者的应用体验也必定不会太差，当然前提是拔高自我要求，以“人无我有，人有我优”做为指标。

通用业务组件少

这个痛点是绝对比拟容易解决的，因为市面上各种 UI 库曾经能满足大部分的业务应用需要了，我只是做了一些二次封装或补充。

比方在 Element Plus 的 Cascader 组件根底上，封装了 省市区街道联动 组件，不便实现二级、三级和四级的抉择联动：

再比方在 Element Plus 的 Upload 组件根底上，封装了 图片上传 组件，提供了多图排序、多图预览、文件类型和数量限度等个性：

除了对 Element Plus 进行一些二次封装外，我还补充了一些组件，比方 趋势标记 组件：

还有 搜寻面板 组件：

当然不仅仅是下面介绍的这些，更多能够拜访 演示站 进行查看。

我想说的就是，通用业务组件，是框架比拟容易解决的一个痛点，因为它肉眼可见，通过原型图或设计稿，找出一些频繁在多个业务模块中呈现的性能，就能够思考是否能够封装成组件，从而缩小开发者本人去实现的工夫。

类似业务模块须要频繁拷贝代码或文件

后盾零碎里，肯定有一些模块在界面、操作逻辑上是高度类似的，比方各个模块里的列表页，它们都有搜寻性能、数据展现、分页性能。但又不齐全一样，比方数据源、搜寻项、列表展现字段都不一样。

对于这种场景，我的做法是通过框架预设的指标，搭配交互式的指令去生成对应的文件。小到组件和单页面的模板，大到整个模块（蕴含列表页、详情页、新增、编辑、删除性能一应俱全），都能够通过几个指令疾速生成，如下图：

当然开发者也能够依据具体业务场景，自行扩大须要生成的模板。

非凡场景短少对立解决方案

这一块的痛点，更多体现在框架本身的能力上，也是我认为决定框架是否好用中最大的因素。

因为下面提到了两个痛点，即便框架做得不到位，开发者也能本人想方法去解决。业务组件少能够本人写，或者找三方他人写好的组件；频繁拷贝代码也不是多大的问题，开发者能够借助编辑器的代码片段性能，或者其余形式去提高效率。

但一些略微非凡的场景下，如果框架自身没有思考到，那需要只能向框架斗争，毕竟不是所有开发者都有能力去残缺浏览框架源码，并进行二次开发定制性能。

说了这么多，可能大家还不分明到底有哪些非凡场景，这里我举几个我遇到的：

大家能够比照下当初正在应用的框架是否能满足这些场景下应用，也能够留言分享一些其余业务场景

1、导航栏按需暗藏

导航栏是个必备的性能，尤其是这种分栏布局的导航（主导航 + 次导航），既然有分栏导航，那就会有次导航是否暗藏的场景，成果如下：

我的做法是通过两个独立的配置项组合应用，实现了这一场景，别离是 切换主导航时主动跳转到次导航里第一个栏目路由 和 次导航只有一个栏目时自动隐藏。

2、标签页合并

标签页的实现是通过路由切换来实现的，每拜访一个路由就会减少一个标签页。

但有的场景须要对标签页进行合并，比方重复从列表页关上不同条目标编辑页，因为每个编辑页的路由不同，所以对应也会生成多个标签页，这时候就心愿能将所有编辑页的标签页合并成一个，成果如下：

既然有编辑页合并的场景，那也会有列表页和编辑页合并的场景，比方同个模块下，不论是列表页，还是编辑页，或者其余同属于该模块下的页面，都心愿能合并成一个标签页，成果如下：

这块我的做法是提供了一个合并规定的配置项，默认不合并，同时反对 依据路由 name 进行合并 和 依据 activeMenu 进行合并 两条合并规定，别离对应了下面两个场景，具体配置可参考文档介绍。

3、页面按需缓存

在理解这个场景前，咱们先要晓得什么是页面缓存，就是当用户来到以后页面后，再返回该页面，须要还原来到时的所有状态，这就是页面缓存。

页面缓存是一个比拟常见的场景，局部框架也提供了反对，但按需缓存，也就是依据来到并拜访的指标页面，判断是否须要对当前页进行缓存，举个例子：

假如 A 页面的缓存规定是，如果来到并拜访 B 页面则进行缓存，拜访其余页面则不缓存；或者只有来到并拜访 B 页面不缓存，拜访其余页面则都须要缓存。

如果是下面假如的这两个场景，依照大部分框架提供的能力（即在路由配置里提供一个页面是否开启缓存的设置项），可能就不肯定能满足了，因为页面缓存只提供了两种状态，即始终缓存和始终不缓存。

而我的做法是别离提供了 cache 和 noCache 两个设置项，开发者能够对 cache 设置 true/false 值以满足页面始终缓存或始终不缓存的场景，也能够设置路由的 name，实现精细化缓存管制，还是拿下面两个场景举例，就能够轻松配置成：

// A 页面来到并拜访 B 页面则进行缓存，拜访其余页面则不缓存
cache: 'b-route-name' // B 页面路由 name

// A 页面只有来到并拜访 B 页面不缓存，拜访其余页面则都须要缓存
cache: true,
noCache: 'b-route-name'  // B 页面路由 name

更多细节可参考文档介绍。

框架自身提供 API 少，扩展性差

这一痛点的根本原因其实是上一个痛点造成的，因为能力少，所以能暴露出的外部办法就不多，所以能提供的 API 天然也就少了。

这里我就介绍几个简略的 API，大家能够点预览链接看实际效果：

1、主导航切换

import useMenu from '@/utils/composables/useMenu'

const {switchTo} = useMenu()

switchTo(index)

预览

2、主页面刷新

import useMainPage from '@/utils/composables/useMainPage'

const {reload} = useMainPage()

reload()

预览

3、主页面最大化

import useMainPage from '@/utils/composables/useMainPage'

const {maximize} = useMainPage()

// status: true / false
maximize(status)

预览

4、动静题目

有时候，咱们须要在某个页面显示自定义的题目，而不是 meta.title 字段，比方在编辑用户的页面，显示以后用户的名称。

import useSettingsStore from '@/store/modules/settings'
const settingsStore = useSettingsStore()

onMounted(() => {settingsStore.setTitle('测试题目')
})

预览

5、标签页相干

提供了关上、敞开、测验等 API。

预览

结尾

写到这里，想扯点题外话。

往年的某个工夫，我忽然对“程序员转行，最适宜转产品经理”这句话有了更多认同感。而在程序员这个大类里，我认为前端开发是其中尤为适宜转产品经理的。

因为大部分客户不在乎你用什么技术，他们只看中“表面”，像界面是否难看，操作是否正当，动效是否晦涩，而前端开发大部分日常工作内容就是在和这些打交道。当接触了足够多的业务需要，就越理解客户想要的是什么，就能在下个业务需要里疾速找出其中的痛点或者不合理的中央，并提供一个绝对成熟的解决方案，这同时也是一个产品经理所应该具备的能力和教训。

就像我写的这款管理系统框架，这一年我不满足于堆砌新个性，而是在此基础上思考怎么更好的去服务应用我这套框架的开发者，不仅满足他们的需要，还要让他们用得舒服，正如 Fantastic-admin 官网首页的标语——“开箱即用，提供舒服开发体验”。

感激大家浏览到这里，心愿文中我的高见能给大家带来一些启发。