前端低代码-少写代码实现灵活需求
低代码开发定义
低代码开发，是⼀种开发模式，通过图形化⽤户界⾯来配置和创建应⽤软件，⽽不是⽤传统模式那样主要依靠⼿写代码。对应的，提供给开发者的这类低代码开发功能实现的软件，称为低代码开发平台(LCDP)。低代码开发模式的开发者，通常不需要具备⾮常专业的编码技能，或者不需要某⼀专门领域的编码技能，⽽是可以通过平台的功能和 约束来实现专业代码的产出。
从定义中我们可以看到，低代码开发的⼯作⽅式主要依赖操作图形化的⽤户界⾯，包括拖拽控件，以及修改其中可被编辑区域的配置。这种可视化的开发⽅式，可以追溯到更早的 Dreamwaver 时期。⽽随着前端项⽬的⽇趋复杂，这种⽅式已不再适应现代项⽬的需求，于是渐渐被更专业的⼯程化的开发模式所取代。
开发途径
但是，快速⽣成项⽬代码的诉求从未消失。⼈们也慢慢到了实现这个⽬的的两种路径：
⼀种是在⾼度定制化的场景中，基于经验总结，到那些相对固定的产品形态，例如公司介绍、产品列表、活动页⾯等，开放少量的编辑⼊⼝，让⾮专业开发者也能使⽤。下⼀课介绍的⽆代码开发，主要就
是⾯向这样的场景需求。
另⼀类则相反，顺着早期可视化开发的思路，尝试以组件化和数据绑定为基础，通过抽象语法或 IDE 来实现⾃由度更⾼、交互复杂度上限更⾼的页⾯搭建流程。这种项⽬开发⽅式通常需要⼀定的开发经验与编码能⼒，只是和普通编码开发⽅式相⽐，更多通过操作可视化⼯具的⽅式来达到整体效率的提升，因此被称为低代码开发。
在实际场景中，尤其是商⽤的低代码平台产品，往往提供的是上⾯两种开发⽅式的结合。
基于编写 JSON 的低代码开发
当我们去审视⼀个项⽬前端部分的最终呈现时，可以发现：
⼀个项⽬的前端部分本质上呈现的是通过路由连接的不同页⾯。⽽前端开发的⽬标就是最终输出页⾯的展⽰与交互功能。
如果学过浏览器基本原理，你会知道：每⼀个页⾯的内容在浏览器中，最终都归结为DOM 语法树（DOM Tree）+ 样式（Style）+动态交互逻辑（Dynamic Logic）。
在组件化开发的今天，⼀个规范定义的组件包含了特定功能的 DOM ⼦树和样式风格。因此页⾯的内容⼜可以定义为：组件树（Component Tree）+ 动态交互逻辑（Dynamic Logic）。
⽽基于 JSON-Schema 的低代码开发的切⼊逻辑是：
在特定场景下，例如开发中后台增删改查页⾯时，⼤部分前端⼿动编写的代码是模式化的。
页⾯组件结构模板和相应数据模型的代码组织，可以替换为更⾼效的 JSON 语法树描述。
通过制定⽤于编写的JSON 语法图式（JSON Schema），以及封装能够渲染对应 JSON 语法树的运⾏时⼯具集，就可以提升开发效率，降低开发技术要求。
编写 JSON 开发的⾼效性
编写 JSON 语法树开发的⾼效性体现在：
由于只⽤编写 JSON ，⽽隐藏了前端开发所需的⼤量技术细节（构建、框架等），因此降低了对开发⼈员的编码要求，即使是⾮专业的开发⼈员，也可以根据⽰例和⽂档完成相应页⾯的开发。
由于只⽤编写 JSON ，⼤量的辅助代码集成在⼯具内部，整体上减少了需要⽣成的代码量。
可以对中后台系统所使⽤的常⽤业务组件进⾏抽象，然后以⽰例页⾯或⽰例组件的⽅式，供⽤户选择。
编写 JSON 开发的缺点
但另⼀⽅⾯，这种⽅式也存在着⼀些不⾜：
输⼊效率：单从组件结构的描述⽽⾔，使⽤ JSON 描述的代码量要多于同等结构的 JSX 语法（参见⽰例代码 07_low_code），对于有经验的前端开发者⽽⾔，通常⽆法第⼀时间感受到效率的提升。
学习记忆成本：由于引⼊了新的 JSON 语法图式，⽆论对于前端开发者、后端开发者还是⾮专业的⼈员来说，上⼿的学习成本都不可避免。此外，不同组件存在不同属性，要在实际编写过程中灵活运⽤，对记忆量也是⼀个考验。⽽反复查阅⽂档⼜会造成效率的下降（对于这个问题，有个优化⽅案是利⽤ IDE Snippets 的选项功能⽣成对应的语法提⽰）。
复⽤性和可维护性：对于多页⾯存在可复⽤业务组件的情况，在 JSON 编写的模式下往往需要⼿动复制到各页⾯ JSON 中，牺牲了复⽤组件的可维护性。此外，对于功能复杂的页⾯，对应的 JSON 长度也会让维护体验变得不太美好。
问题排查难度增加：这个问题涉及⾯向⼈，如果是⾮专业的⼈员从事 JSON 的开发过程，当遇到问题时，在如何排查上可能造成阻碍，因此通常需要配备额外的专业⼈员来提供技术⽀持。
基于可视化操作平台的低代码开发
可视化的低代码操作平台把编写 JSON 的过程变成了拖拽组件和调试属性配置，如下图所⽰，这样的交互⽅式对⽤户来说更直观友好，开发效率也会更⾼。
可视化操作平台的基本使⽤⽅式
前端页面模板绝⼤部分的可视化操作平台都将界⾯布局分为三个区域：左侧的组件选择区，中部的预览交互区以及右侧的属性编辑区。这三个区域的排布所对应的，也是⽤户⽣成页⾯的操作流程：
⾸先，在左侧⾯板中选择组件。
然后，拖⼊中间预览区域，并放置到合适的容器块内。
最后，调试右侧⾯板中新移⼊的组件属性。
调试完成后，进⾏下⼀个组件的循环操作直到整个页⾯搭建完成。
可视化操作平台的⽣产效率影响因素
通常来说，在组件数量不变的情况下，编写 JSON 的产出效率更⼤程度上取决于编写页⾯的开发者的技术熟练度。但在使⽤可视化操作平台时却并⾮如此：我们会看到，平台本⾝的很多⽅⾯也会直接影响使⽤者的产出：
⾸先，平台的功能完备性直接决定了⽤户产出的上限：开发者不可能在平台⾥使⽤组件区没有显⽰的组件，也不可能创建编辑区不存在的属性。这就迫使平台开发者需要尽可能完整地陈列所有类型的组件，以及通过定义组件类型描述，来获取所有可以被编辑的属性和⽅法。包括⽤户交互和数据对组件的影响，这些都需要平台以合适的使⽤⽅式提供给⽤户。
其次，平台的逻辑⾃洽性决定了⽤户产出的质量：在代码的组织上，不同组件之间不可以任意组合，错误的组合可能导致显⽰与功能的异常。如果平台只是简单罗列所有组件，⽽对其中的规则不加以限制，就可能导致⽤户在使⽤过程中出现意料外的产出结果。所以，平台开发者需要有⼀套完整的组件关联关系表，并反映到交互呈现中。
最后，平台提供的交互易⽤性决定了⽤户的产出效率：尽管⼤部分低代码平台都提供了相似的区域操作逻辑，但真正影响⽤户使⽤效率的往往是很多细节的控制。例如，与单纯依靠光标选取组件相⽐，在侧边栏提供节点树的⽅式可以更⼤程度减少误选；与简单陈列所有组件相⽐，合适的分类，以及当选择特定组件时筛选出可添加的部分组件，更能减少⽤户搜索的时间，同时减少可能的出错；⼀些平台提供了操作栈回放的功能，能减少⽤户误操作后的修复成本，等等。
低代码开发的产品
低代码开发的产品有很多，其中既包括商⽤的产品，例如 Kony、OutSystems、Mendix、Appian、iV
X（国内）等，也包括开源类的产品，例如阿⾥飞冰、百度 Amis、贝壳河图、Vvvebjs、react-visual-editor 等。这⾥就不⼀⼀介绍了，感兴趣的话，你可以进⼀步搜索了解。
总结
这篇介绍了低代码开发的概念和它的基本应⽤场景，也了解了低代码开发的两种基本开发模式：基于编写 JSON 的⽅式和基于可视化操作平台的⽅式。
前者对普通的项⽬开发流程做了抽象，将编写不同功能模块的代码变为只编写组件语法树描述信息，这种⽅式在⼀定程度上降低了使⽤者的技术要求，提升了开发的效率，但是在⼀些⽅⾯仍然不甚理想。⽽平台化的开发模式相对⽽⾔解决了编写 JSON 模式下的⼀些问题，但是要搭建⼀个功能完备、使⽤逻辑⾃洽和交互性良好的平台也并⾮易事。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。