관리 배경 프레임워크를 만드는 방법

순서

2020년 10월 17일 정식 발매환상적인 관리자이 Vue 기반 중간 및 백그라운드 관리 시스템 프레임워크입니다. 지난 2년여 동안 저는 이 프레임워크를 개발하면서 경험한 내용과 기술적 요약에 대해 여러 기사를 썼습니다.

• 2020 "배경 프레임에서 케이크 애니메이션 효과의 아이싱을 어떻게 디자인합니까?"
• 2020 "단번에 연결 유지를 기반으로 백그라운드 다중 레벨 라우팅 캐시 문제를 해결합니다."
• 2021년"배경의 틀이 균질한 오늘날, 나는 어떻게 생각하고 차이를 만드는가"
• 2022년 "마법! 이 Vue 백그라운드 프레임워크는 라우팅을 수동으로 구성할 필요가 없습니다."

그런데 올해는 반년 넘게 거의 자취를 감췄고 단 한 편의 기사도 내지 못했다. 프레임워크를 유지하고 반복하는 것 외에도 다음과 같은 질문에 대해 생각하고 있습니다.

관리 시스템 프레임워크를 만드는 방법은 무엇입니까?

손이 있습니까?

이것은"VUE 백그라운드 관리 시스템 템플릿"웹사이트에 있는 프레임워크 중 일부는 비교적 잘 만들어졌거나, 어느 정도 평판이 나 있습니다. 물론 이것은 빙산의 일각에 불과합니다. Gitee나 Github에 가서 "backstage", "admin"과 같은 키워드로 검색하면 ", 더 찾아보실 수 있습니다. 프론트엔드 개발은 백그라운드 프레임워크를 작성하는 것만으로도 손이 있다면 충분할 것 같은데요?

실제로 표준 백그라운드 관리 시스템의 대부분의 기본 기능은 C-end 제품과 같이 높은 사용자 정의가 필요하지 않기 때문에 상대적으로 통합되어 있습니다. 구성을 통해 사이드 또는 헤더 내비게이션 바가 자동으로 생성되고, 쉽게 전환할 수 있도록 여러 테마 세트가 미리 설정되어 있으며, 사용자 관리, 역할 관리 및 사전 관리와 같은 여러 일반 모듈이 작성되고, 마지막으로 로그인 페이지가 추가되어 개선되었습니다. 다음 권한 제어가 기본적으로 수행됩니다.

이것들을 달성하기가 어렵습니까? 어렵지 않아요 프론트엔드는 손만 있으면 충분합니다. 이것은 또한 많은 개발자가 스스로 작성하도록 유도합니다.관심이 있는 사람은 작성 후 홍보할 것입니다.피드백이 좋으면 계속 유지하고 피드백이 없으면 점차 자체 사용 프레임워크가 될 수 있습니다. 또는 구덩이를 버리십시오.

이래서 인터넷에 배경 프레임워크가 너무 많은데, 항상 새로운 프레임워크가 등장하고 있고, 몇 달, 심지어는 반년 이상 업데이트가 안 된 프레임워크도 많이 있기 때문입니다 .

당신은 누구를 섬기는가?

주제로 돌아가서, 우리는 관리 시스템 프레임워크를 만들고 싶기 때문에 이 " 좋음 "을 정의할 사람은 고객입니까? 예, 하지만 전부는 아닙니다.

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

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

如何服务？

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

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

시사

끝

여기에 작성, 나는 약간 탈선하고 싶습니다.

올해 언젠가 나는 "프로그래머가 경력을 바꾸는 가장 적합한 제품 관리자"라는 문구에 대해 갑자기 더 많은 인식을 갖게 되었습니다. 프로그래머의 범주에서 프론트 엔드 개발은 특히 제품 관리자로 전환하는 데 적합하다고 생각합니다.

대부분의 고객은 어떤 기술을 사용하든 상관하지 않기 때문에 인터페이스가 잘 생겼는지, 조작이 합리적인지, 애니메이션이 부드러운지 등 "외관"만 중요하게 생각하며 대부분의 일상 업무는 프런트엔드 개발팀에서 이러한 문제를 다루고 있습니다. 충분한 비즈니스 요구사항에 노출되었을 때 고객이 원하는 것을 더 잘 이해하고 다음 비즈니스 요구사항에서 Pain Point나 무리한 부분을 빠르게 찾아내어 상대적으로 성숙한 솔루션을 제공할 수 있습니다. 소유해야 합니다.

제가 작성한 관리 시스템 프레임워크처럼 올해는 새로운 기능을 쌓아 올리는 것에 만족하지 않고 이를 바탕으로 제 프레임워크를 사용하는 개발자들의 니즈를 충족시킬 뿐만 아니라, 와 같이 사용하기 편하다환상적인 관리자공식 웹 사이트 홈페이지의 슬로건 - " 즉시 사용 가능, 편안한 개발 경험 제공 ".

여기를 읽어주셔서 감사합니다. 이 기사의 겸손한 의견이 여러분에게 영감을 줄 수 있기를 바랍니다.