前言2020年10月17日，我正式发布了Fantastic-admin，一个基于Vue的中后台管理系统框架。这两年多写了好几篇关于我开发这个框架的心得和技术总结：2020年《我是如何设计后台框架里那些锦上添花的动画效果》2020年《一劳永逸，解决基于 keep-alive 的后台多级路由缓存问题》2021年《在后台框架同质化的今天，我是如何思考并做出差异化的》2022年《神奇！这款 Vue 后台框架居然不用手动配置路由》但是今年半年多了，我几乎消失了，没有发表一篇文章。除了框架的维护和迭代，我也在思考一个问题，那就是：如何做一个管理系统框架？你有手吗？这些都是在“VUE后台管理系统模板”网站上整理的一些制作比较完善的框架，或者有一定的知名度。当然，这只是冰山一角。如果你去Gitee或者Github上搜索“background”、“admin”等关键字，你可以找到更多。前端开发有手的话，貌似写个后台框架就够了？确实，一个标准的后台管理系统，大部分的基本功能都是比较统一的，因为它不像C端产品那样需要高度定制化。通过配置自动生成侧边或头部导航栏；预设多套主题，方便切换；然后写了几个通用的模块，比如用户管理，角色管理，字典管理；最后添加一个登录页面完善下面的权限控制就基本搞定了。实现这些难吗？这并不难。对于前端来说，有手就够了。这也促使很多开发者选择自己编写。有兴趣的朋友写完再推广。如果反馈不错，他们会继续维护。如果没有反馈，可能会逐渐变成自用框架或者弃坑。这也是为什么网上有那么多后台框架的原因，因为不断有新的框架出现，也有大量的框架好几个月，甚至半年多都没有更新。你为谁服务？回到正题，既然要做一个管理系统框架，这个“好”由谁来定义，是客户吗？是的，但不是全部。任何技术框架或者产品最终都要服务于客户和业务，但是作为管理系统框架，我觉得更多的是为开发者服务，让开发者花更少的时间去完成客户或者业务的需求，那才是好的管理系统框架。但是一个可以手写的框架，如果想让开发者选择使用你的而不是自己写，那肯定不是实现上面的功能那么简单，那么如何服务好开发者呢？如何服务？既然立志为开发者服务，就要确定开发者的痛点。好在我自己也是开发人员，在公司内部业务开发中也实际使用过，所以开发中的痛点还是比较容易发现的，无外乎以下几点：通用业务组件少，业务相似模块需要频繁拷贝代码或特殊文件的场景缺乏统一的解决方案。该框架本身提供的API很少，可扩展性差。关于以上几点，我会用几个实际的例子来介绍我是如何为开发者提供服务的，或者说我是如何为自己服务的。.毕竟只要自己用起来舒服，其他开发者的用户体验肯定不会太差。当然，前提是要提高自己的要求，以“人无我有，人有我有”为目标。不太常用的业务组件的痛点相对容易解决，因为市面上各种UI库已经可以满足大部分业务需求，我只是做了一些二次包装或者补充。例如，在ElementPlus的Cascader组件基础上，封装了省、市、街联动组件，方便实现二级、三级、四级选择联动；再一个例子是基于ElementPlus的Upload组件，封装了图片上传组件。提供多图排序、多图预览、文件类型和数量限制等功能：除了ElementPlus的一些二次包装外，我还添加了一些组件，比如趋势标记组件：和搜索面板组件：当然没有上面介绍的只有这些，更多的可以去demo站点查看。我想说的是，公共业务组件对于框架来说是一个比较容易解决的痛点，因为它是肉眼可见的。通过原型或者设计稿，找出一些在多个业务模块中频繁出现的功能，可以考虑是否可以封装成组件，从而减少开发者自己实现的时间。类似的业务模块需要频繁拷贝代码或文件。在后台系统中，必然存在一些界面和操作逻辑高度相似的模块。例如，每个模块中的列表页面都具有搜索功能、数据展示和分页功能。但也不完全一样，比如数据来源、搜索项、列表展示字段等都不同。对于这种场景，我的做法是通过框架预设的目标，通过交互指令生成相应的文件。小到组件、单页模板，大到整个模块（包括列表页、详情页、添加、编辑、删除功能），都可以通过几条指令快速生成，如图下图：当然，开发者也可以根据具体的业务场景，扩展需要生成的模板。特殊场景缺乏统一解决方案的痛点更多体现在框架本身的能力上，我认为这是决定框架好用与否的最大因素。因为上面提到的两个痛点，即使框架不到位，开发者也可以自己想办法解决。如果业务组件少，可以自己写，或者找第三方写的组件；频繁拷贝代码问题不大，开发者可以使用编辑器的代码片段功能，或者其他提高效率的方法。但是在一些特殊场景下，如果框架本身不考虑需求，那么需求只能向框架妥协。毕竟并不是所有的开发者都有能力完整的阅读框架的源码，进行自定义功能的二次开发。说了这么多，你可能不知道有哪些特殊场景。下面是我遇到的几个：大家可以对比一下自己现在使用的框架是否可以满足这些场景，也可以留言分享一些其他的业务。场景一、导航栏按需隐藏导航栏是一个必不可少的功能，尤其是这种分栏式布局导航（主导航+副导航）。既然有栏目导航，就会出现可以隐藏副导航的场景，效果如下：我的做法是用两个独立的配置项组合来实现这个场景，分别在切换主导航时，自动跳转到二级导航中的第一列路由，并在二级导航只有一列时自动隐藏。2.标签页合并标签页的实现是通过路由切换实现的，每访问一个路由，就会添加一个标签页。但是在某些场景下，tab页需要合并，比如从列表页重复打开不同item的编辑页，因为每个编辑页的路由不同，所以会对应生成多个tab页，这时候,希望可以合并所有的编辑页将页面的标签页合并为一个,效果如下:既然有合并编辑页的场景,那么也会有合并列表的场景页面和编辑页合并，比如在同一个模块下，不管是列表页，编辑页，还是其他同属于这个模块的页面，都希望合并成标签页。效果如下：我的做法是提供一个合并规则的配置项，默认不合并。也支持根据路由名合并和根据activeMenu合并，两种合并规则分别对应以上两种场景。具体配置请参考文档介绍。3、按需页面缓存在理解这个场景之前，我们需要知道什么是页面缓存，即当用户离开当前页面，然后返回页面时，离开时的所有状态都需要恢复。这是页面缓存。页面缓存是一个比较常见的场景，一些框架也提供了支持，但是按需缓存，即根据留下和访问的目标页面来判断当前页面是否需要缓存。例如：假设页面A的缓存规则是的，如果你离开访问页面B，就会被缓存，如果你访问其他页面，则不会被缓存；或者只离开访问B页面，不缓存，访问其他页面就需要缓存。如果是上面假设的两种场景，根据大部分框架提供的能力（即在路由配置中提供一个页面是否开启缓存），可能无法满足，因为页面缓存只提供了两种状态，即始终缓存和从不缓存。我的做法是提供两个设置项，分别是cache和noCache。开发者可以为缓存设置true/false值，以满足页面一直缓存或者从不缓存的场景。他们还可以设置路由的名称来实现细粒度的缓存控制。,或者以上面两种场景为例，可以很方便的配置为：//当A页面离开访问B页面时，缓存，其他页面不缓存：'b-route-name'//B页面路由名//页面A只离开和访问页面B不做缓存，访问其他页面需要缓存cache:true,noCache:'b-route-name'//更多关于页面B的路由名，请参考文档。框架本身提供的API少，可扩展性差的痛点根源其实是之前的痛点造成的。因为能力不足，内部可以暴露的方法不多，自然可以提供的API就少了。这里介绍几个简单的API，可以点击预览链接查看实际效果：1.主导航开关importuseMenufrom'@/utils/composables/useMenu'const{switchTo}=useMenu()switchTo(index)预览2、主页面刷新importuseMainPagefrom'@/utils/composables/useMainPage'const{reload}=useMainPage()reload()预览3、主页面最大化importuseMainPagefrom'@/utils/composables/useMainPage'const{最大化}=useMainPage()//status:true/falsemaximize(status)preview4.动态标题有时候，我们需要在某个页面显示一个自定义的标题，而不是meta.title字段。例如，编辑用户页面时，显示当前用户的姓名。importuseSettingsStorefrom'@/store/modules/settings'constsettingsStore=useSettingsStore()onMounted(()=>{settingsStore.setTitle('TestTitle')})preview5.Tabs提供开、关、检等API.预告的结尾写到这里，想跑题了。今年某个时候，突然对“程序员转行，最适合产品经理”这句话有了更多的认同。程序员这一类，我觉得前端开发特别适合转产品经理。因为大部分客户并不关心你用的是什么技术，他们只关心“外观”，比如界面是否好看，操作是否合理，动画是否流畅，大部分日常工作前端开发正在处理这些。当接触到足够多的业务需求，越了解客户想要什么，就能快速找出接下来业务需求中的痛点或者不合理的地方，并提供相对成熟的解决方案，这也是一个产品经理应该具备的能力和经验应该拥有。就像我写的管理系统框架，这一年我并不满足于堆砌新的功能，而是在这个基础上思考如何更好的服务于使用我的框架的开发者，不仅是满足他们的需求，也是让它们用起来舒服是必要的，就像Fantastic-admin官网首页的slogan——“开箱即用，提供舒适的开发体验”。感谢您阅读到这里，希望我在文章中的浅见能给您带来一些启发。
