JSON 驱动界面 · 衍景

本文解决什么问题：一个常见的功能需求（加一列、改个搜索、调整表单顺序）往往要「找开发改代码、等排期」。衍景让界面可以用配置描述——改动属于配置级而非代码级。业务使用者与实施方都能更快得到需要的页面。

一句话定义

衍景（Derive-View） 是衍数的界面框架：用一份 JSON 配置描述页面的搜索区、表格列、表单控件与布局，平台据此渲染出完整可用的界面——绝大多数后台页面不需要手写前端代码。

它想解决什么问题

传统开发里，「同样的增删改查」要在每个项目里重写一遍界面，工作量大、样式还不一致。衍景把界面的结构描述与运行实现分开：

• 只需要描述「这个页面有哪些字段、怎么搜索、列怎么展示」；
• 界面的渲染、分页、筛选、权限控制交给通用组件完成。

结果是一类页面（例如各类业务单据的管理列表）可以用几乎相同的方式快速产出，且视觉统一。

一份配置长什么样

下面是一段示意（实际配置由平台定义模型后自动生成，不必手写）：

{
  "list": {
    "title": "订单列表",
    "search": ["order_no", "status"],
    "columns": [
      { "field": "order_no", "label": "订单号", "width": 180 },
      { "field": "status", "label": "状态", "type": "dict" }
    ]
  }
}

传统开发 vs 配置化

常见疑问

是不是完全不能写自定义代码？ 需要个性化交互时，可以在通用组件上做扩展——平台允许在保持配置主路径的同时接入自定义实现。大多数日常管理功能用配置就足够。

页面配置存在哪？ 配置与数据模型一起作为平台资产管理，可以随项目一起迁移与复用。

相关阅读

• 想上手搭建 → 「五分钟快速上手」
• 想了解数据模型如何驱动这些界面 → 「动态数据模型 · 衍枢」