大厂的前端面试——低代码混合

最近参加了一家大厂的前端面试，我向面试官介绍了我开发的低代码平台，并说明这个平台的产出物是完整页面 。但他告诉我，在他们公司的实际使用场景中，低代码的使用方式非常克制------他们并不生成整个页面 ，而是只产出组件。

这些组件不会独立运行，而是被嵌入到用手写代码开发的应用中。也就是说，整个页面由两部分组成：

面试官问：低代码平台要怎么实现才能支持这样的混合模式？

我的回答是：

低代码平台的改动很小，如果低代码平台生产局部模块，它们可被页面载入，我们需要考虑：怎么将模块与页面关联。

换句话说，一个页面可以有多个模块，当页面被访问时，怎么确定该载入哪些模块？

借这个问题，我想进一步谈谈"低代码混合"的业务场景，以及它背后的实现逻辑。分两种情况：

回顾：低代码生产整个页面

在前端开发中，有一个基本的认知------每个页面都对应一个路由。如果低代码生产页面，我们可以很自然的想到，将路由与 ID 绑定，访问路由就能得到页面的 Schema。一旦拿到 Schema，就将其传递给渲染器，由渲染器将该 Schema 所描述的页面动态渲染到界面上。流程图如下：

要实现低代码与零代码的混合，首先要做的是，将低代码产出的模块接入零代码平台。这种混合模式在数据类平台中尤为常见。

以一个典型的数据分析页面为例：

页面通常包含多个图表模块，这些模块可以由低代码平台生成。最终的页面结构与内容，则由使用者在零代码平台中自由编排------他们根据业务需求选择需要展示的模块，并支持保存页面配置以供日后查看或复用。

在这种模式下，低代码平台产出的每个模块都有一个唯一的 ID。当模块被添加到页面中时，系统会将该模块的 ID 与当前页面进行关联。

为了支持这种混合渲染的能力，我们需要对渲染器进行改造，使其具备两个核心能力：

在"低代码与零代码混合"的场景中，低代码模块通常以较固定的布局嵌入到页面中。它们显示的位置是预设的，往往仅占据页面中的一个特定区域，以固定数量的列，自上而下排列。

这种结构下，前端只需维护一个低代码模块的 ID 列表，遍历该列表，并将每个 ID 依次传入改造后的渲染器，便可完成多个低代码模块的注入与渲染。

相比于与零代码的混合，低代码与手写代码的混合方式具有更高的灵活性。

这种灵活性体现在：

低代码模块在页面中的位置、尺寸乃至加载时机，都不再固定。开发者可以通过手写代码动态控制模块的布局方式，样式表现，甚至根据上下文决定是否渲染某个模块。

这使得低代码能被灵活的嵌入到复杂页面中，成为整个系统的一部分，而不是一个静态组件集合。

这种场景，渲染器依然具备两个核心能力：

与零代码平台的集成方式不同，在这里，渲染器所需的模块 ID 由页面开发者在手写代码中显式传入。这为模块的加载时机、展示位置等提供了更大的灵活性，也要求开发者对模块的使用有更强的掌控能力。

我是何遇，感谢你读到这里。愿这篇文章为你打开一个新的视角，看到低代码在不同业务场景中的灵活运用。欢迎关注我，一起继续深入探索低代码的更多可能。