低代码平台思考
- 批量更新落地页的问题
本身不是问题，只要提供了批量更新的功能就行。但是批量构建的速度非常慢，则导致了等待的问题。
另一个问题时职责不清晰，比如技术侧增加了一行日志或者技术迭代更新了接口。业务侧并不关心，他们自然不愿意做批量更新的动作。
页面缺乏生命周期的维护，导致页面越来越多。批量更新的页面也越来越多。
页面 = 项目模版 + 组件 + 组件配置 + 页面配置
项目模版和组件都是不同页面之间公用的，所以需要版本化管理。组件配置则是属于某个页面的。 组件可以在不同的项目模版中使用，但是不同的项目模版意味着不同的业务功能。
crm系统 = 平台项目模版 + 平台组件（外部导入组件+平台内部维护的组件） + 组件配置 + 页面配置 + 系统配置 + 路由机制
页面级别的项目模版时需要共享的，也就是某个页面的升级极大可能需要共享到其他页面。 当然如果不想要共享这种升级变化，意味着这是一次fork，就存在两个页面模版了。 所以项目模版应该是独立存在的，而且是版本化的，页面只是关联到特定模版的某个版本。 如果模版升级了，页面则需要主动去升级对应的模版版本。
对应的crm系统的项目模版大概率是不需要共享的。所以项目模版是属于系统的，并不是系统关联特定的模版的某个版本。 而且页面的部署方式和系统的部署方式也不太一样。所以最好是分成两个独立的业务来实现。
L1落地页 -> 下单成功页面 官网 -> L1落地页 -> 下单成功页面 广告 -> L1落地页 -> 下单成功页面
支付页面 -> 第三方支付页面 -> 选择开课时间页面 -> 支付成功页面 课包列表页面 -> 支付页面 -> 第三方支付页面 -> 选择开课时间页面 -> 支付成功页面 官网 -> 课包列表页面 -> 登录页面 -> 支付页面 -> 第三方支付页面 -> 选择开课时间页面 -> 支付成功页面
这些页面怎么组织是一个问题。 方法1: 通过系统来组织页面。意味着每个落地页都有一个对应的下单成功页面。实际上下单成功页面是公用的，只是美国和东南亚不一样。 方法2: 自己通过代码控制跳转到哪个页面，意味着跳转链接需要写死，那不同的页面可能不一样，则需要配置的地方。
还是觉得方法2比较好一些，不用引入新的概念。
项目模版的版本化 npm中需要包含git源码，用于nodejs构建项目。 项目模版发版时需要构建出一个包含所有组件的js文件，并且具有解析配置文件的runtime。
组件的版本化 组件的版本化没有特殊的地方，关键在于组件的配置表单如何实现。而且组件的配置表单也需要版本化。 另外对于第三方组件库应该如何实现配置表单。