为什么前端开发不能灵活些

[yidinghe]

以上面的图为例，前端在展示表单的时候不是把每个元素写死，而是先加载一个类似下面这样的 JSON 元数据：

{
    "ui-type": "form",
    "ui-element-id": "sms-query-form",
    "form-submit-path": "./sms-service/query",
    "fields": [{
        "field-name": "手机号码：",
        "field-type": "text"
    }, {
        "field-name": "发送时间：",
        "field-type": "time-range"
    }, {
        "field-name": "短信类型：",
        "field-type": "combo",
        "items": [{
            "key": "",
            "value": "全部"
        }, {
            "key": "0",
            "value": "注册"
        }, {
            "key": "1",
            "value": "修改密码"
        }, {
            "key": "2",
            "value": "找回密码"
        }]
    }, {
        "field-name": "发送状态：",
        "field-type": "combo-lazy-loading",
        "loading-path": "./enums/sms-send-status"
    }, {
        "field-name": "所属区域：",
        "field-type": "combo-lazy-loading",
        "loading-path": "./enums/busi-area"
    }]
}

然后按照 JSON 中的内容去动态组装表单。这样做的好处是如果查询条件有变化，这个 JSON 可以让后端开发直接改就可以了。

类似的表格也可以啊，虽然说请求次数和渲染时间可能增加，但作为后台系统是可以接受的。

[nianyu]

这种东西有 N 多现成的， 弊端楼上很多兄弟也说了，一旦复杂情况（尤其是工业领域互联网的表单还没那么复杂）你要不断实现自己的 DSL 最后就崩了

[abcbuzhiming]

你这不就是配置化 UI 吗？不是什么稀奇玩意，别说 web，上个时代的 PC UI 都有，问题是这类 UI 都倒在了层次不穷的需求上了。UI 这个东西的复杂性在于需求多样化，特别的多，以至于你没有办法在贴近业务的领域抽象出通用化的 DSL 来，要知道 UI 开发搞了这么多年也就积累出了一个 MVC(MVP,MVVM)模式，不是没理由的，太靠近业务的地方变化太多了，没法抽象