低代码平台前端二开机制设计

低代码平台前端二开机制，大致有两种：

平台直接提供整个页面的代码，即出码
平台提供视图组件，组件约定二开机制，即配置扩展

出码方案的优缺点

出码是平台直接提供整个页面的代码，但代码里会暴露整体布局、数据state及逻辑、样式等，虽然也会包含一些基本组件，但组件本身并不会进行逻辑处理。

优点：自由度高，可完全突破平台内置的样式/布局/交互约束，可补充各种自定义逻辑
缺点：产出的代码复杂,开发/维护成本高；

一旦出码，想再使用平台的配置比较困难。平台上视图新增了一个控件，得进行复杂的比对，才能将部分新增内容插入到本地代码中，这个过程类似 git 的冲突合并，没法做到稳妥的自动合并。

配置扩展方案

平台提供一个完整的组件，比如列表视图就提供一个 Pro-Table 组件，表单视图提供一个 Pro-Form 组件，组件既视图。

默认情况该组件会拉取平台配置进行渲染，二开点全部基于配置 schema 进行设置，并将扩展schema作为props传入组件，该组件将扩展配置与平台配置合并后再进行渲染。

举个例子

比如配置 schema 中，对表格类和表单项的描述如下：

json 复制代码

{
    "columns":[{
        "key":"status",
        "title":"状态",
        "type":"enum",
        "enumOptions":[
            {"t":"正常","v":"1"},
            {"t":"异常","v":"0"}
        ]
    }],
       "formItems":[{
        "key":"startDate",
        "title":"开始日期",
        "type":"date",
        "required":true,
        "editWidget":"dataPicker"
    }]
}

基于该结构，可设置二开约定：

对表格的"状态"列自定义渲染内容

css 复制代码

{
    "customSetting":{
        "columns":[{
            key:"status",
            render:CustomStatusRender
        }],

    }
}

对表单项"开始日期"自定义编辑控件，则可对组件传入扩展配置

css 复制代码

{
    "customSetting":{
        "formItems":[{
            key:"startDate",
            editWidget:CustomDatePicker
        }]
    }
}

这种模式下，组件对开发者是个黑盒，增删改查等所有内置逻辑都在黑盒内运行，开发者只能根据组件约定的方式，对有限的配置进行二开。比如要调整布局/交互，但组件schema本身没有提供这方面能力，则无法实现。这种设计方案的优点是二开成本低，并且可以继续使用平台配置。

前端组件设计

在该方案下，组件应当遵循以下原则：

尽可能多开放内部逻辑，比如点击打开详情，出发查询刷新，勾选，表单校验保存提交等
尽可能多开放内部数据，比如表格/表单当前数据、动态枚举/关系数据，当前配置项
尽可能多开放配置项
尽可能多的暴露内部事件，比如查询前后、修改前后等

基于以上原则，可以推导出如下设计：

组件应进行ui和数据分层，ui和数据层以action或事件交互，对外暴露action
组件应设计多种hooks，before类hooks应支持阻塞/取消
组件应将配置进行颗粒度划分，且配置与状态分离
扩展配置应区分静态扩展配置（多次渲染只会处理一次）和动态扩展配置（每次渲染都会处理）

第4点是出于性能考虑，否则将整个setting作为state，会导致很多不必要的渲染，而setting中有一部分扩展配置属于初始化配置，仅处理一次。

比如字段展示名称，每次渲染都需要合并，因为开发者可能会以不同的数据而设置不同的名称；

但如果是渲染控件配置，则合并后不再关注该配置的变化，如果开发者需要在某些条件下显示A控件，其他情况显示B控件，可以将这种逻辑在一个组件内实现：该组件可以通过props获取当前配置、数据，然后再进行判断渲染A还是B。

整体结构

比如一个Pro-Table组件提供整个列表视图，在Pro-Table组件内部，包含配置层，视图层，数据层，和action。

Pro-Table的视图，又由几个高级组件pro-component拼装完成。pro-component内部具有逻辑，比如导入按钮，内部包含整个导入流程：点击事件、上传弹窗、导入请求、异步消息等。

每个pro-component从全局setting中接收配置，如果有动态配置，则需要将该配置作为自己的state；pro-component可以获取全局data，也可能产生本地data。

pro-component内部由多个原子组件组成，这部分原子组件可以由二开组件代替。二开组件可以获取到 pro-component内部的配置及数据，也可以调用内部的action。当然整个pro-component也可以是一个二开组件。

action中心，需要从全局配置中拿到hooks，补充到action控制器，组件派发action，控制器在处理真正的action逻辑前后需要先处理hooks。