SREWorks前端低代码工程设计概览
引子
"低代码"一词似乎是最近几年才流行起来的词汇，2015年前后AWS、Google、Oracle等厂商开始入局低代码领域时，国内氛围还没有很高。2018年5月，快速应用开发的低代码平台 OutSystems 获得 3.6 亿美金投资；同年8月，西门子宣布以 6 亿欧元收购低代码应用开发厂商 Mendix ；此后，越来越多的企业开始尝试以低代码/零代码技术重构数字化业务，低代码平台市场逐步火爆起来。
其实低代码开发并非新生事物，据可考的资料，低代码概念最早诞生于上世纪80年代IBM的快速应用程序开发工具(RAD)；后来微软的VB、C#可视化开发工具Visual Studio，谷歌的Android集成开发工具Android Studio等都是对其概念的工程实践。低代码本质上还是一种软件开发方式：即不写代码或少写代码的方式来完成软件开发。
于前端而言，低代码开发其实也并不陌生，把“低代码”描述为“页面可视化编辑”，这一概念就变得熟悉了起来，我们曾经使用过的Dreamweaver、Frontpage等其实都可以归属到低代码的范畴。随着Angular、React、Vue等前端框架的普及以及gulp，webpack等构建工具的完善，前端进入工程化协作开发时代，逐步开始承载越来越多的业务逻辑。
当前云原生开发火热，在容器化微服务化技术加持下，传统意义的后端开发瘦身，又催生出了前端服务化的理念。在适配行业领域，业务场景，用户群体等不同条件下，前端低代码的设计落地和工程实践相应会呈现出不同的特征与特色。
文章结构
项目背景
技术架构
设计理念
菜单树与路由
前端设计器
页面布局
动态表单
数据源
页面操作
节点参数阈
组件扩展
愿景与规划
一 项目背景
SREWorks是一套面向企业级复杂业务的开源云原生垂直运维解决方案，是大数据SRE团队近10年锤炼的SRE工程实践的沉淀。
解决前端开发的前端统一托管工程（sw-frontend）是运维解决方案的重要一环，提供了一套serverless体验的配置化前端低代码解决方案：该方案以运维人员为主要用户群体，集成了前端设计器/渲染器，提供前端页面部署，代码回滚，编译打包等方案。同时赋予运维人员根据自身业务需求，快速创建定制应用的能力，有效提升诸如支撑故障处理、监控分析、变更保障及值班/客服/大促等运维场景的运维效率。
二 技术架构
低代码作为一种软件开发方式，特点在于少写代码或不写代码，只通过界面的托拉拽配置即可完成满足需求场景的软件，提高了软件的开发效率。效率提升的关键在于“复用”——于前端页面而言，就是对页面进行解构抽象，映射为json等格式的配置文件，进而对各个粒度的组件进行编排复用；通过模板引擎进行组件映射，加载，渲染，路由组装编排，数据流传递注入等完成页面挂载。
作为一款着力于提升运维开发效率的前端低代码产品，sw-frontend工程采用React+antd为主的技术框架，设计了一套组件映射、编排、解析、渲染的工程体系：以antd组件为自由编辑粒度，用户在前端设计器通过可视化交互或者json编辑的方式，依据运维工作的实际使用场景，对组件进行属性配置/组件嵌套拼装；同时根据运维场景目标需求对页面组件进行布局的编排、数据源的绑定以及在合适点位插入Dynamic Logic，完成页面节点的设计工作，形成节点模型nodeModel，经模板解析引擎进行解析渲染。
sw-frontend整体架构图如下：
三 核心设计
低代码产品由于适配的需求场景和面向的用户群体不同，所呈现的产品形态和交互方式也各具特点：类似汽车自动驾驶，区分L1、L2、L3...，低代码产品在使用复杂度上也大体呈现几种形态：
给普通用户使用的低代码产品：用户只需关心自身业务，无需代码配置，只用修改页面组件的 Data 就能快速地生成页面，通常营销活动页面都是通过此类方式快速构建；
面向中台开发的低代码产品：进行界面拖拽设计并进行json编辑配置即可；
着力于提高前端人员日常产出效率的可复用组件/插件：如json-shcema动态表等，具有一定封装粒度，旨在提升代码段复用率，提升开发效率。
sw-frontend就是这样一款面向运维中台开发的低代码产品。运维是个特定的业务需求场景，搭建一个ui界面只是运维场景的需求之一；sw-fontend提供了一套满足强交互页面类型设计，serverless体验，灵活的数据流处理能力和丰富的组件扩展能力的低代码解决方案。它不单是一个低代码框架，而且还内置了或者塑造了一整套的运维工作流模式，以适配运维业务场景的使用：
1 菜单树与路由
sw-frontend以用户创建的各个应用为一级路由构建起整个前端工程的菜单体系，所有的页面都是依托“应用”为节点进行挂载的。下图为应用运维桌面，用户可以点击应用快捷方式进入运维应用。
运维桌面同时也是我们应用维度的其中一员，即在sw-frontend的总体设计概念上：一切皆是应用。
菜单节点树
进入到dataops应用的开发态，在前端开发编辑器中，我们可以从左侧菜单节点树看到与上面菜单一一对应的内容，每个节点上挂载了该页面的具体配置，每个页面配置包含一个主页面和多个页面区块配置，维护管理在页面设计器中。
动态路由生成
节点树示意图
2 前端设计器
swadmin作为内置应用的一员，同时也是其他应用的母应用，一生万物，所有应用的都是通过前端设计器设计配置而来；在此可以对组件/页面进行业务字段、ui和数据源的配置，对当前应用的节点树进行编辑，以及对每级节点对应页面的组件进行属性配置、数据源绑定和布局编排工作。
swadmin提供了两种交互编辑方式：
可视化交互编辑
如下图就是在对staticPage这一应用下的一级子路由"pageScreen"页面进行开发编辑，下方弹窗区为对页面内大屏组件的属性进行可视化配置。
可视化编辑模式
源码编辑（JSON编辑）
除了可视化设计界面外，同时也提供了源码编辑，直接修改映射配置，以提供更大的灵活性；且可以在源码编辑和可视化编辑之间进行灵活切换，并保持同步的编辑态。
3 页面布局
sw-frontend内置两种页面布局类型：自定义布局和流式布局(自定义布局当前只在内置应用使用，暂未对外部应用开源使用)。对于流式布局我们将页面抽象成一行行的容器，在新增行容器时可以自定义分割成若干区块并并确定分割占比，每个区块对应一个组件容器位。
流式布局
对于自定义布局，可以根据业务需要对添加进入的区块组件任意拖拉改变宽高以及布局位置：
4 组件体系
组件结构图
自定义组件管理
5 动态表单
表单工厂
页面交互还有重要的一环：表单数据的交互。sw-frontend以工厂模式提供了近三十种输入形式的表单项以供表单设计选择使用，对于Form表单提供了界面化的属性配置如：表单项类型、是否展示、表单项数据源、表单项条件渲染、表单项label、表单项key，表单拖拽排序，动态添加表单项等。
对于表单数据的编辑回填,以及表单和页面的数据流以及action交互，也做了模型化的抽象处理，这个在后面页面操作章节做详细介绍。
过滤器/表单Action
对于页面的表单Action，如新增、编辑等，sw-frontend抽象为单独的操作区块，每个操作区块创建时会生成unikey，在页面组件工具栏区添加好操作button后，可以通过页面交互或源码编辑的形式建立绑定关系。
源码视角下，在table组件的toolbar字段下，“新建应用”button以blockId的形式跟新建应用的表单操作区块建立了绑定关系；当模板引擎解析到toolbar工具栏，会用该blockId获取到该操作区块的配置，然后根配置以表单工厂函数加载对应表单项并对其表单项值初始化。
源码视角区块绑定形式
过滤器
过滤器
action操作
对于数据源为api格式的地址中使用$(变量名)，会统一从参数阈中渲染替换，然后获取组件数据源的数据；同时提供请求前置函数和请求后置函数的执行钩子，在这里可以进行数据的拆解或组装以及写入一些业务逻辑代码。
7 页面操作（Action）
页面操作是低代码工程设计里面的重要一环，承载着很大一部分运维需求场景，sw-frontend将页面操作抽象为四个大的类别：工程内置操作类，过滤器类，表单提交类，超链跳转类。
工程内置操作类
sw-frontend在组件的工具栏内置了若干通用的按钮类的操作，根据操作类型map，识别相应操作进行渲染。典型的如“组件刷新”操作，用户在界面添加该按钮，配置唯一识别字段"__refresh__"，即可完成组件刷新操作的配置，该刷新Button通过触发参数阈改变事件，间接完成组件的数据刷新操作。
超链跳转类
超链跳转类别的操作，常用于表格等组件的行内操作，一般以JSXRender的形式进行配置，渲染为button/link。进行路由跳转或者超链跳转时，表格行内数据可以作为传入参数使用。
过滤器类
过滤器本质而言是对传统开发方式下页面查询的一种抽象：组件本身定义有数据源，过滤器的职能是触发组件重新获取数据。在sw-frontend中，过滤器的表现形式可以是一组tab、一组表单项。以表单类过滤器为例：用户在填充各过滤条件之后，“提交”操作本质并没有直接的提交地址，而是进行表单参数的投递--改变节点参数阈，组件通过监听参数阈关联字段的改变，重新拉取数据，完成传统页面的查询操作。
表单提交类
表单操作承载了大部分的页面操作，sw-frontend将常规的“增”、"删"、"改"都抽象为表单提交类的事件，对这类Action操作，在完成和服务端交互后，以callback的形式，进行节点参数阈字段的投递，以触发数据渲染类组件的刷新从而完成“增”、"删"、"改"类的操作，如下两图分别为Action操作定义和运行时渲染界面：
其中在进行数据编辑时的表单数据回填，大多数场景为列表类数据的编辑：定义在行内的“编辑”操作会绑定一个表单Action区块；在点击事件发生时，会将该行内数据对象rowData与当前节点参数阈合并，作为actionParams传入该Action表单区块，表单区块模型类通过读取actionParams的对应字段value作为各表单项的initValue，完成数据回填。
8 节点参数域
节点参数阈是以redux状态管理机制为依托，建立路由节点页面共享参数状态对象nodeParams，节点页面各组件通过对nodeParams的修改和对应字段侦听来间接完成组件间的信息传递和事件交互。
sw-frontend在节点页应用创建之初，会初始化节点参数域：nodeParams；在节点页面的生命周期内，也会将url中变量参数，一些页面交互产生的runtime参数以及外部函数投递来的参数整合到参数域中来。
节点参数阈查看示意图
随之组件在经过统一数据源处理器获取数据流渲染之后，会对节点参数阈的target字段值通过监听对比，以触发数据reload刷新机制，重新获取数据源数据；同时页面的一些action表单操作，也是通过参数阈投递更新目标字段值进行进行间接触发相应组件的reload刷新渲染。
9 组件扩展
sw-frontend提供了声明式内置组件的注册机制，同时开辟了用户自定义组件的入口，用户可以将一些常用的自定义组件嵌入到我们的组件列表，以供前端设计器统一调拨；当前自定义组件以JSXRender的方式进行执行，可以直接书写JSX代码，同时能够识别antd组件，赋予用户更加灵活的页面渲染能力。
自定义组件编辑区
四 愿景与规划
现sw-frontend已内置运维场景常用的基础组件，图表组件，landing组件，布局组件等五十余个组件，除此之外还开放了用户自定义简单JSX组件的入口，让用户对自定义组件进行编辑管理，以拓展组件扩展和插拔使用的空间。同时动态加载远程组件，建立运维组件生态市场也纳入到了后面的版本规划中；以期能够共建打造出一个丰富共享的运维组件生态来，这也是我们将其开源的一个初衷愿景。
版本动态：我们会根据工作项目节奏，持续对功能进行完善优化和升级。近期在5月上旬发布了一个小版本，该版本加入了页面模板保存和从模板快速创建的功能，以进一步聚焦"复用"，提升开发效率。
SREWorks 开源项目地址
点击阅读原文查看详情！