继上篇，我们讲讲低代码的产品形态，为啥这么讲，我个人认知市面上不太可能出现通用型低代码平台，低代码的目的就是适应某一特定领域，来解决这一领域中开发人员不足，流程复杂，开发效率低的问题。所以必然是对某一个领域的适用性，比如营销H5页面的搭建，工作流的定义等。
那么必然需要强依赖领域模型，也就是这一领域的产品形态。同时产品的设计至关重要。我将列举几个案例，只是讨论，不分对错。
先来看看有赞的店铺装修后台，其实营销领域中的组件也算比较全，还能适配小程序。
比较中规中矩的左中右模式
- 左侧组件添加按钮，负责添加组件
- 中间可视化预览，兼顾删除和排序的功能
- 右侧选中组件的属性设置，兼顾页面设置，组件列表
本人也曾做过类似的工作，只是组件上需求量不大，该有的都有。加入了版本控制，就是历史操作记录。这块在下一篇技术实现上会细讲。这里只是讨论产品形态。
我们看到这类页面型编辑器，一类是业务无关的，类似简单的H5生成器。个人比较喜欢maka，当然别的也不错
另一类就是类似有赞，阿里等电商平台，这类产品跟平台相关，是因为借助电商生态，和商品系统，销售系统等等数据进行打通的，这类系统就可以做到很多特色组件，比如 秒杀，搜索，商品展示，店铺信息等等。
营销页面生成系统优势很明显，使用者可视化使用，无需专业技能，只需要根据一些说明文档进行配置即可。
同时也有一些局限：
- 由于组件限制了灵活性，虽然使用大量模板来弥补不足。上篇说到的问题就是，几乎不能100%的满足用户，只能是用户妥协，微调的可能性极低
- 加载效率的问题，由于组件一般是一次性加载，根据配置列表的内容动态创建组件。组件的代码还是要加载进来，随着组件个数增加，势必增加代码加载量
- 数据加载的量，举例一般这样的系统都会有商品模块，每个商品组件都是根据制作页面的时候设置的商品动态请求商品信息，如果一个页面，类似于活动会场页面，就会有大量的商品组件，个人经验30个总有的，这个时候问题就是太多的ajax请求会拖慢展示速度
一般上述问题也都有相应的策略去解决。这个需要下篇解释。先暂时讲讲产品策略对于技术的影响，类似于这种比较吃展示的页面型操作，产品的一个不适当想法就会让前端忙的晕头转向。但是有些合理的产品策略还是要响应。举例如下：
- 展示效果需求，稳定性，不能有报错，不能白屏。速度还得快，不能让客户等太久。
- 业务需求，组件的丰富，就是市面上有的咱要有，没有的也希望有。例如，为了有条理的展示更多商品，类似于分类的组件，为了更好的控制页面结构，类似于layout的需求
- 路由需求，随着营销类的运营能力提升，很多活动是以主题活动的形式开展，就不是一个一个单页的宣传了，往往是一个会场的概念，就会集合很多个单页组成一些列的页面搞活动，那么就需要控制路由的能力
- 投放需求，活动页面会有定点投放的需要，类似于某些活动只在杭州搞，杭州以外的地区不参加，页面就要有根据地区展示的能力，还有有些活动是定点在某个渠道搞，其他渠道不搞。
- 数据收集的需要，搞活动目的还是要留存客户，当然希望还有入口可以让用户留下点信息。以便后续的变现。
- 数据分析的需要，一般来讲，页面访问数据未来还是要能提升以后的活动效果，用户行为数据分析，以便为后续活动提供策略支持，简单的uv，pv已经不能满足当下运营的需要了，而是要跟立体的数据，例如商品的点击次数，用户在页面的留存时间，用户在整个活动中的访问链路。
以上的点也就是我个人实践中得出的低代码平台在营销类页面搭建应该考虑的问题。不敢说每个方向都完美解决，只是针对性的进行了优化。具体代码思路参考下一篇。
回过头我们，探讨下工作流领域的低代码，经验所致，我开发过的只有阿里巴巴内网的工作流平台，也就是钉钉的审批模块。还有就是医疗行业的一个问卷系统。工作流系统，从工作流的定义，到自助表单的开发都有涉足。钉钉审批是2015年开发的，现在的开发者已经把产品向前推进了一大步。
这一类的产品的一个典型特点就是要完成一定的工作，这项工作可以由各种独立功能的节点组成有向无环图。一般分为
- 开始节点，业务发起的条件
- 操作节点，具备某种业务执行能力，例如审批，具备某些权限，例如 判断条件，操作人设置等
- 条件节点，也就是根据上一个节点的执行结果进行条件判断，走向不同的分支
- 结束节点，达到某种结果，而退出工作流。
这类操作其实开发起来非常简单，原因是基本是后台操作，没有特别的流量压力，以及展示效果要求。而且操作往往在pc端完成，代码容错性高。唯一的要求就是配合工作流引擎根据业务定义，把各个节点的UI和相应的功能设置完成即可。还有就是完成工作流中的工作，几乎都是需要一些数据的，也就是当前工作流中的表单，发起人或者流程节点中的操作往往都是围绕最初始的一个表单进行操作。比如 请假，出差，设备领用，入职，离职，这些都需要一个原始表单，承载业务数据。伴随而来的就是自助表单系统，也有些叫问卷系统，不管叫什么，就是一个数据输入工具。
这类表单系统从UI上来讲并不复杂，而且很多工具组件库都提供了form表单组件。个人经验认为有几个重要的点值得注意（2个项目，一个阿里巴巴工作流，一个医疗行业问卷系统）。
- 数据的验证，既然是数据输入，就有一些必要的验证，例如必填项，也有一些数据分析要求的格式验证。例如 手机号码，表单收集者肯定不希望你填一堆不必要的文字。一般表单组件都提供了一些基础验证，但是也有例外，如果用户有些特殊的验证，例如组合验证，几个表单项的结果组合就不对，这种情况也常见
- 控制操作，在很多调查问卷中常常出现，就是表单域的控制能力，根据某一内容的值，来判断将要填什么内容。在医疗行业特别明显。例如 选择性别，男性，那么你后面就不能填月经时间是不是，所以在医疗问卷中这只是一个很简单的例子，通常都是性别，年龄，科室，身高，体重一起来决定你是要填什么问题。
- 自动化填充，为啥要讲这个，这个也是在做类似表单系统的时候发现的，有很多数据要填的时候，填表人总是很反感。还是医疗行业举例，我姓名，性别，年龄，科室，身高体重等等固定信息不是在看病或者多次检查住院时都填好的，还要一并填写，不人性化。利用现在很多AI技术，表单的填充也越来越智能，能自动填的自动填，能选的就不要让用户输入。
- 表单效果，早期的时候大家都是习惯了瀑布流的结构，随着移动的发展，表单结构也有了变化，也有比较多的样式体现。这一点我还是比较欣赏material-ui的做法，虽然表单是收集数据为主，但是能做到好看又新奇不也挺好吗
总结：产品形态决定了前端的技术方案。所以我一直认为一个优秀的产品真的会成就一家互联网公司。你想毁掉一个产品就给他找个不合适的产品经理。还有就是低代码的平台一般产品经理做不好，所以各位前端同学一定多想想产品的事，只有前端能做好低代码，不服来辩。
