経営背景フレームワークの作り方

順序

2020年10月17日、正式にリリースしましたファンタスティック管理者この Vue ベースの中間およびバックグラウンド管理システム フレームワーク。過去 2 年ほどの間に、このフレームワークを開発する際の経験と技術的な概要についていくつかの記事を書きました。

• 2020」背景フレームのアイシング アニメーション効果をデザインするにはどうすればよいですか"
• 2020」キープアライブに基づいてバックグラウンドのマルチレベル ルーティング キャッシュの問題を解決します。"
• 2021年」背景の枠組みが同質である今日、私はどのように考え、違いを生み出すのか"
• 2022年」魔法！この Vue バックグラウンド フレームワークでは、ルーティングを手動で構成する必要はありません"

しかし、今年は半年以上、ほぼ姿を消し、記事を一つも出していませんでした。フレームワークの維持と反復に加えて、次のような質問についても考えています。

マネジメントシステムのフレームワークを作るには？

手はありますか？

これは"VUE バックグラウンド管理システム テンプレート「ウェブサイトのフレームワークの中には、比較的よくできていたり、一定の評判を得ているものもあります。もちろん、これは氷山の一角にすぎません。Gitee や Github にアクセスして、「backstage」や「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 が提供されています。

プレビュー

終わり

ここに書いて、少し脱線したい。

今年のある時期、突然「プログラマーが転職、最適なプロダクト マネージャー」という言葉が認知されるようになりました。プログラマーのカテゴリーでは、特にフロントエンド開発がプロダクトマネージャーへの転職に適していると思います。

ほとんどのお客様は、どのような技術を使用しているかは気にせず、インターフェイスがかっこいいかどうか、操作が合理的かどうか、アニメーションがスムーズかどうかなど、「見た目」だけを気にし、日常業務のほとんどをフロントエンド開発の現場はこれらに対応しています。十分なビジネス要件にさらされると、顧客が何を望んでいるかを理解するほど、次のビジネス要件での問題点や不合理な場所をすばやく見つけ出し、比較的成熟したソリューションを提供できます。これは、プロダクト マネージャーとしての能力と経験です。持つべきです。

私が書いた管理システムのフレームワークと同じように、今年は新しい機能を積み上げることに満足していませんが、これに基づいて、私のフレームワークを使用する開発者のニーズを満たすだけでなく、より良いサービスを提供する方法を考えています。など、快適に使用できますファンタスティック管理者公式ウェブサイトのホームページのスローガン - 「すぐに使える、快適な開発体験を提供する」。

ここを読んでくれてありがとう。この記事の謙虚な意見があなたにインスピレーションをもたらすことを願っています。