国内的大多数低代码平台，都有一个非常显眼的，可拖拉拽的视图设计器，比如宜搭的编辑器和明道云的表单设置。很多文章谈到低代码设计，就从可视化编辑器讲起。
截图来源：阿里的低代码引擎
截图来源：明道云的表单编辑器
表单编辑器与视图编辑器的区别
上面的两个截图，虽然布局类似，拖拉拽的交互一样，但他们对低代码的理念是完全不一样的。
明道云的表单编辑器，其实是可视化建模，他们的流程是：创建对象表单——创建对象和关系——以对象字段和关系生成列表视图。
而宜搭微撘这种，则是完全的从零开始配置界面。这些低代码开发者们，不知道用户配出来的界面是什么样子，也不知道数据怎么流转，只是提供最基础的视图控件和逻辑控件，视图效果和数据逻辑完全交给用户自己。如果同样配置一个列表视图，那么就要配置：查询区域的表单——表格和列——表单提交触发的查询接口——表格和查询接口返回数据的绑定——分页——新增修改按钮——新增修改的弹窗和表单——新增修改触发的接口等等。
可见视图编辑器使用和上手难度高很多。
但如果只是配一个简单的抽奖页、固定数据的列表页、 折线图等报表，那明道云的编辑器就完全无法支持。
所以视图编辑器是以效率和简捷为代价去适配更多的场景。
为什么都选择了可视化配置
对宜搭微撘这种低代码平台来说，他们并无确定的用户，也无标准场景，可视化的视图编辑器能适配的场景最多。
对明道云来说，虽然他们主要场景是标准的列表和表单视图，但他们面向的客户，大多没有能力理解模型、字段、关系等编程概念，而可视化表单配置，能很好的掩盖掉这些概念。当然，无论是表单还是对象，通过字段是无法完全描述列表本身的视图配置的，因此他们的列表视图非常简单。不过明道云舍弃了大数据对象、多层嵌套关联、多字段复杂联动等场景，以简单的视图应对简单的需求，这也不失为一种难能可贵的智慧。
为什么视图编辑器不适合配置列表视图
上面讲了，在视图编辑器中配置列表视图的操作，和元数据驱动的列表视图相比，显得非常复杂。
而元数据模型对象和字段本身的描述，也无法完全对应到列表视图的细节配置，因此列表视图是需要有它自己的一套配置的。
那么能否将列表视图作为一个组件，嵌入到视图编辑器中呢，利用它的可视化能力以及丰富的组件呢？微撘就有类似的操作，但并不符合实践。
列表视图是一个独立的复杂视图
一个完备的列表视图可以分为这些部分：
以及内置功能
元数据对象列表视图作为组件，虽然可以自带查询统计、新增修改功能，但是列表视图本身的交互细节仍然配置，比如字段可见性可编辑器、字段查询操作和控件、查询条件的常驻和隐藏、统计字段和方式、字段顺序、内容格式等等，内置按钮功能的各种配置。在我司的实践中，列表视图的配置项有170多项，可视化视图局促的编辑空间完全没办法容纳这些配置。
列表视图配置不强需求可视化
列表视图都是标准布局，在用户配置视图之前，他就知道这个视图是什么样子，因此用户对列表视图的可视化需求很低。
元数据驱动的列表视图配置痛点，主要在于，不熟悉配置能力的人找不到相关功能配置的地方：想要配置某个字段的可编辑，并不是去系统表单里添加这个字段，而是去这个字段的属性里打开可编辑性——很多人无法将一个展示类功能与对象的字段联系起来。这一点即使放到可视化视图里也解决不了。
总结
可视化编辑器并不是万能的法宝，并不适合多数据交互的场景。SaaS的典型视图场景——列表视图，值得且应该以一套独立的交互方案提供配置。
