secuencia

El 17 de octubre de 2020, lancé oficialmentefantástico-administradorEste marco de sistema de gestión de fondo y medio basado en Vue. En los últimos dos años más o menos, he escrito varios artículos sobre mis experiencias y resúmenes técnicos en el desarrollo de este marco:

2020 "¿Cómo diseño esos efectos de animación de guinda del pastel en el marco de fondo?"
2020 "De una vez por todas, resuelva el problema de caché de enrutamiento de varios niveles en segundo plano basado en keep-alive"
2021 "Hoy, cuando el marco de fondo es homogéneo, ¿cómo pienso y hago diferencias?"
2022 "¡magia! Este marco de fondo de Vue no necesita configurar manualmente el enrutamiento"

Pero este año, durante más de medio año, casi desaparecí y no produje un solo artículo. Además de mantener e iterar el marco, también estoy pensando en una pregunta, es decir:

¿Cómo hacer un marco de sistema de gestión?

¿Tienes manos?

Esto es"Plantilla de sistema de gestión de fondo VUE"Algunos de los marcos en el sitio web están relativamente bien hechos o tienen cierta reputación. Por supuesto, esto es solo la punta del iceberg. Si vas a Gitee o Github para buscar palabras clave como "backstage" y "admin ", puede encontrar más. ¿Parece que escribir un marco de fondo es suficiente para el desarrollo de front-end si tiene manos?

zvh62T.md.png

De hecho, la mayoría de las funciones básicas de un sistema de gestión de fondo estándar están relativamente unificadas, porque no requiere una gran personalización como los productos C-end. Una barra de navegación lateral o de encabezado se genera automáticamente a través de la configuración; varios conjuntos de temas están predeterminados para facilitar el cambio; luego se escriben varios módulos generales, como administración de usuarios, administración de roles y administración de diccionarios; finalmente, se agrega una página de inicio de sesión para mejorar básicamente se realiza el siguiente control de Autoridad.

¿Es difícil lograr estos? No es difícil Para la parte delantera, es suficiente tener manos. Esto también lleva a muchos desarrolladores a optar por escribir por sí mismos. Aquellos que estén interesados lo promoverán después de escribir. Si los comentarios son buenos, continuarán manteniéndolo. Si no hay comentarios, puede convertirse gradualmente en un marco de uso propio. o abandonar el hoyo.

Es por eso que hay tantos marcos de fondo en Internet, porque aparecen nuevos marcos todo el tiempo, y también hay una gran cantidad de marcos que no se han actualizado durante varios meses, o incluso más de medio año .

¿A quién sirves?

Volviendo al tema, ya que queremos hacer un marco de sistema de gestión, ¿quién definirá este " bien ", es el cliente? Si, pero no todo.

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

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

如何服务？

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

通用业务组件少
相似业务模块需要频繁拷贝代码或文件
特殊场景缺少统一解决方案
框架本身提供API少，扩展性差

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

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

通用业务组件少

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

比如在 Element Plus 的 Cascader 组件基础上，封装了**省市区街道联动**组件，方便实现二级、三级和四级的选择联动：

zvH9Wn.md.png

再比如在 Element Plus 的 Upload 组件基础上，封装了**图片上传**组件，提供了多图排序、多图预览、文件类型和数量限制等特性：

zvHFyV.md.png

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

zvHmFJ.md.png

还有**搜索面板**组件：

zvHnY9.md.png

当然不仅仅是上面介绍的这些，更多可以访问演示站进行查看。

我想说的就是，通用业务组件，是框架比较容易解决的一个痛点，因为它肉眼可见，通过原型图或设计稿，找出一些频繁在多个业务模块中出现的功能，就可以考虑是否可以封装成组件，从而减少开发者自己去实现的时间。

相似业务模块需要频繁拷贝代码或文件

后台系统里，一定有一些模块在界面、操作逻辑上是高度相似的，比如各个模块里的列表页，它们都有搜索功能、数据展示、分页功能。但又不完全一样，比如数据源、搜索项、列表展示字段都不一样。

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

当然开发者也可以根据具体业务场景，自行扩展需要生成的模板。

特殊场景缺少统一解决方案

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

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

但一些稍微特殊的场景下，如果框架本身没有考虑到，那需求只能向框架妥协，毕竟不是所有开发者都有能力去完整阅读框架源码，并进行二次开发定制功能。

说了这么多，可能大家还不清楚到底有哪些特殊场景，这里我举几个我遇到的：

大家可以对比下现在正在使用的框架是否能满足这些场景下使用，也可以留言分享一些其他业务场景

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. Pestaña relacionada

Se proporcionan API como abrir, cerrar y verificar.

avance

fin

Escrito aquí, quiero desviarme un poco.

En algún momento de este año, de repente tuve más reconocimiento por la frase "los programadores cambian de carrera, el gerente de producto más adecuado". En la categoría de programadores, creo que el desarrollo front-end es especialmente adecuado para cambiar a gerentes de producto.

Debido a que a la mayoría de los clientes no les importa qué tecnología usa, solo les importa la "apariencia", como si la interfaz es atractiva, si la operación es razonable y si la animación es fluida, y la mayor parte del trabajo diario del desarrollo front-end se ocupa de estos. Cuando se expone a suficientes requisitos comerciales, cuanto más comprenda lo que quieren los clientes, podrá descubrir rápidamente los puntos débiles o los lugares poco razonables en los próximos requisitos comerciales y brindar una solución relativamente madura, que también es La capacidad y la experiencia que un gerente de producto debe poseer.

Al igual que el marco del sistema de gestión que escribí, este año no estoy satisfecho con la acumulación de nuevas funciones, pero sobre esta base, pienso en cómo servir mejor a los desarrolladores que usan mi marco, no solo para satisfacer sus necesidades, Y hacerlos cómodo de usar, comofantástico-administradorEl eslogan en la página de inicio del sitio web oficial: " Listo para usar, brinda una experiencia de desarrollo cómoda ".

Gracias por leer aquí, espero que mi humilde opinión en el artículo pueda brindarle algo de inspiración.

Cómo hacer un marco de antecedentes de gestión