南瓜电影动态布局探索讲座笔记

动态布局与 lowcode 探索

和讲座无关,主要是谈谈做业务中遇到的问题。

个人理解,动态布局的主要作用是:解放前端生产力(笑哭)。前端工程师在讲页面中的组件模块化、解耦后,可以通过配置信息 —— 常见的是 json、不常见的是 yml —— 来快速的生成页面。

而 lowcode 和 nocode 的主要作用是在动态布局建设完成的前提下,将 UI 与 UE 的工作交付给上游,自身专心负责数据层的写作和组件的建设。

一个完整建设的 lowcode 平台,代码透传顺序应该是:UI -> 运营 -> 产品 -> RD。阿里和微博还通过机器学习,让 UI 产出的图可以由 lowcode 平台所使用的。

Lowcode 解决的痛点是:

  • 开发周期短,需求急。在此基础上,需求方还老是喜欢改东西。
  • 前后端配合能力差,因为不规范的流程造成的开发效率底下。
  • 归类和沉淀的成本太高,变相的造成了开发的成本提高。

南瓜电影对于动态布局的探索

本次讲座中,南瓜电影对于动态布局的探索主要集中在如下几点:

  1. 布局动态化
  2. 组件化
  3. 容器化

因为南瓜电影本身是 App,容器化的动态探索对于前端的参考意义有限,因此讲座后对于于布局的动态化与组件化的进行了一些追问。

布局动态化

布局动态化方面,南瓜电影的做法和我们大同小异:编写一个通用容器,在容器通过请求后端获取页面 json,解析 json 后动态的加载与渲染组件,目前看来这是动态化布局绕不开的一环。另一种业界通用的做法是(通过拖拽)生成 yml,依据 yml 文件生成全新的项目。此项目包含 yml 里所记录的所有组件和 UI UE,同时具备基础的网络层、数据层代码,前端工程师拿到后可以直接装配数据(甚至可以通过培训运营让其自己装配数据)。

南瓜电影的动态布局渲染流程是:

  1. 使用渲染一个默认的骨架屏,同时读取 json。
  2. 根据 json 先加载 1 级容器,填充骨架屏。
  3. 根据显示与否,1 级容器内自行决定是否加载容器内组件。

    现在才真正认识到啥是骨架屏。

这样解决了因为多次请求 json、多个页面加载,造成的首屏白屏时间长于非动态布局的问题。

组件化方面的探索

组件化方面的探索,南瓜电影主要分享了如下几点:

  • 前端组件的分离、组件库的建设
  • 错误码的统一与分离、功能拓展
  • 路由的建设
  • 配置的建设

前端组件的分离、组件库的建设

前端组件分离也是另一个老生常谈的问题,目前看来随着组件的增多、将组件踢出业务项目进行独立是一个所有人都在做的事情。但是由此带来的问题便是组件的版本管理、多个组件打包发布、组件拆分的细粒度,解决了老问题又产生了新问题。目前看来南瓜电影拆分的时候依然会有基础组件和业务组件耦合的情况,而他们也希望通过 mpaas 小程序提供的 CI/CD 功能解决这些尴尬。

这方面我们做的比南瓜电影要好,但是如果有多个组件接入对打包服务器的要求要更高。个人认为包括打包 docker 化、定期清理无效构建等操作,是目前应该补充的 —— 当然有个更大的服务器就更好了。

错误码的统一与分离、功能拓展

南瓜电影讲错误码分离成另一个独立库,在此基础上做了功能的拓展。

南瓜电影在 1 个接口中返回三类错误码:

  1. 业务线编码。
  2. 错误编码。
  3. 后续处理编码。

1 和 2 比较好理解、也很常见(我们也是通过双码定位错误),但是南瓜电影的后续处理码是我们应该学习和借鉴的方向。简单的说,通过处理码的下发南瓜电影可以让后端进一步的控制前端逻辑。不仅仅是弹出提示,还可以跳转页面、结合路由触发事件,使用户获得更好的体验。

路由的建设

南瓜电影所谓的“路由”实际上是控制协议、schema 约束,大致是一个 pumpkin://xxxx/xxxxx?params=xxxx 形式的东西。

南瓜电影下发的配置中,有一套协议的注册功能。每个组件在初始化的过程中都会将自身所拥有的方法、事件等等注册成协议,这样组件间的通信过程就转化为协议间的通信。通过协议的转发、请求,南瓜电影不仅仅可以做到页面间跳转,更可以通过协议精确的控制 A 组件中 B 方法的调用 —— 连传什么参数都可以写在协议里,从而达到了组件间的完全解耦。

个人认为路由建设是南瓜电影中最精髓的一环,应该模仿他们建设我们自己的路由注册与分发机制。

配置的建设

配置的建设方面,南瓜电影的说比较浅而我也忘记在会后询问,因此凭印象和查询结合实际开发过程中的问题自我剖析。

第一个问题是,配置是如何产生的。

如果从 lowcode 的角度分析,配置应该是由拖拽组件产生。但是事实上目前我们缺乏这么一个平台,只能依赖于 json-editor 之类的富文本编辑器修改 json 然后再渲染界面,不够直观。

第二个问题是,配置与后端。

理论上,配置应该是动态化的。亦即我们会提供给后端一个大的、完整的、带有条件判断的 json,后端读取 json 后并不是简单的透传,而是解析 json 后再进一步加工、产生最终的动态布局的 json。这样动态布局才能发挥真正的意义,而不是单纯的解放前端。用户 A 和用户 B 可以访问同一个 json,经过过滤后看到不同的页面。

南瓜电影对今后开发的方向指导

结论:

  1. 在渲染过程中,应该也建立一条默认骨架屏 -> 1 级容器渲染 -> 容器内组件渲染的渲染顺序。
  2. 应该建设和完善我们自己的路由协议、订阅与发布机制,使得组件间充分的解耦。
  3. 应该建设和完善我们自己的 json 生成器,可以先粗糙一些,但是仍然是希望能以拖拽代替数值调整。
  4. 完善配置的动态化,这方面需要联合后端一起进行相关的建设。

参考

南瓜电影 Github

results matching ""

    No results matching ""