从零开始开发纯血鸿蒙应用
- 一、前言
- 二、系统性认识`@Builder`和`@BuilderParam`
- [三、改造 PageTitleBar](#三、改造 PageTitleBar)
- 四、总结
一、前言
上个周末，由于身体抱恙，故而没有更新博文，而昨天，在返乡路途上，所以，只能拖到今天才进行博文的更新。
言归正传，开发纯血鸿蒙应用所使用的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。