背景作为前端开发者，你可能已经熟悉现有的前端框架和工具，但随着数字化转型的推进，越来越多的企业需要更多快速高效地构建您自己的应用程序。一个低代码平台可以成为我们前端开发人员解放生产力的神器。低代码平台为用户提供可视化界面、拖拽式组件、自动生成代码等功能，让用户无需编写大量手动代码即可更快速地创建应用。在我的团队中，我负责社区、用户、品类等所有运营相关业务的前端研发。此类业务（业务）具有以下特点：时效性短、变化快、频率高。运营活动的生命周期从1天到1个月不等，部分内容需要根据活动反馈实时调整，活动不同阶段有不同的页面（比如比赛的运营活动）)，以及负责每个模块的运营人员每周甚至每天，你都有自己的活动需要上线发布，需要投入大量的开发人力来满足运营需求。非常互动。通常，为了增加用户活跃度，运营会推出很多互动活动。例如，以彩票活动为例。页面上会有很多区域来引导用户做任务。这些任务有的在页面上，有的在其他页面上。通过完成任务，可以兑换抽奖次数，引导用户参与抽奖，消费抽奖。频率。从整个页面的流程来看，交互逻辑要比展示类页面复杂。因此，基于这些特点，我们可以确定以下目标：满足运营活动频繁迭代的场景，解放开发人员的生产力，需要支持交互逻辑更复杂的场景。基于此，我在团队内部开发了一个低代码平台来服务我们的运营团队。平台上线近一年，已产生500+有效页面。按照2天+/人的平均工作时间计算，至少节省了1000+天/人。本系列将结合本人在开发低代码平台时的思考和实践，详细介绍低代码平台涉及的概念和技术。目前介绍UI配置实现（如何生成页面UI）的low-code相关文章很多，这里先介绍low-code的另一个核心模块：逻辑配置。（我也会在系列后续文章中写UI配置）注：以下文章中的运营人员指的是平台用户（非开发者）。逻辑配置在低代码平台中，逻辑配置是指通过可视化界面配置不同的业务逻辑，而无需编写大量代码。通过UI配置生成的静态页面可以理解为HTML+CSS，没有任何交互逻辑。然而，目前几乎很少见到纯静态页面，通常使用JavaScript代码为页面添加交互逻辑。所以逻辑配置在整个低代码系统中的作用就是让用户在页面内进行交互，比如关注用户，跳转页面等。历史版本Version1：交互逻辑包组件是开发的版本快速启动和使用的早期阶段。交互逻辑内置在组件中，这意味着逻辑和UI是高度耦合的，所以这个版本是开发者维护起来最难受的版本，但也是运营商认为最好用的版本。优点：对操作人员来说，精神负担小，容易上手；对开发者来说，实现难度低，可以快速支持上线缺点：高度封装，可扩展性差，难以支持稍微复杂的交互逻辑，更难维护版本2：表单UI用于线性流程表单操作，并将数据显示为流程图。属于DAG过渡版本，这个版本已经具备了很高的可扩展性。优点：触发器和事件解耦，支持触发器和事件的排列组合，可扩展性强。缺点：不支持分支逻辑，无法进一步处理更复杂的场景。同时，要求操作人员熟悉业务流程，表单交互体验不够友好。Version3:DAG(Latest)DAG，DirectedAcyclicGraph，H5活动配置平台最新的逻辑配置方案。为什么要使用DAG？回到版本1——交互逻辑封装了组件，为什么运营商认为这个版本是最好的版本？因为上手几乎没有难度，您只需要在指定的输入框中填写业务参数即可。比如要实现跟帖流程，只要在输入框中填写被关注用户的uu和跟帖后的按钮复制，即可实现跟帖交互。这样做所能付出的代价是，开发者要承担组件中难以维护的交互逻辑，组件库的更新迭代带来的成倍增长的研发成本，以及产生的冗余代码实现复杂的逻辑过程。因此，与UI配置不同，逻辑配置完全且必须由开发人员主导。基于版本1的研发痛点，提出了版本2——线性过程形式。所有耦合到组件上的交互逻辑都会被解耦分离，逻辑被拆解独立成为一个事件（handler），它是逻辑执行的最小单元。至此，逻辑配置和UI配置在研发层面已经解耦，交互逻辑也被拆解成独立的可执行单元。基于全新逻辑配置的架构设计具有以下优势：支持扩展任意事件，目前支持的事件包括用户关注、页面跳转等常规事件，以及抽奖、投票、游戏角色等更具交互性的事件选择器等事件。逻辑配置将提供标准的事件规范（EventSchema）。通过解析基于标准事件规范生成的数据，然后编写相应的事件逻辑JavaScript代码，即可被逻辑配置模块识别并执行，因此只要规范基于Write，任何你需要的事件可以添加到逻辑配置中。从以往的实践来看，在开发业务逻辑时（比如做其他业务需求时，只是为了实现以用户为中心的方法），如果是基于标准的事件规则开发，是不会影响在业务开发中使用的，而可以直接被逻辑配置识别，提供给H5活动配置平台的所有用户。一石二鸟，可以说是上乘之作。触发器与事件解耦。触发器作为标识符存在，用于标识用户的操作。当命中触发行为时，会执行匹配的交互逻辑。需要注意的是，这里的交互逻辑并不是再次硬编码，而是遵循标准逻辑规范（LogicSc??hema）创建的数据。以此为基础，可以实现触发器和事件的排列组合，生成各种复杂的交互逻辑。但是如果运营商想根据不同的情况进一步实现更复杂的交互逻辑，版本2的线性流程形式是无法支持的。比如判断一个用户是否关注某个作者，如果关注则展示文案A，否则展示文案B。另外，线性流程形式的本质还是形式。虽然尽可能接近流程可视化的方向，但本质上还是一种形式，无论是用户体验还是视觉效果都不好。基于版本2的业务和体验痛点，提出了版本3——DAG。想法来源于游戏开发领域的蓝图概念：IntroductiontoBlueprints|虚幻引擎4.27文档。我在思考和理解Unreal和Unity作为游戏引擎如何帮助不熟悉C++或C#的游戏设计师通过Blueprint实现游戏脚本；同样，作为开发者，如何帮助不熟悉编程的运维人员实现交互逻辑。在研发成本方面，DAG是三个版本中最高的。version3解决方案融合了前两个版本的一些核心思想和实践，进而进行了新的逻辑配置架构的整体设计和开发。首先，DAG的使用大大提升了体验。交互式图形界面可以更清晰直观地展示交互逻辑的内部组成和关系。同时，逻辑分支的支持使得基于不同情况的复杂业务场景可以通过配置完成，而无需开发人员进行开发。版本1是为了满足快速启动和上手的实际需求；版本2是为了提高研发效率；第三个版本是解决基于业务场景和交互体验的问题。从版本1到版本3，每个版本的提出和开发都在循环逐步优化和完善逻辑配置模块。到了版本3，似乎从研发到业务，目前的逻辑配置已经相当完善，但是作为开发者，很容易忽略一个问题，就是从运营者（非开发者）的角度)，使用这套工具会有多大的精神负担。版本1是基于运维人员的角度实现的，所以不存在这个问题，但是对于开发者来说，需要面对的是难以维护的代码和扩展性极差的模块。从2.0版本开始，为了从开发者的角度提升研发效率，1.0版本进行了大幅度的重构，重新梳理了原有的操作员友好的业务流程，增加了操作员的精神负担。因此，虽然版本2在研发层面解决了一些问题，但对于运营商来说，用户体验却变差了，因为在版本1中，业务流程是运营的黑盒，完全由开发者自己决定。封装实现，对外只保留关键字段的表单输入。对于大多数运营商来说，虽然可以描述业务场景，但是很难将业务场景抽象成具体的业务流程。如何减轻抽象业务流程带来的精神负担？首先，这个问题不可能是技术问题。开发者不能否定这个方案，因为2+版本的新方案会给运维人员造成一定的精神负担，因为总体来说，带来的收益明显高于1版本，肯定是高的，精神负担的问题不是无法解决，但不是从技术层面解决，而是从业务层面解决。从版本1->版本2，业务流程抽象的负担并没有消失，只是从开发人员转移到了运维人员身上，而这种转移会放大负担，因为大多数开发人员比运维人员更清楚如何去抽象业务流程，在一定程度上，这是开发者研发过程的一部分。因此，如何让开发者完成业务流程抽象，并在没有版本1的情况下提供给运营商，是值得思考的问题。我提供的解决方案是模板化，就是开发者将一些常见场景的业务流程抽象成模板，分享给运营商。运营商只需填写指定的业务参数，或根据模板任意扩展。这既保留了2+版本扩展性强、业务场景覆盖广的优势，又符合1版本开发者抽象业务流程，运维人员只填写业务参数的流程。BlueprintUpload（模板上传）：BlueprintMarket（蓝图市场）：所有工具都有学习成本。覆盖的场景越多，学习成本就越高。开发者能做的就是尽可能的降低这个成本。逻辑配置UI方案对比BlockyBlocky是一种基于图形化编程语言的编程工具。它采用拖放式编程方式，使编程简单易懂，适合初学者或儿童使用。目前，一些低代码平台使用Blocky作为逻辑配置的UI。其主要特点包括：图形化编程：Blocky通过拖动和连接图形块来构建程序，避免了手写代码的繁琐和复杂，让编程变得更简单。直观易懂。可视化编程：Blocky采用可视化编程方式，使编程更加有趣生动，适合儿童和初学者学习。开放性：Blocky是一种开放的编程工具，可以轻松扩展和定制。用户可以根据需要添加自定义块或扩展程序功能。跨平台支持：Blocky可以运行在多个平台上，包括PC、Mac、Linux、Chromebook等，支持多种编程语言。教育应用：Blocky是一款非常适合教育应用的编程工具。可以帮助儿童和初学者了解编程的基本概念和原理，提高编程能力和逻辑思维能力。虽然通过可视化降低了难度，但本质还是一个编程工具。对于开发者来说，都有一定的学习成本，更不用说运营商了，平台的主要用户还是运营商。如果是为了实现复杂的逻辑而需要生成源码，或者是非面向业务的开源平台（比如Low-CodeEngine），那么开发者直接写源码会更快。我个人认为这是一个不讨人喜欢的解决方案。相关链接：Blocky：https://blockly.games/Scratch：https://scratch.mit.edu/Form这类UI由输入框+按钮等表单组件组成。通过填写表单完成逻辑配置。也是目前比较常见的实现逻辑配置的方式。逻辑配置的常规UI方案，开发成本低，开源社区有很多表单方案（formily，form-render）库。一般有线性形式和嵌套形式两种形式。上面介绍了线性形式，不再赘述；嵌套形式是线性形式的进一步实现，用于处理分支场景。本质还是形式，通过逐层嵌套的方式来处理分支的情况。这确实解决了线性形式无法处理分支场景的问题，但同时也引入了新的问题。复杂业务场景下嵌套超复杂表单的视觉体验，可能需要滴眼药水才能坚持看完整个配置逻辑（如上图，这里还是没有任何其他逻辑，只有分支）。逻辑蓝图配置效果相关链接：AMIS：amis-低代码前端框架Low-CodeEngine：阿里低代码引擎DemoDAGBlocky学习成本，线性形式不能支持分支，嵌套形式对复杂场景不友好。基于游戏开发领域的蓝图理念，最终选择DAG作为逻辑配置的UI方案。其他内容我就不赘述了，见上文。
