前端低代码之路（二）-- 产品形态很重要

继上篇，咱们讲讲低代码的产品形态，为啥这么讲，我我的认知市面上不太可能出现通用型低代码平台，低代码的目的就是适应某一特定领域，来解决这一领域中开发人员不足，流程复杂，开发效率低的问题。因此必然是对某一个领域的适用性，好比营销H5页面的搭建，工做流的定义等。

那么必然须要强依赖领域模型，也就是这一领域的产品形态。同时产品的设计相当重要。我将列举几个案例，只是讨论，不分对错。

先来看看有赞的店铺装修后台，其实营销领域中的组件也算比较全，还能适配小程序。

比较中规中矩的左中右模式

• 左侧组件添加按钮，负责添加组件
• 中间可视化预览，兼顾删除和排序的功能
• 右侧选中组件的属性设置，兼顾页面设置，组件列表

本人也曾作过相似的工做，只是组件上需求量不大，该有的都有。加入了版本控制，就是历史操做记录。这块在下一篇技术实现上会细讲。这里只是讨论产品形态。

咱们看到这类页面型编辑器，一类是业务无关的，相似简单的H5生成器。我的比较喜欢maka，固然别的也不错

另外一类就是相似有赞，阿里等电商平台，这类产品跟平台相关，是由于借助电商生态，和商品系统，销售系统等等数据进行打通的，这类系统就能够作到不少特点组件，好比 秒杀，搜索，商品展现，店铺信息等等。

营销页面生成系统优点很明显，使用者可视化使用，无需专业技能，只须要根据一些说明文档进行配置便可。

同时也有一些局限：

• 因为组件限制了灵活性，虽然使用大量模板来弥补不足。上篇说到的问题就是，几乎不能100%的知足用户，只能是用户妥协，微调的可能性极低
• 加载效率的问题，因为组件通常是一次性加载，根据配置列表的内容动态建立组件。组件的代码仍是要加载进来，随着组件个数增长，势必增长代码加载量
• 数据加载的量，举例通常这样的系统都会有商品模块，每一个商品组件都是根据制做页面的时候设置的商品动态请求商品信息，若是一个页面，相似于活动会场页面，就会有大量的商品组件，我的经验30个总有的，这个时候问题就是太多的ajax请求会拖慢展现速度

通常上述问题也都有相应的策略去解决。这个须要下篇解释。先暂时讲讲产品策略对于技术的影响，相似于这种比较吃展现的页面型操做，产品的一个不适当想法就会让前端忙的晕头转向。可是有些合理的产品策略仍是要响应。举例以下：

• 展现效果需求，稳定性，不能有报错，不能白屏。速度还得快，不能让客户等过久。
• 业务需求，组件的丰富，就是市面上有的咱要有，没有的也但愿有。例如，为了有条理的展现更多商品，相似于分类的组件，为了更好的控制页面结构，相似于layout的需求
• 路由需求，随着营销类的运营能力提高，不少活动是以主题活动的形式开展，就不是一个一个单页的宣传了，每每是一个会场的概念，就会集合不少个单页组成一些列的页面搞活动，那么就须要控制路由的能力
• 投放需求，活动页面会有定点投放的须要，相似于某些活动只在杭州搞，杭州之外的地区不参加，页面就要有根据地区展现的能力，还有有些活动是定点在某个渠道搞，其余渠道不搞。
• 数据收集的须要，搞活动目的仍是要留存客户，固然但愿还有入口可让用户留下点信息。以便后续的变现。
• 数据分析的须要，通常来说，页面访问数据将来仍是要能提高之后的活动效果，用户行为数据分析，以便为后续活动提供策略支持，简单的uv，pv已经不能知足当下运营的须要了，而是要跟立体的数据，例如商品的点击次数，用户在页面的留存时间，用户在整个活动中的访问链路。

以上的点也就是我我的实践中得出的低代码平台在营销类页面搭建应该考虑的问题。不敢说每一个方向都完美解决，只是针对性的进行了优化。具体代码思路参考下一篇。

回过头咱们，探讨下工做流领域的低代码，经验所致，我开发过的只有阿里巴巴内网的工做流平台，也就是钉钉的审批模块。还有就是医疗行业的一个问卷系统。工做流系统，从工做流的定义，到自助表单的开发都有涉足。钉钉审批是2015年开发的，如今的开发者已经把产品向前推动了一大步。

这一类的产品的一个典型特色就是要完成必定的工做，这项工做能够由各类独立功能的节点组成有向无环图。通常分为

• 开始节点，业务发起的条件
• 操做节点，具有某种业务执行能力，例如审批，具有某些权限，例如 判断条件，操做人设置等
• 条件节点，也就是根据上一个节点的执行结果进行条件判断，走向不一样的分支
• 结束节点，达到某种结果，而退出工做流。

这类操做其实开发起来很是简单，缘由是基本是后台操做，没有特别的流量压力，以及展现效果要求。并且操做每每在pc端完成，代码容错性高。惟一的要求就是配合工做流引擎根据业务定义，把各个节点的UI和相应的功能设置完成便可。还有就是完成工做流中的工做，几乎都是须要一些数据的，也就是当前工做流中的表单，发起人或者流程节点中的操做每每都是围绕最初始的一个表单进行操做。好比 请假，出差，设备领用，入职，离职，这些都须要一个原始表单，承载业务数据。伴随而来的就是自助表单系统，也有些叫问卷系统，无论叫什么，就是一个数据输入工具。

这类表单系统从UI上来说并不复杂，并且不少工具组件库都提供了form表单组件。我的经验认为有几个重要的点值得注意（2个项目，一个阿里巴巴工做流，一个医疗行业问卷系统）。

• 数据的验证，既然是数据输入，就有一些必要的验证，例如必填项，也有一些数据分析要求的格式验证。例如 手机号码，表单收集者确定不但愿你填一堆没必要要的文字。通常表单组件都提供了一些基础验证，可是也有例外，若是用户有些特殊的验证，例如组合验证，几个表单项的结果组合就不对，这种状况也常见
• 控制操做，在不少调查问卷中经常出现，就是表单域的控制能力，根据某一内容的值，来判断将要填什么内容。在医疗行业特别明显。例如 选择性别，男性，那么你后面就不能填月经时间是否是，因此在医疗问卷中这只是一个很简单的例子，一般都是性别，年龄，科室，身高，体重一块儿来决定你是要填什么问题。
• 自动化填充，为啥要讲这个，这个也是在作相似表单系统的时候发现的，有不少数据要填的时候，填表人老是很反感。仍是医疗行业举例，我姓名，性别，年龄，科室，身高体重等等固定信息不是在看病或者屡次检查住院时都填好的，还要一并填写，不人性化。利用如今不少AI技术，表单的填充也愈来愈智能，能自动填的自动填，能选的就不要让用户输入。
• 表单效果，早期的时候你们都是习惯了瀑布流的结构，随着移动的发展，表单结构也有了变化，也有比较多的样式体现。这一点我仍是比较欣赏material-ui的作法，虽然表单是收集数据为主，可是能作到好看又新奇不也挺好吗

总结：产品形态决定了前端的技术方案。因此我一直认为一个优秀的产品真的会成就一家互联网公司。你想毁掉一个产品就给他找个不合适的产品经理。还有就是低代码的平台通常产品经理作很差，因此各位前端同窗必定多想一想产品的事，只有前端能作好低代码，不服来辩。