Elpis 动态组件扩展设计：配置驱动的边界与突破

飞雪飘摇
4 阅读5分钟

配置驱动的边界问题

Elpis 通过配置驱动解决了 80% 的中后台 CRUD 场景，但总会遇到内置组件无法覆盖的情况：

  • 需要省市区三级联动选择器
  • 需要带千分位格式化的金额输入框
  • 需要集成公司自研的图片裁剪上传组件
  • 需要富文本编辑器、图表组件等第三方库

这时候有三个选择：

方案 A：放弃配置驱动，回到手写代码

方案 B：等框架作者更新内置组件

方案 C：自己扩展组件，像内置组件一样使用

Elpis 选择了方案 C，通过动态组件扩展机制，让框架既保持标准化，又具备灵活性。

核心设计：一个"字符串"的魔法

Elpis 的扩展机制说穿了就一个核心思想：配置里写的是字符串，渲染时才决定用哪个组件。

看这段配置：

product_name: {
  createFormOption: {
    comType: 'input',  // 这只是个字符串
  }
}

这个 'input' 不是直接对应某个组件，而是一个"代号"。真正的组件在哪？在一个叫"注册中心"的地方：

// form-item-config.js
const FormItemConfig = {
  'input': { component: InputComponent },
  'select': { component: SelectComponent },
  'richEditor': { component: RichEditorComponent }
};

渲染时，Elpis 做的事情很简单：

<component :is="FormItemConfig[配置里的comType].component" />

就这样，配置和组件解耦了。你想加新组件？往注册中心加一行，配置里就能用。

这个设计妙在哪？

1. 配置稳定： 即使你把 InputComponent 整个重写了，配置文件一个字都不用改。因为配置里只是写了个 'input' 字符串。

2. 场景隔离： 搜索栏有自己的注册中心，表单有自己的注册中心。同样是 'input'，在搜索栏可能是个简单输入框，在表单里可能是个带校验的复杂组件。

3. 扩展简单： 不需要改框架代码，不需要发 PR，不需要等更新。自己加一行注册，立刻就能用。

实战：扩展一个富文本编辑器组件

通过实际案例演示如何扩展组件。假设需要添加富文本编辑器支持。

第一步：实现组件

创建文件 app/pages/widgets/schema-form/complex-view/rich-editor/rich-editor.vue：

<template>
  <div class="form-item">
    <div class="item-label">
      <span>{{ schema.label }}</span>
      <span v-if="schema.option?.required" class="required">*</span>
    </div>
    <div class="item-value">
      <QuillEditor v-model:content="value" />
      <div v-if="!isValid" class="valid-tips">{{ validMessage }}</div>
    </div>
  </div>
</template>

<script setup>
import { ref } from 'vue';
import { QuillEditor } from '@vueup/vue-quill';

const props = defineProps({
  schemaKey: String,    // 字段名
  schema: Object,       // 字段配置
  model: String         // 初始值
});

const value = ref(props.model || '');
const isValid = ref(true);
const validMessage = ref('');

// 必须实现的接口方法
const validate = () => {
  if (props.schema.option?.required && !value.value) {
    isValid.value = false;
    validMessage.value = '这个字段必填';
    return false;
  }
  isValid.value = true;
  return true;
};

const getValue = () => {
  return { [props.schemaKey]: value.value };
};

defineExpose({ validate, getValue });
</script>

关键约定：

  • Props 必须包含 schemaKey、schema、model
  • 必须暴露 validate() 和 getValue() 方法
  • 其他实现细节可自由发挥

第二步：注册组件

在 app/pages/widgets/schema-form/form-item-config.js 中注册：

import richEditor from "./complex-view/rich-editor/rich-editor.vue";

const FormItemConfig = {
  input: { component: input },
  select: { component: select },
  richEditor: { component: richEditor }  // 新增注册
};

第三步：配置使用

在业务模型中使用新组件：

product_description: {
  type: 'string',
  label: '商品描述',
  createFormOption: {
    comType: 'richEditor',  // 使用扩展组件
    required: true
  }
}

完成。刷新页面，富文本编辑器自动渲染，校验、提交等功能自动生效。

背后的技术：Vue 3 的动态组件

你可能好奇 Elpis 是怎么做到"运行时决定渲染哪个组件"的。答案是 Vue 3 的 <component :is>。

看 Elpis 的核心渲染代码：

<template>
  <template v-for="(itemSchema, key) in schema.properties">
    <component
      :is="FormItemConfig[itemSchema.option?.comType]?.component"
      :schemaKey="key"
      :schema="itemSchema"
      :model="model[key]"
    />
  </template>
</template>

这段代码在做什么？

  1. 遍历配置里的每个字段
  2. 读取字段的 comType（比如 'input'）
  3. 从注册中心找到对应的组件（FormItemConfig['input'].component）
  4. 用 :is 动态渲染这个组件

关键点：:is 后面可以是一个变量，这个变量的值是什么组件，就渲染什么组件。

这就是为什么你改配置文件就能换组件——因为组件是运行时决定的，不是编译时写死的。

一个容易忽略的细节：统一接口

注意到没有，所有组件都接收同样的 props：

:schemaKey="key"
:schema="itemSchema"
:model="model[key]"

这是 Elpis 的"约定"。只要你的组件遵守这个约定，就能被动态渲染。

这就像 USB 接口，不管你是键盘、鼠标还是 U 盘，只要接口对得上，就能插上用。

所以写扩展组件时，记住三件事：

  1. Props 要有 schemaKey、schema、model
  2. 要暴露 validate() 和 getValue() 方法
  3. 其他的随便你发挥

对比：Elpis vs 其他方案

vs Element Plus / Ant Design（组件库）

组件库：给你一堆组件，你自己拼。

<el-form>
  <el-form-item label="商品名称">
    <el-input v-model="form.name" />
  </el-form-item>
  <el-form-item label="价格">
    <el-input-number v-model="form.price" />
  </el-form-item>
  <!-- 每个字段都要写 -->
</el-form>

Elpis：写个配置，自动生成。

{
  product_name: { createFormOption: { comType: 'input' } },
  price: { createFormOption: { comType: 'inputNumber' } }
}

结论：组件库灵活但重复劳动多，Elpis 标准化但省事。适用场景不同，不是替代关系。

vs Formily / React JSON Schema Form（表单方案）

JSON Schema 表单：只管表单，其他的你自己搞。

Elpis：搜索 + 表格 + 表单 + 详情，一套配置全搞定。

结论：Elpis 是 JSON Schema 思想在整个中后台系统的延伸。

写在最后

Elpis 的动态组件扩展机制核心就三件事：

  1. 配置里写字符串标识，不直接引用组件
  2. 用注册中心做类型映射，字符串对应具体组件
  3. 用 Vue 的 :is 实现运行时动态渲染

这套设计让框架在标准化和灵活性之间找到了平衡：

  • 80% 的场景用内置组件，配置驱动，快速开发
  • 20% 的场景扩展组件，一次封装，到处复用

扩展组件的成本是一次性的，但收益是长期的。当你的组件库逐渐丰富，配置驱动的威力就会越来越明显。

框架的价值不在于限制开发者，而在于提供清晰的扩展路径，让开发者在需要时能够突破标准化的边界。

引用： 抖音“哲玄前端”《大前端全栈实践》

avatar
文章
阅读
粉丝