凌晨一点，又在折腾第三方的低代码平台。
组件库对不上，风格千篇一律，想加点定制逻辑就得投降。
真是憋了一肚子火。
其实早就想写这段了，今天终于忍不住。
因为我也踩过一模一样的坑。
我们团队的需求其实很简单：中后台系统，审批流程，数据看板。
结果市面上找了五六家，没有一家完全满意的。
存在这样的情况，有的是在云端进行部署时数据存在不安全的状况，有的是代码被锁定以至于无法进行变动修改，有的是年费高昂到极其离谱的程度。
老板问我怎么办，我说要不自己搞。
他就瞪着我：“你疯了？你以为低代码是随便玩玩？”
但我是真受够了。
拖拽出来的东西看着快，上线全是坑。
而且这就像木桶，你提这种需求它缺这块，提那种需求它缺那块。
根本没用。
所以最后的答案就是：把源码捏在自己手里！
React低代码平台源码哪家强
先说说市面上能拿到源码的主流选择。
有个名为阿里的主体，将进行了开源操作，在这个平台之上，它拥有15k+的Star数量，它属于真正的企业级引擎。
其架构采用的是“微内核 + 插件”这种模式状态，涵盖了物料接入这一环节，还有可视化编排这一方面，以及UI渲染这一要点，另外包含代码生成全链路能力这一整体情况。
对 React、Vue、Rax 这类框架提供支持，最终所生成的代码，不只是具备很强的特性，同时还是那种干净且易于维护的态势。
没错，它存在热度也是必然，可是学习所需成本着实不低，需要去花费时间将协议规范透彻掌握。
如果你想要那种轻量级快速上手的，推荐 Puck。
它属于模块化的那种，是针对React的可视化编辑器，其自身乃是有着合规标准的React组件。
你能将其毫无缝隙地嵌入你目前所拥有的任意 React 项目之中，不用去做架构方面的改造工作。
存在着更为轻巧的brick-，它是依据React组件来开展可视化拖拽操作的。
所见到的就是所能够得到的，对PC以及手机型号的效果展示予以支持，模板功能还具备能够减少重复操作的作用。
比如，这是一个基于React的开源低代码框架，通过拖放的方式来进行搭建，其主要侧重于内部工具的快速开发。
但也需要提及一下 ，它有着这样特定的定位，那就是“面向开发者的开源 React 框架”。
尽管它并非纯粹的低代码工具，然而作为所谓的“低代码替代方案”，它协助你去做诸如 CRUD、认证、权限等这些重复性的工作，并且还能够让你保留 100%的代码控制权。
选哪个？没有标准答案，关键看你什么场景。
React低代码平台源码怎么读
很多人一拿到代码就懵了，拖拽那么多文件，到底怎么下手？
我跟你是同样的情况，最初的反应也是如此。随后才弄清楚，九成的React低代码引擎核心逻辑环绕着一套系统运行。
是什么呢？大概而言，就是运用一份JSON数据，去对整个页面呈现出来的样子进行描述。
比如说，在阿里当中的某一个按钮，最终所呈现出来的输出结果便是如此这般的：
{
"": "Page",
"": [{
"": "",
"props": {"text": "Click me"},
"": {"": "alert('Hello World')"}
}]
}
从上面开始朝着下面去寻找，通常是从构建引擎也就是以及渲染器那里看起。
构建引擎承担着将 JSON 进行转化的职责，转化的结果是能运行的 React 组件树。
渲染器负责拿到数据把界面上显示出来。
要是计划去看一个更为完整的实例，那么推荐蚂蚁这家的开源文章，它是基于Ant 、React 18、以及Vite来搭建的。
它有着这样的架构，架构被划分成三层，其中一层是协议层，协议层运用JSON 去定义“数据契约”，还有一层是编辑层，编辑层承担着可视化拖拽的职责，最后一层是渲染层，渲染层开展动态映射的工作。
看过这一套，你便会明白，低代码仅仅是将“编写代码”转变为“进行拖拽可视化以及配置化”，其本质是相同的。
甚至更费脑子。
React低代码平台源码开发的痛点
这里必须泼一盆冷水。
好些人觉得，拿到了 “React低代码平台源码”，我便无需再编写代码了。
天真！
低代码平台不减少复杂性，它只是重新分配了复杂性。
传统开发里，复杂度分散在每一行代码里。
到了低代码环境，复杂度全压在设计平台和建模的阶段。
三大致命痛点，谁都躲不开。
第一，复杂逻辑直接瘫痪。
你想做个金融风控？想解析工业设备的复杂协议？
传统平台靠预设模板生成 CRUD，根本接不住。
风控规则引擎这些复杂业务，你最终还得跳出去手写代码。
这样低代码反而成了摆设。
第二，生成本身带来的失控。
很多平台生成的代码和你的设计模型是脱节的。
改一次需求你在可视化界面和编辑器里来回切，切换得想吐。
数据不同步，迭代成本高得吓人。
第三，全栈开发的串联是灾难。
前后端之间、设计和开发之间有数据断层。
低代码把前端生成得快了，后端对接不上白搭。
API 调试时间比写代码还长。
看懂了吗？
源码虽然给你了白盒，但并不是说拿到了就圆满。
核心的区分界限在于，架构的边界是不是清晰，行为可不可以进行预测，能不能于你所需要的时刻插入切实的原生逻辑。
为什么你必须懂源码底层
好，现在已经分了四个小标题，都是你会搜索的。
我在接下来的时间里，想要谈论一个或许不太适宜于公开表述的观点，然而呢，鉴于这是一场比赛，所以我就没有什么顾虑了。
大量的低代码平台最终会沦落到一个死循环。
什么循环？
因平台有着要降低非技术人员使用门槛的需求，故而会确定一套固定的“标准功能”。且这一套“标准功能”是被固定的那一种。
举例来说，这就如同给予你100种色彩的画板，然而却仅仅准许你绘制那种中规中矩的画作。
当你真正要做一个带独立品牌、特殊交互风格的应用时。
不好意思，越界了。
但你再看看 React 这类框架的思路。
它不生产黑盒，它生产“无头组件”（头显）。
那是什么意思呢？是他们给了你，一堆用于处理的东西，以及定制UI的Hooks，还有组件工具。
它不限制你的界面长什么样，数据流逻辑怎么走。
low-code 但【对开发者友好】。
我们真要的无非就是：既要拖拽快，又要有完全的代码掌控权。
最后说几句真心话
其实我知道看这文章的人都在找捷径。
想要用最少的代码，交付最复杂、最强大的页面。
低代码如果在这个目的，肯定没错。
但我从源码里面刚摸爬打滚爬出来，真正的感受却是：
宁愿在他人所设框架内艰难地进行妥协，也不要于巨人肩膀之上修补自身的补丁。
拿到源码的那一刻，别以为结束，那才是挑战的开始。
认识 的逻辑，装配自身的业务组件，确立好团队开发规范。
否则，即便拿到了数量众多的有着 Star 的项目代码，仍旧 是另起炉灶，换来另外一个崭新的 “坑。”。
凌晨三点，快扛不住了，今天先骂到这里。
老铁点个赞再走，明天一起肝！
