OpenHarmony装饰指定自定义组件:@BuilderParam装饰器
当开发者创建了自定义组件,并想对该组件添加特定功能时,例如在自定义组件中添加一个点击跳转操作。若直接在组件内嵌入事件方法,将会导致所有引入该自定义组件的地方均增加了该功能。为解决此问题,ArkUI引入了@BuilderParam装饰器,@BuilderParam用来装饰指向@Builder方法的变量,开发者可在初始化自定义组件时对此属性进行赋值,为自定义组件增加特定的功能。该装饰器用于声明任意UI描述的一个元素,类似slot占位符。
说明:
从API version 9开始,该装饰器支持在ArkTS卡片中使用。
装饰器使用说明
初始化@BuilderParam装饰的方法
@BuildParam装饰的方法只能被自定义构建函数(@Builder装饰的方法)初始化。
● 使用所属自定义组件的自定义构建函数或者全局的自定义构建函数,在本地初始化@BuilderParam。
@Builder function GlobalBuilder0() {} @Component struct Child { @Builder doNothingBuilder() {}; @BuilderParam aBuilder0: () => void = this.doNothingBuilder; @BuilderParam aBuilder1: () => void = GlobalBuilder0; build(){} }
● 用父组件自定义构建函数初始化子组件@BuildParam装饰的方法。
@Component struct Child { @Builder componentBuilder() { Text(`Parent builder `) } @BuilderParam aBuilder0: () => void = this.componentBuilder; build() { Column() { this.aBuilder0() } } } @Entry @Component struct Parent { @Builder componentBuilder() { Text(`Parent builder `) } build() { Column() { Child({ aBuilder0: this.componentBuilder }) } } }
● 需注意this指向正确。
以下示例中,Parent组件在调用this.componentBuilder()时,this.label指向其所属组件,即“Parent”。@Builder componentBuilder()传给子组件@BuilderParam aBuilder0,在Child组件中调用this.aBuilder0()时,this.label指向在Child的label,即“Child”。对于@BuilderParam aBuilder1,在将this.componentBuilder传给aBuilder1时,调用bind绑定了this,因此其this.label指向Parent的label。
说明:
开发者谨慎使用bind改变函数调用的上下文,可能会使this指向混乱。
@Component struct Child { @Builder componentBuilder() { Text(`Child builder `) } label: string = `Child` @BuilderParam aBuilder0: () => void = this.componentBuilder; @BuilderParam aBuilder1: () => void = this.componentBuilder; build() { Column() { this.aBuilder0() this.aBuilder1() } } } @Entry @Component struct Parent { label: string = `Parent` @Builder componentBuilder() { Text(`${this.label}`) } build() { Column() { this.componentBuilder() Child({ aBuilder0: this.componentBuilder, aBuilder1: this.componentBuilder }) } } }
使用场景
参数初始化组件
@BuilderParam装饰的方法可以是有参数和无参数的两种形式,需与指向的@Builder方法类型匹配。@BuilderParam装饰的方法类型需要和@Builder方法类型一致。
class GlobalBuilderParam { label: string = "" } @Builder function GlobalBuilder1($$ : GlobalBuilderParam) { Text($$.label) .width(400) .height(50) .backgroundColor(Color.Blue) } @Component struct Child { @Builder componentBuilder() { Text(`Child builder `) } label: string = 'Child' // 无参数类,指向的componentBuilder也是无参数类型 @BuilderParam aBuilder0: () => void = this.componentBuilder; // 有参数类型,指向的GlobalBuilder1也是有参数类型的方法 @BuilderParam aBuilder1: ($$ : GlobalBuilderParam) => void = this.componentBuilder; build() { Column() { this.aBuilder0() this.aBuilder1({label: 'global Builder label' } ) } } } @Entry @Component struct Parent { label: string = 'Parent' @Builder componentBuilder() { Text(`${this.label}`) } build() { Column() { this.componentBuilder() Child({ aBuilder0: this.componentBuilder, aBuilder1: GlobalBuilder1 }) } } }
尾随闭包初始化组件
在自定义组件中使用@BuilderParam装饰的属性时也可通过尾随闭包进行初始化。在初始化自定义组件时,组件后紧跟一个大括号“{}”形成尾随闭包场景。
说明:
此场景下自定义组件内有且仅有一个使用@BuilderParam装饰的属性。
开发者可以将尾随闭包内的内容看做@Builder装饰的函数传给@BuilderParam。示例如下:
// xxx.ets class CustomContainerParam { header: string = ''; } @Component struct CustomContainer { @Builder componentCloser() { Text(`Custom closer `) } @Prop header: string = ''; @BuilderParam closer: () => void = this.componentCloser; build() { Column() { Text(this.header) .fontSize(30) this.closer() } } } @Builder function specificParam(label1: string, label2: string) { Column() { Text(label1) .fontSize(30) Text(label2) .fontSize(30) } } @Entry @Component struct CustomContainerUser { @State text: string = 'header'; param: CustomContainerParam = { header: this.text }; build() { Column() { // 创建CustomContainer,在创建CustomContainer时,通过其后紧跟一个大括号“{}”形成尾随闭包 // 作为传递给子组件CustomContainer @BuilderParam closer: () => void的参数 CustomContainer(this.param) { Column() { specificParam('testA', 'testB') }.backgroundColor(Color.Yellow) .onClick(() => { this.text = 'changeHeader'; }) } } } }
本文由博客一文多发平台 OpenWrite 发布!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
袋鼠云代码检查服务,揭秘高质量代码背后的秘密
质量是产品的生命线,代码检查是软件开发过程中至关重要的一环,它可以帮助我们发现并纠正潜在的错误,提高软件质量,降低维护成本。 在袋鼠云产品中也存在这个问题,由于离线数据开发人员 SQL 水平不一,导致代码书写混乱、SQL 代码运行问题较多。本文将介绍在离线产品中如何利用 SQL 检查规则规范化 SQL 代码,对代码书写问题进行拦截,便于统一管理,用于预防引入需要治理的问题。 通过本文的介绍,我们希望您能够认识到代码检查的重要性,并了解如何通过最佳实践来提高代码质量和开发效率。 何时进行代码规则检查? SQL 任务在离线产品界面开发完成之后,点击运行的按钮,会先经过代码规则检查,如果代码规则不满足则会提示到用户具体的原因。 数据资产模块内置了 5 种代码检查规则,用户可以根据需要选择性开启。 开启后在离线项目管理中可以选择使用的代码规则检查项、生效范围和 SQL 任务类型。 在离线 SQL 任务中去运行一条 SQL 前会根据选择的规则先进行代码检查,如果代码检查不通过则会反馈给用户,用户可以根据实际需要判断要不要执行该 SQL。 在数据资产的代码检查时间中可以看到已经触发的检查历史以及相...
- 下一篇
恶搞: 高效能软件工程师的 7 个习惯
有一个文章《高效能软件工程师的 7 个习惯》 https://www.oschina.net/news/259604/7-habits-of-highly-effective-software-engineers 快速将想法打造出原型,进行概念验证 恶搞:太浪费时间,对于2周一次迭代来说,根本没有时间原型。 原型失败就得不偿失。快速构建的项目是不可能失败的,或者越失败、混沌,对你越有利 有效评估工作量 恶搞:工作量评估看场景,如果争取新项目,当然评估比别人更短点,这样,你可以负责项目,如果是老项目维护,交接项目,当然要悲观点评估。准确评估对自己没有好处。与其花太长时间评估肯定导致不准,还不如按照自己需要评估 快速且及时地 review 代码 恶搞:看过此文章的人自问,真的Review别人代码了么?别人真有时间Review你代码?大部分连Review自己代码都没有。 主动记录代码、设计和流程,形成文档 恶搞:浪费时间,且没人看。过不了3个月就是垃圾 。 且,你记录的清楚,那就容易被替代,我就是那个写好代码,写好单元测试,写好文档,然后被赶到下一个项目,下下个项目的程序员。 坦诚地参与技术...
相关文章
文章评论
共有0条评论来说两句吧...