乐趣区

关于低代码:基于-LowCodeEngine-的低代码组件体系的建设和实践

明天在这里和大家聊一聊前端组件,或者当初更风行的说法「物料」的话题。

物料自身曾经不是一个陈腐的话题了,从 06 年 jQuery 公布,前端物料就开始以各种 jQuery 插件的模式不断涌现,直到明天咱们依然能够在 github 上看到很多 jQuery 物料插件,他们当中的设计思路在明天风行的这些前端组件库里依然能够看到很多影子。

然而,物料也是一个常聊常新的话题,回看前端的倒退历史,会发现随同着前端技术的倒退,新的模块化形式、工程化工具、研发框架的呈现,物料的组织模式和品牌都在一直变革变动之中。究其原因,我感觉在于物料作为前端的一种模块化形象,是最显著和疾速的提效伎俩。前端团队和集体在业务开发到肯定水平时,应用形象物料的伎俩来升高业务开发的重复性和复杂度简直能够说是一条必经之路。此外,物料的形象往往又和模块化、工具、框架这些技术手段严密相连,这些技术的变革也会催生新的物料生产和生产模式的诞生。

近些年来,低代码畛域的话题热度在一直升温,国内外的各大云厂商和传统 SaaS 厂商都在低代码畛域一直加码投入。在这样的时代大背景下,物料这个陈词滥调的话题,又被赋予了哪些新的问题,随同着哪些挑战和时机。这外面的思考和实际正是明天想和大家聊的货色。

物料的现状和挑战

后 jQuery 时代,以 React、Vue、Angular 为代表的的前端框架曾经站稳脚跟,通过数年的迭代更新和互相学习,API、应用形式和生态都已成型并根本欠缺。同时,基于三大框架的根底组件库,无论从组件分类、应用形式、主题定制以及相干的生态上都曾经比较完善,并且都曾经有了本人的忠诚拥趸和重度使用者。

从根底组件到业务组件

大部分的前端团队曾经很少再从零开始写根底组件库,筛选一个适合的合乎本人业务特点和技术选型的根底组件库,并基于此生产适宜本人业务的业务组件库,置信是更多人的抉择。通常咱们会从四个角度登程去封装咱们的业务组件库:

  • 业务数据:将根底组件与业务数据接口联合,如选人、选部门、选城市等
  • 业务场景:业务中呈现的一些通用场景,以大颗粒度的模式封装起来,常见于表格、表单、图表场景
  • 业务特色:业务里独有的交互模式,能够由一些根底组件拼合而成
  • 品牌主题:将根底组件批改为和业务产品品牌设计相符合的款式

从技术的角度看,业务组件与根底组件次要面临的问题不同:

  • 业务组件对易用性和开箱即用的诉求高于扩展性和通用性
  • 业务组件大多不须要解决简单的交互
  • 业务组件对业务频繁变动须要做出疾速响应

低代码时代的全新挑战

无论咱们如何对待低代码的问题,低代码的浪潮正在不可逆转地到来。Gartner 预测,到 2024 年,65% 的利用开发流动将由低代码开发实现。越来越多的企业开始认可并承受低代码的工作形式,大型云服务厂商都曾经上线了本人的低代码平台。

在低代码时代,对咱们现有的物料体系提出了挑战:

  • 如何可能为低代码我的项目提供丰盛的物料?
  • 如何低成本将已有的物料接入到低代码我的项目中?

同时,咱们也有机会去思考,是否能够应用低代码技术去更高效、更高质量地生产业务物料。

这也引出了这篇文章外围要探讨的两个问题:

Q1:如何让物料为低代码援用服务?
Q2:如何让低代码技术为物料生产服务。

已有物料和低代码

首先咱们先探讨如何将已有物料疾速导入到低代码我的项目中应用的问题。在低代码时代之前,其实咱们曾经积攒了大量的物料,在低代码利用中,咱们心愿可能在组件面板中找到这些组件,并且能够配置这些组件的属性来应用。下图展现的是一般物料的应用文档和低代码利用中物料的配置界面。能够看出,一般物料和低代码我的项目的物料的差别次要在于,除了失常的组件渲染逻辑外,低代码利用须要物料的名称、形容、截图、logo 等信息,以及哪些属性能够供用户配置和更改。

既然是配置,就要有协定标准,只有在协定标准的领导下,才能够实现多个环节的最大协同,而不至于实现上出现分歧。在咱们开源的 LowCodeEngine 我的项目中,咱们也同步开源了低代码利用最重要的三个协定标准:「低代码引擎物料协定标准」「低代码引擎搭建协定标准」和「低代码引擎资产包协定标准」。其中「低代码引擎物料协定标准」就重点对物料形容配置进行了约定。

目前,咱们曾经有 1800+ 的组件,通过手写物料形容的模式接入了低代码我的项目中。继而咱们在思考一个问题,既然物料形容自身是一份协定约定的结构化数据,其自身是否也能够通过低代码技术来生产呢?这样能够进一步地升高组件接入低代码引擎的老本。

物料形容的可视化编排

咱们其实认真看下组件的属性配置局部,就会发现他其实也是一个经典的表单,继而咱们想到咱们能够通过搭建一个表单页面地形式来生成一份物料形容,只是这个表单里的每个组件表白的是一个属性的名称、类型、形容、设置等。咱们就能够把这样一份页面搭建的形容转换为物料配置的形容。

这是咱们应用中的平台界面,最终咱们应用这种低代码地形式生产了 1200+ 的物料形容,让这些源码组件能够疾速地进入到低代码利用中。

低代码生产组件

之前咱们次要探讨的是已有物料接入低代码我的项目中的思考和实际。接下来我想聊一下,如何基于低代码技术来生产组件,这也回应咱们后面对于物料现状的探讨,如何高效率地开发业务组件。

咱们后面有提到,业务组件通常是基于根底组件之上实现的,封装接口、业务逻辑进步复用性是他的次要场景,所以大部分没有简单的交互,但相比起根底组件来说,变更会更频繁。用低代码生产很洼地适应了这些特点,它具备极低的上手门槛,更高的研发效率以及对低代码我的项目人造的敌对性。

让咱们看看为什么这么说,对于上手门槛,首先低代码平台是齐全 web 端操作的,就跟拜访其余网站一样,不须要开发者筹备他的开发环境,如 node、python、git 等,随到随用。其次,他能够屏蔽很多开发的技术栈细节,如 React、Redux 等等,通过良好的封装性和精心降级的各种工具来实现组件开发中的各种细节(如属性配置、申请数据点等)。在研发效率方面,低代码生产组件不需建设仓库,也无需构建等环节,随到随开发,自身就非常轻量级,因而也能够更好地应答频繁变更的需要。因为自身是依附低代码开发的,低代码产生数据的结构性,也能够让他在定义属性的同时就做好了物料形容,因而能够间接在低代码利用中应用,而无需再经验咱们下面探讨的环节。

除了这些长处之外,他的轻量性决定了也更容易复制和扩大,他的全程平台化能够更好地保障代码的安全性,并且研发链路的多个环节能够管控,对于利用的品质和稳定性也会带来便当。同时他也不是只能在低代码利用中应用,咱们也能够导出成一个源码 React 组件,在源码我的项目中应用。

接下来咱们将具体探讨如何应用低代码技术生产出一个能够应用的组件。

组件是什么?

咱们要想实现组件生产到应用的残缺生命周期,首先要搞清楚组件是什么。前端组件并没有写进标准中的定义,但在前端大量的生产实践中,一个前端组件大多具备以下个性:

  • 封装性:逻辑和 UI 被封装在一个黑盒中,对外部使用者不可见,内部使用者也无奈间接批改被封装的逻辑和 UI。
  • 接口性:因为封装性的存在,这个黑盒须要裸露一些对外的接口,从而实现与内部的通信以及内部对组件的管制。
  • 切面性:组件从首次渲染到最终卸载过程中会经验多个阶段,通常状况下须要提供这些阶段的控制能力,如生命周期的概念。
  • 独立性:组件不用和利用的保护和发版保持一致,能够独立保护和发版。
  • 复用性:组件不会只被利用生产,自身应该能够援用其余组件或者被其余组件援用。

具备了这些个性的形象,咱们个别能够称之为一个组件。接下来咱们细化看一下为此咱们要实现的性能。

首先抱着协定后行的准则,咱们定义了一份低代码组件的搭建协定,用以驱动 UI 渲染。低代码组件的搭建协定和页面相似,但在他的根底之上次要减少了对于属性方面的定义。

在能力分层上,咱们将须要构建的能力分为四个档次。根底能力的局部是一个组件必备的局部,用于实现组件最根本的性能。加强能力则是有了之后会比没有的状况下更易用的局部。预览调试的性能用来帮忙用户开发地更顺畅。而公布生产则是在组件生产完结后如何给到我的项目中去应用。接下来咱们会对这外面的一些实现进行重点探讨。

属性的实现

属性是组件对外的接口,在低代码组件中,咱们能够通过可视化的形式来注册属性,包含属性的名称,形容,类型,应用哪种类型的设置器,以及是否须要联动等。这些设置能够主动转化为组件的物料形容。理论渲染的过程中,咱们创立了一种非凡的组件状态 props,组件内能够间接绑定 props,或者在逻辑块中通过 http://props.xxx 来获取。

生命周期

咱们规定了组件里五个最常见的生命周期用以实现组件的切面。这些切面,不同的框架可能有不同的实现,然而都必不可少。咱们在低代码组件的最外层容器组件上对这个五个申明周期进行实现。

预览和调试

咱们提供了两套开发调试环境,一套称为”预览“,在这个环境里能够简略地对属性进行批改,比拟轻量级。但无奈体验组件的设计态(组件被拖入我的项目设计态时的状态)。所以咱们还有另一套称为”调试“的环境,在这个环境中,咱们会帮忙用户创立一个模仿我的项目环境,并装置上这个组件。用户能够从设计态到预览态,残缺调试低代码组件的整个过程,并且能够和其余的组件进行联动。同时,调试的内容也能够用来生成 demo,供组件使用者查看

组件的生产

低代码组件在低代码利用中的生产,次要须要思考如何实现组件的封装性。

咱们实现了一个组件渲染器,相似页面渲染器,同样能够依据 schema 递归渲染节点。在注册组件的时候,通过判断组件是否蕴含 schema 信息来决定是否注册为低代码组件,低代码组件在页面渲染器渲染 schema 时会应用组件渲染器来渲染低代码组件。这样组件在页面设计器中会体现为只是一个组件,而不是外部打算的 schema,用户无奈对组件外部间接做批改,只能像应用组件一样通过批改属性来实现对组件的管制,从而实现组件的封装性。

相似的逻辑也能够复用到低代码组件援用低代码组件的场景中。

我的项目内调试

有些组件因为各种起因在我的项目内调试效率会更高,如申请域名限度,或者与其余组件联调。因而,咱们也提供了低代码组件在低代码我的项目内调试的能力。

源码组件是通过启动一个本地 server 的模式来和页面进行通信的,然而低代码组件只是一个 web 页面,如何做到相似的成果呢?咱们在这个过程中抉择了应用 BroadCastChannel 进行 Tab 间通信,当一个低代码组件的设计器被关上时,会告知页面有组件处于调试中。如果页面是后关上的,他也会通过这个通道询问目前是否有正处于调试状态的插件。建设链接后,当组件更新,就能够通过这个通道,告知页面最新的组件 schema,页面拿到后进行从新渲染实现实时调试。

援用其余组件

低代码组件领有本人的依赖治理能力,能够为每个依赖的组件指定版本和装置构建。在装置其余低代码组件的时候,咱们会将组件和被援用组件的依赖进行合并拍平,在这个过程中疏导用户进行抵触解决。

组件的版本治理

一个组件应该能够在不同时刻公布不同的版本,利用能够选择性地装置不同版本。低代码组件同样反对公布不同的版本,每个不同版本咱们会依据版本号,记录他的 schema,物料形容以及依赖配置。咱们还特意设计了一个调试版本 0.1.0,这个版本永远与线上最新的记录同步,不便用户进行利用内的调。

低代码组件和源码我的项目的联合

低代码组件作为组件的一种生产方式,不应该限度组件的生产场景。就像源码开发的组件能够在低代码我的项目中应用一样,低代码生产的组件也应该能在源码中应用。

在咱们的实际中,咱们应用 LowCodeEngine 的出码模块对组件的 schema 进行出码,转换为 React 代码,同时剖析组件的依赖以及物料形容,生成组件所需的 package.json,再补充其余的工程文件。组成一个残缺 React 组件脚手架,再利用这个脚手对组件进行构建公布,最终生成一个 npm 包。这个 npm 包其本质就是一个纯正的 React 组件,因而他能够在任何 React 我的项目中间接应用。

既然在源码我的项目中应用,那就会波及到如何在源码我的项目中调试。咱们不可能在一个迭代进行过程中,每次批改在源码中看到成果都须要进行一次出码,这样的效率是不能承受的。因而咱们在我的项目工程中设置了一个调试插件,通过这个插件,咱们能够自在切换组件是否处于调试模式。当处于调试模式时,咱们会将组件 alias 到一个通用容器组件上,容器组件会依据包名,找到对应的组件,并从云端拉取最新的 schema 进行调试。实现了不出码,也能够进行低代码组件在源码我的项目中的调试。

历史记录 & 容灾

在 schema 的存储逻辑上,咱们做了多层记录,其中包含以保留工夫为维度的云端存储「历史记录」,还有以间隔时间为维度的本地存储「容灾存储」。「历史记录」能够帮忙用户不便地切换至某次保留时的 schema,用于应答 hotFix,推倒重来等网络通信没有呈现问题时的批改。「容灾存储」则会定时在本地记录用户的 schema,这样当平台的网络呈现问题时,用户的批改也不会失落,只是临时没有与云端进行同步,能够等到网络复原时再从新实现同步。

服务化

比起页面,模块在日常的前端开发里更为常见,模式也更为多样,很多逻辑的形象都能够以一个模块的模式存在。

咱们也粗浅地意识到,不可能通过一个低代码组件平台承当所有的模块类低代码生产诉求。咱们心愿能够通过提供一整套的服务化策略,来让业务基于通用版本,定制出合乎各自业务特点的低代码模块生产工具。这外面包含了相干的设计器插件,配套的后端服务,开箱即用的治理后盾模板,以及用于渲染低代码组件的运行时 sdk。通过这一整套的工具,开发者能够很疾速地搭建起本人的低代码组件平台,并且在此之上进行定制。

下图,是咱们业务中的一个实际,应用服务化的低代码组件构建了一个钉钉音讯卡片的搭建平台。尽管两者在生产和生产链路上都有很大差别,但依然能够基于同一套底座开发进去。

目前的成绩

目前通过低代码的形式,曾经产生了超过 3000 个组件,并利用于超过 900 个利用当中。在新增的组件中,有超过 48% 的技术选型抉择了低代码组件,在咱们的实际中低代码组件曾经成为一种重要的技术选型形式。

将来打算

咱们初步实现了对于如何通过低代码模式更好地与业务组件想联合的模式,将来咱们的方向会向更深更难地畛域进军。有三个明确的摸索方向:

  • 面向多角色的协同:P2C/D2C/C2D 等与产品、设计实现更高效率的协同
  • 简单交互能力加强:动效、手势、拖拽等简单交互场景的封装
  • 组件品质保障:代码标准查看、Code Review 和 自动化测试。

通过这三个方向的进一步欠缺,心愿可能进一步地扩充低代码组件能够承接的业务边界,让模块生产低代码化成为一种新常态。

原文链接

本文为阿里云原创内容,未经容许不得转载。

退出移动版