从零开始开发纯血鸿蒙应用之自定义构建函数

从零开始开发纯血鸿蒙应用

一、前言

上个周末,由于身体抱恙,故而没有更新博文,而昨天,在返乡路途上,所以,只能拖到今天才进行博文的更新。

言归正传,开发纯血鸿蒙应用所使用的ArkTS ,是一门典型的支持函数式编程的语言,页面的结构、样式以及响应逻辑,都可以使用函数去描述。在之前,我们先后接触了不少使用函数参数的代码,比如将具体的响应逻辑载入到自定义组件中。

实际上,在鸿蒙框架里面,不仅是纯逻辑的代码支持通过函数参数传递,一些页面内容也支持通过函数参数进行传递,例如,鸿蒙组件的 bindMenu 属性就接受一个菜单构建器------描述菜单具体内容和样式、结构、响应逻辑的特殊函数:

那么,类而用之,我们自己封装的自定义组件中,能不能做到支持使用函数参数从外部获得内容构建器呢?答案是可以的,具体如何实现,请继续跟着下文了解。

二、系统性认识@Builder@BuilderParam

看到这两个装饰器,大家应该立马想到在每个自定义组件中都必须有的 build 方法。在鸿蒙框架中,描述 UI 的代码和描述纯逻辑的代码,有着严格的区分。在 build 方法里面,可以直接使用各种实现定义好的鸿蒙组件或自定义组件,但在未特殊声明的其他成员方法体、如生命周期函数中,UI描述代码是不被允许使用的。

然而,现实需求又是存在的,即并不是所有的 UI 实现都适合用组件级别的结构进行封装,像一些描述页面局部的UI、如一个 Tip,需要更为轻量级的实现体来承担,故而,鸿蒙框架提供了 @Builder 装饰器,来将普通的成员方法转换成描述UI的自定义构建函数

既然允许开发者声明和定义自定义构建函数,那么衍生出来的需求必然有:将自定义构建函数传入到子组件或另一个组件中进行使用 ,而普通的函数参数的声明,无法被编译器识别成 UI 描述,所以,就提供了与 @Builder 装饰器配合使用的 @BuilderParam:

当函数参数使用了 @BuilderParam 装饰后,它就只能接受一个用 @Builder 装饰的函数,否则就会报错。

利用 @BuilderParam 参数从外部获取的 UI 实现,既可以直接在 build 方法中使用,也可以继续往 bindMenu 等鸿蒙组件的属性方法中透传,我这里便是第二种用途:

三、改造 PageTitleBar

之前封装了一个 PageTitleBar 用做页面标题栏,并且,里面预留了右上角菜单的位置。在之前的代码中,这个右上角菜单对点击动作的响应,是通过 onClick 函数完成的,这一次,要改为用 bindMenu 方法,也就是变成如上图的代码。

这一步改造,是考虑到不同页面的右上角菜单,必然功能不同,例如在编辑页面的右上角菜单里,可以有分享等功能,却不适合有进入编辑的功能,毕竟已经在编辑状态了。由于 PageTitleBar 实现代码发生了变化,那么,使用它的地方也要相应变化:

当然了,这里只是一个示例,因为我仍然还没考虑好各个页面的右上角菜单应该有什么功能。

四、总结

@Builder 装饰器的存在,让 UI 实现的灵活度,得到进一步的提高,像一些在某个自定义组件内重复度较高的 UI 代码,我们可以利用自定义构建函数进行抽取,从而降低代码冗余。

自定义构建函数,是由普通函数升格而来,也就自然而然地支持函数参数:

具体怎么使用,可以根据实际情况决定,我这里主要提醒大家在开发鸿蒙应用的过程中,别因为使用频率的缘故,忽略了鸿蒙框架中的一些好用的 API。

相关推荐
kymjs张涛9 分钟前
零一开源|前沿技术周报 #6
前端·ios·harmonyos
Georgewu11 小时前
【HarmonyOS】鸿蒙应用开发Text控件常见错误
harmonyos
Georgewu13 小时前
【HarmonyOS】富文本编辑器RichEditor详解
harmonyos
zhanshuo19 小时前
鸿蒙应用调试与测试实战全指南:高效定位问题,性能优化必备技巧+实用代码示例
harmonyos
万少1 天前
2025中了 聊一聊程序员为什么都要做自己的产品
前端·harmonyos
网络小白不怕黑1 天前
华为设备 QoS 流分类与流标记深度解析及实验脚本
网络·华为
网络小白不怕黑1 天前
华为交换机堆叠与集群技术深度解析附带脚本
网络·华为
幽蓝计划2 天前
HarmonyOS NEXT仓颉开发语言实战案例:动态广场
华为·harmonyos
万少2 天前
第五款 HarmonyOS 上架作品 奇趣故事匣 来了
前端·harmonyos·客户端
幽蓝计划2 天前
HarmonyOS NEXT仓颉开发语言实战案例:电影App
华为·harmonyos