低代码平台的探索之路WG-LCode

Mothpro
1,168 阅读9分钟

前言：为什么要做低代码平台

首先，在说正事之前，我们来先看看前端整体的一个发展历程。

从前端的发展历史说起，让我们回到前端的史前时代，也就是所谓的切图仔时期。这个时候前端的同学主要负责的是视图层的逻辑，当时主流的前端均处于”网页三剑客“统治时代，专门负责静态页面的展示。其他的动态渲染，业务逻辑，HTTP API等，均由后端负责。

image.png

然后因为智能手机的全面普及，还有3G到4G网络时代的迅猛发展，前端进入了一个快车道，迅速的发展到了工程化的时代，这个时代开始，开发者非常关注前后端的性能优化问题，页面的渲染工作逐渐交给前端同学负责，前后端逐渐开始分离，php、jsp、.net开始逐步退出历史的主舞台，取而代之的是jquery、jquery mobile、html5、css3的大力发展和前端构建工具grunt、webpack崛起。

image.png

接着，前端同学开始不满意低效的前后端协同开发模式，而正是Node的出现让一部分前端的同学开始承担BFF接入层的开发，逐渐开始负责一些创新项目的全栈开发，对外提供HTTP API。

彩蛋🥚 ：什么是BFF？

“BFF是英文“Best Friend Forever”的缩写,一般中文直译为“永远的最好的朋友”,该词汇多用于口语。” 前端和后端永远是好朋友！

image.png

随着职能的改变，变化给我们带来了新的机遇，也带来了新的挑战

前端的巨人从来没有停止过步伐，新的职能带来了更大的机遇和更多的挑战，前端也开始考虑，如何保障高可用、高性能、高质量和高稳定？

大前端时代来临了！🙋🏻‍♀️

对于很多前端同学来说，这是一个全新的领域，从浏览器端到服务器端，从简单的视图层逻辑渲染到业务层服务开发，很多新的领域只是需要去了解和学习，一个个全新的名词出现在了前端开发者的案板前：前端微服务，数据可视化，低代码平台，大前端，中台，组件化……

而今天，我们要谈的前端低代码平台的探索之路，就是建立在一个这样波澜壮阔的背景下🌊

我需要用低代码平台来解决什么问题

对于做架构而言，所有的技术方案都是建立在发现问题、遇见问题后，专门用来解决问题、避免问题的。

那对于我们来说，我们到底需要用WG-LCode来解决什么问题？

  • 统一微前端架构各个微应用页面的样式和交互

    • 我们公司的医务信息化 his 系统由多个独立部署、第三方技术栈不统一的系统组合而成，这些系统的样式，交互存在差异，通过页面可视化搭建系统生成的页面底层使用同一套组件库，这可以满足样式，交互一致，并且面对之后的样式和交互变更支持批量修改

  • 缩短页面开发的时间

    • 我们公司的医务信息化 his 系统是一个 toB 系统，这里面存在数量可观的类似的页面，开发重复页面容易磨灭开发人员的积极性，整理各类页面的共同之处，通过可视化搭建系统来减少页面开发重复度，让开发人员集中精力开发逻辑复杂的页面

  • 提高交付质量，降低前端开发门槛

    • 对于简单逻辑的页面，通过可视化搭建系统，配置式、一键式自动生成活动页、运营页，可以降低前端代码的复杂度，让产品同学、测试、实施、后端同学、实习生通过编写少量的JavaScript代码甚至完全不编写就能搭建无数个页面。

低代码

实际上，搭建一个可用的前端低代码平台并不是一件难事。但是搭建一个符合公司实际情况，贴切满足企业职工自身需求的低代码平台却不是一件易事。

首先，我们需要明确，低代码平台解决的最大问题是复用。

复用也是目前前端开发中的一个重要课题，特别是当前的主流JavaScript框架，比如我们正在使用的Vue，React等，都是组件化的开发方式，又如形形色色的ui组件库的出现像element-ui，ant-design等都是用来解决重复造轮子的问题。

image.png

目前我们遇到的问题和提出的解决方案

我们的前端团队还处于一个初步创立，各项基础设施待持续完善的状态，虽然我们在日常的开发过程中，通常会创建一些通用的组件，然后在各个需要这个组件的地方去进行引用，以此来提升开发效率。

但是，我们可以发现，尽管这样的页面非常相似，我们的UE同学也针对性的设计了不同的规范要点，每个同学对于规范的认知不一致，看似一样的页面实现方式很多种，百花齐放的代价就是维护难，拷贝又会有隐藏问题。

而一个从0到1阶段的产品，产品的反复修改和规范的反复修订又是一个常态，在项目进度和压力如此紧张的情况下，我们前端的研发人力本身就严重不足，如果还需要抽出宝贵的开发资源来做UI走查下的细节追究，这更是一场噩梦和灾难。但是从交付以及各种角度出发，我们又需要保障产品的产出是外观精美且功能完善的。

因此我们前端基础建设团队，希望通过建设WG-LCode低代码平台，统一由平台去维护，如果涉及到规范、样式的调整，我们只需要维护一处，也就是低代码平台的资源。

架构设计

我们可以通过下面的大图来了解整个 WG-LCode 的架构。

image.png

在这里，我们借用 ant-design-pro 的思想，希望把WG-LCode的资源统分为两大类，一类为区块，一类为模板。

image.png

image.png

这是我们基础配置工作站里最常见的一个页面。包含了列表数据的增删改查操作。

假如我们把这个页面定义为一个模板，那么它就分别由以下几个区块组成：

  • 标题栏区块
  • 搜索区块
  • 操作区块
  • 内容区块
  • 分页区块

我们可以通过一个json数据来描述这样的一个模板，数据大概是下图所示的样子，

image.png

它们分别是：

  • 标题（headerTtile）
  • 控制搜索区块整体配置细节（searchOption）
  • 控制搜索区块显示的内容（searchs）
  • 控制内容区块是否显示多选（showSelect）
  • 控制内容区块是否显示序号（showIndex）
  • 控制内容区块列表表头显示的内容和需要展示的数据细节（columns）
  • 控制内容区块列表针对特殊表头————操作列的个性化配置（columnsOption）
  • 控制操作区块左边操作内容（toolBarRender）
  • 控制操作区块右边操作内容（toolBarRightRender）
  • 抽象的网络请求方法（request）
  • 控制模板加载状态的标志（loading）

这些都是可以传入到这个模板和各个区块中的属性及初始属性值。列如这个模板展示的布局方式、区块内容，表格包含的列信息、按钮等。而这个json也是低代码平台搭建最核心的部分。 在我们的计划中，WG-LCode需要支持可视化可拖拽的页面设计，这个json需要承担页面设计和页面渲染间串联的纽带角色。

第一期规划 V 1.0 wg-blend-page

当我们的产品展示类似的界面时，开发只需要在页面文件中引用这个blendPage模板组件，再把对应的描述json信息传递到组件内就可以了。

关于wg-blend-page

image.png

但是这样似乎还是采用了编码的方式去解决复用问题，距离我们的低代码还有些距离。

第二期规划 V 2.0 wg-lcode-web

我们会创建一个wg-lcode-web的内部后台管理项目。

在这一期我们需要做的事情：

  • 创建可视化的工程界面
  • 支持在界面上配置组件以及组件所需的字段和属性
  • 根据已经配置好的字段和属性参数条件，自动生成对应的模板page或者区块组件
  • 可以选择生成的产物指定的位置（比如指定在某工作站下生成模板页面）
  • 可以直接发布到线上
  • 发布线上的同时产出源代码，可以供于开发二次修改和再定制

这时，我们可以将这些可动态控制的组件属性通过在线表单进行填写。

前端工作站工程中，我们可以直接在pages文件夹中找到这个区块模板的页面路由所对应的组件，他们都是我们已经封装好的列表增删改查模板。

这样，如果还有二次开发和再定制的需求，进入到这个页面，我们只需要根据实际的业务场景需求，完善json数据，将我们设置的模板属性值赋值到组成模板的各个组件上就可以完成这个模板的渲染了。

image.png

image.png

第三期规划 V 3.0 可视化拖拉拽低代码平台

在这一期工程中，我们主要要做好两件事情：

  • wg-lcode-web后端管理平台需要支持拖拽式的灵活搭建页面
    • 要实现这个目的，我们首先需要预设好大量符合业务场景和用户需求的区块组件，包括且不限于大量且丰富完善的表格区块、树区块、弹窗区块、表单区块等。

image.png

  • wg-cli脚手架需要支持悬浮的dev-tool工具，支持一键插入代码块和自动在本地生成页面模板

image.png

以上两张截图来自于ant-design-pro和某成品低代码平台

avatar
文章
阅读
粉丝