How to make a management background framework

sequence

On October 17, 2020, I officially releasedFantastic-adminThis Vue-based middle and background management system framework. In the past two years or so, I have written several articles about my experiences and technical summaries in developing this framework:

• 2020 "How do I design those icing on the cake animation effects in the background frame"
• 2020 "Once and for all, solve the background multi-level routing cache problem based on keep-alive"
• 2021 "Today, when the background framework is homogeneous, how do I think and make differences"
• 2022 "magic! This Vue background framework does not need to manually configure routing"

But this year, for more than half a year, I almost disappeared and did not produce a single article. In addition to maintaining and iterating the framework, I am also thinking about a question, that is:

How to make a management system framework?

Do you have hands?

This is"VUE background management system template"Some of the frameworks on the website are relatively well done, or have a certain reputation. Of course, this is just the tip of the iceberg. If you go to Gitee or Github to search for keywords such as "backstage" and "admin", you can find more. It seems that writing a background framework is enough for front-end development if you have hands?

Indeed, most of the basic functions of a standard background management system are relatively unified, because it does not require high customization like C-end products. A side or header navigation bar is automatically generated through configuration; several sets of themes are preset for easy switching; then several general modules are written, such as user management, role management, and dictionary management; finally, a login page is added to improve the following Authority control is basically done.

Is it difficult to achieve these? It's not difficult. For the front end, it's enough to have hands. This also prompts many developers to choose to write by themselves. Those who are interested will promote it after writing. If the feedback is good, they will continue to maintain it. If there is no feedback, it may gradually become a self-use framework or abandon the pit.

This is why there are so many background frameworks on the Internet, because there are new frameworks appearing all the time, and there are also a large number of frameworks that have not been updated for several months, or even more than half a year .

Who do you serve?

Back to the topic, since we want to make a management system framework, who will define this " good ", is it the customer? Yes, but not all.

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

但是一个有手就能写的框架，要让开发者选择使用你的，而不是自己去写，想必肯定不是实现上面那些功能那么简单，那要如何服务好开发者呢？

如何服务？

既然确定是给开发者服务，那就需要确定开发者的痛点。好在我本身也是开发者，在公司内部业务开发中就有实际在使用，所以开发中的痛点还是比较好找的，无非以下几点：

• 通用业务组件少
• 相似业务模块需要频繁拷贝代码或文件
• 特殊场景缺少统一解决方案
• 框架本身提供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. Tab related

APIs such as open, close, and check are provided.

preview

end

Written here, I want to digress a bit.

Sometime this year, I suddenly had more recognition for the phrase "programmers change careers, the most suitable product manager". In the category of programmers, I think front-end development is especially suitable for switching to product managers.

Because most customers don't care what technology you use, they only care about the "appearance", such as whether the interface is good-looking, whether the operation is reasonable, and whether the animation is smooth, and most of the daily work of front-end development is dealing with these. When exposed to enough business requirements, the more you understand what customers want, you can quickly find out the pain points or unreasonable places in the next business requirements, and provide a relatively mature solution, which is also The ability and experience that a product manager should possess.

Just like the management system framework I wrote, this year I am not satisfied with piling up new features, but on this basis, I think about how to better serve the developers who use my framework, not only to meet their needs, And make them comfortable to use, asFantastic-adminThe slogan on the homepage of the official website - " Out of the box, providing a comfortable development experience ".

Thank you for reading here, I hope my humble opinion in the article can bring you some inspiration.