关于前端:关于前端低代码的一些个人观点

2022，低代码彻底火了，甚至火到没有点相干教训，都不好意思进来面试的水平，堪称 lowcode“元年”。在整个互联网大裁员的背景下，无论你是否置信它是降本提效的利器，彷佛都不重要了。因为行业趋势总是这般浩浩荡荡，是不以集体意志为转移的。从下图某技术峰会的分享主题中就可见一斑。

刚好笔者最近正在开发一个 B 端低代码的平台。所以，想把这段时间的感悟整顿一下与大家分享一些。不过，结尾先申明一点，本文只聊观点与感悟，不聊具体技术细节。低代码的产生背景互联网产品趋于标准化据我察看，有相当一部分的程序员一提起低代码就点头 say no，示意已经被这些低代码平台“挫伤过”，因为产品需要一旦波及平台暂不反对的性能，轻则导致加班返工，重则绩效堪忧，甚至丢了工作。这是一个新事物倒退初期必经的一个阶段: 与现有环境水土不服。如果站在更高的角度，构想一下: 当有一天，你的老板发表，产品经理当前提的需要一律不得超出低代码平台反对的能力范畴时，该作何感想。不要轻易说不可能，因为资本的实质就是追赶利润，如果因为这些非标需要额定付出的开发成本，发明不了预期的收益，那对那些试错老本宽容度较低的团队而言，这些需要齐全没有存在的必要（回头想一想，你的产品经理提的那些奇奇怪怪且上线没几天就又改回去的需要，你真的认为有价值嘛）。理解点软件外包行业的都晓得，很多外包订单都是先 copy 一个个的模版我的项目，在之上稍加改变即可交付。因为和他们对接的大部分客户需要都很标准化。比方，客户须要开发一个 H5 商城，商品、订单、物流再加一个商品经营后盾就齐全能够满足需要了，甚至不在意 UI 的款式与竞品截然不同。不过这里也不排除有定制化开发的报价相比齐全套模版会高出一大截的因素，但这也至多阐明这些非标需要是精益求精的性能，基本不是刚需。其实大厂也有这个趋势。毕竟各厂的业务范围越来越呈现穿插的态势，产品层面也都是相互 copy，真正具备创新性的产品越来越少。C 端的产品，尤其在一些大厂充沛竞争或者劣势的业务畛域，因为要谋求 UI 设计、交互、产品体验的差异性，所以绝对不容易标准化。比方每年双 11 的促销各家要紧跟潮流，玩法每年都不尽相同，这种就很难标准化。但大部分的 B 端产品，对定制化要求不高，随着产品模式的固化，用户未然造成了一套约定俗成的交互习惯。利用开发的技术栈趋于成熟就拿前端出活的主力:js 框架来说，vue、react 尽管还在大版本的迭代，但对整个开发方式的影响，曾经不足以与 15、16 年 jQuery 到古代框架的那种革命性等量齐观了。更多是一些类如更灵便的逻辑拆分、服务端渲染等方面的优化。针对前端开发中的痛点，拆分出的比方构建工具、前端框架、框架之上的 UI 组件库、跨端等等各个技术畛域的边界，也都划分的比拟明确了，且倒退日趋成熟。这是前端低代码呈现的技术背景。前端低代码实现笔者对低代码的了解是: 能够通过配置化的低成本交互方式（支流是拖拽）加上大量的一些胶水代码，去满足一类利用的需要。这里笔者以倒退更加成熟的 B 端低代码讲述，C 端也是很相似，然而因为款式、动画等定制要求要比 B 端的简单许多，所以目前前端低代码绝对成熟的利用是在 B 端。低代码实现原理其实非常简单，就是先预置丰盛的原子组件，通过拖拽抉择所需组件在画板上进行地位的编排。之后，进行一些组件属性的设置。

最终生产出一份 jsonSchema 或者供开发者二次开发的“源代码”，驱动用户端的内容渲染。原理尽管简略明确，但它也有一些实现难点。比方以下几种：一、宏观设计首先设计一个可能面向不同业务场景的低代码我的项目，是个不小的挑战。
比方一个公司级别的低代码我的项目，指标是赋能各条业务线。这个就会有一个问题：每个业务对低代码平台的能力要求是不同的，除了大量可复用的性能，必定也会有不少的定制化需要。甚至各条业务线的产品状态很不统一，有面向 C 端的，有面向 B 端的。如果是中心化的思维，一套低代码平台，满足各业务线的需要，首先人力老本很难均摊上来，其次平台随着接入业务线增多，不可避免的会变得臃肿不堪，难以保护。如果每个业务线都独立做一套合乎本身业务个性的低代码，这样难度会升高不少，但也意味着公司级别的低代码物料复用变得艰难。
讲下业界目前比拟风行的解决方案：在公司级甚至业界推动低代码协定对立。这样就让跨业务甚至业界的物料复用变得可能，阿里前端委员会为此付出了不少致力，大家有空能够理解下。将低代码架构分层。先有一个低代码基础架构，再用它去“生成”一个个面向具体业务场景的低代码平台。那么如何设计好这个“生成低代码平台的低代码平台”就成为了重中之中。这有点相似于低代码“中台”与“前台”的关系。二、实现细节事件编排下图就是目前最常见的一种设计，能够配置点击一个 button 时，要触发哪种类型的事件，事件触发要调用哪些函数，个别都会内置一些比拟常见的函数，比方关上一个 Modal 框等。如果内置不满足需要，就须要插入一些定制化的代码。状态联动这个绝对好解决一些。阿里的 formily、x-render、jsonschema-form 等这些成熟计划的都可能解决，他们之间的差别更多的是在联动性能上，不过这也是在超长表单场景下差距才会比拟显著。以下是阿里 lowcode-engine 的交互设计。

这个平台内置的绝对简略。我接触过的内置绝对丰盛的是 iofod 这个全场景低代码平台，这里为他们的开发者打个广告。笔者还与他们的开发者加了好友，吃惊的是这么大的工作量居然是一个人实现的，体验下来比很多公司团队级的产品都用心。

异步数据绑定传统的前端开发大量工夫其实是花在与后端接口的对接上，这些工作在目前前端低代码的开发模式中，一点都不会少。如下图，你须要一个表单回填的性能。后端给的详情数据，与前端表单须要的格局差别很大，这里就不得不去手写一个转换函数去解决。

这也是低代码平台大家诟病最多的一点，即：还是须要写代码。然而低代码的价值，素来就不是谋求一行代码不写，而是让开发者尽量的少写代码。有人说，我 copy 代码其实来的更快，而且这性能我开发起来很熟，代码不会有任何问题。然而，你是不是常常在提交 cr 之后，又悄悄的 commit 了几个 fix 呢。最可怕的是测试也感觉这性能很常见，不必细测了，将隐患带上了线。试着回顾一下过往我的项目的 bug 列表，是不是很多都是因为不经意的走神或者忽略造成的。这就是低代码目前就可能解决的一个问题，通过内置一些常见的性能，缩小常见性能的开发、测试老本。使大部分性能的交付品质，不依赖于某一个开发者在某一段时间的开发教训、精力及程度。这是笔者认为，现阶段低代码技术的最大价值。