★ FEATURED ARTICLE 1. 状态管理入门这节内容到底解决什么问题做鸿蒙应用开发绕不开一个核心问题页面上的数据变了界面怎么跟着变如果还是靠传统命令式写法手动去操作每个组件页面一复杂就失控。ArkTS的V1状态管理体系就是用来解决这个问题的它让数据和UI之间建立起自动同步的通道数据变了用到这个数据的组件自动刷新。我见过不少初学者在没搞懂状态管理的情况下硬写业务代码结果出现两类很典型的问题一类是数据改了界面纹丝不动另一类是搞不清数据流向子组件改了数据父组件不知情调试半天找不出原因。这节的四个主角——State、Prop、Link、Watch——恰好覆盖了组件内状态、父子组件通信、跨组件同步和状态变化的监听回调这几大基础场景。这一节的内容适合谁看如果你是刚入手ArkTS还停留在静态页面阶段学完这节能让你把自己的页面真正“动”起来如果你已经在写业务但遇到过数据不刷新或者父子同步混乱的问题这节也能帮你把底层机制理清理顺。整节我在讲原理的同时会带完整的代码示例主打一个“看完能抄、抄完能跑”。2. 核心装饰器逐个拆解从State到Watch2.1 State组件内响应式状态的基石State是V1体系里最基础的装饰器它标记的变量会成为组件内部的响应式状态。意思就是这个变量一旦被赋值或修改框架会自动重新渲染依赖它的UI部分。我一般这样给初学者打比方把组件想象成一块电子公告牌State变量就是牌子上显示的数字。你拿遥控器把数字从1改成2牌子跟着就变了不需要你亲手去把牌子上的字擦掉重写。State干的就是这个“自动改牌子”的活。具体到代码里它有几个必须遵守的约束。第一State变量只能在组件内部初始化不能从外部直接赋值这是它和Prop、Link最直观的区别。第二State支持的数字、字符串、布尔值、对象、数组、枚举等类型都支持甚至支持Date这类系统自带类型。第三对象和数组这类引用类型State做的是深层观察对象属性变了也能触发刷新。先看一个最基础的计数器示例Entry Component struct CounterPage { State count: number 0 build() { Column({ space: 20 }) { Text(当前计数${this.count}) .fontSize(30) Button(点我 1) .onClick(() { this.count }) Button(归零) .onClick(() { this.count 0 }) } .width(100%) .padding(20) } }这个例子没有一句手动操作UI的代码count一增Text组件里的数字自己就变了。这就是响应式带来的直接的开发体验提升。2.2 Prop父传子的单向同步Prop的定位是父组件的数据变化能同步到子组件但子组件内部对Prop变量的修改不会同步回父组件。这就是单向同步。在理解上有个关键认知Prop变量在子组件里是一个本地副本。初始化时它接收父组件传来的值之后父组件更新源数据框架会把新值重新推给子组件。但在子组件内部它和普通成员变量一样你可以修改它只是改了之后父组件感知不到。正因为它是“拷贝”的语义所以父组件传什么类型的值有两个地方要注意第一Prop支持的类型和State基本一致但不支持数组这种复杂引用类型对象类型也有限制——我这节里不做展开实际用到时去查官方约束列表即可。第二父组件传值时必须带上$前缀比如Child({ propValue: $parentValue })漏掉$就会变成普通传参响应式同步直接失效。动手验证一下单向同步最直观。父组件里放一个State变量通过Prop传给子组件子组件有个按钮去改自己的Prop父组件放一个Text把源数据显示出来你会发现子组件改了界面上自己的值父组件里的源数据纹丝不动。这个实验我每次都建议学员亲手做一遍理解会非常深刻。2.3 Link父子双向同步Link和Prop最大的区别在于它是双向的。子组件修改Link变量父组件的源数据也会跟着变。底层看Link变量和父组件源数据共享同一个内存引用子组件里不是副本而是同一份数据的不同入口。这个特性在需要子组件直接改父组件数据的场景下非常好用比如表单页里子组件填写的内容要直接回写到父组件的表单数据对象。它的使用同样需要在父组件用$传值比如Child({ linkValue: $parentValue })。Link有一个容易踩的小坑它要求父组件传过来的值必须是State、Link或Prop等响应式变量。如果你尝试把一个普通变量用$传给Link编译器直接报错这也是初学者问得很多的问题之一。举个例子更直观。还是计数器场景但把按钮挪到子组件里去Component struct ChildCounter { Link count: number build() { Button(子组件当前值${this.count}) .onClick(() { this.count }) } } Entry Component struct ParentPage { State count: number 0 build() { Column({ space: 20 }) { Text(父组件计数${this.count}) .fontSize(24) ChildCounter({ count: $count }) } .width(100%) .padding(20) } }子组件里点按钮修改count父组件的Text立刻跟着变化。因为没有把修改逻辑层层往上传代码结构也干净很多。我实际开发中如果需要子组件直接改父组件的数据Link往往是首选省去回调函数的样板代码。2.4 Watch状态变化的监听回调Watch是配合前三个装饰器使用的“监听器”。它可以在状态变化时执行一个自定义回调函数适合做联动逻辑、数据校验、缓存更新等操作。用法是在State/Prop/Link变量上追加Watch参数State Watch(onCountChanged) count: number 0 onCountChanged() { console.info(count变化了当前值${this.count}) }回调函数在变量发生改变后触发函数名用字符串传入。我建议Watch回调尽量保持轻量只放必要逻辑不要在里边做复杂计算或网络请求避免影响到UI刷新的性能。一个典型的联动场景当计数达到10的倍数时弹个提示。Watch回调里判断一下新值就能实现。另一个常见的用法是把多个State的变更汇总后做一次持久化存储避免每次变化都去写缓存。3. 父子组件通信方案的选型逻辑面对一个需求到底用Prop还是Link不少新手会纠结。我给一个非常朴素的判断标准子组件需不需要修改父组件的数据不需要用Prop数据流清晰、可预测需要用Link简单直接。再细化一点从数据流的安全性和可维护性角度出发Prop的数据流是单向的逻辑链路清晰排查问题时候只需要看父组件怎么传Link让数据在父子间双向流动灵活但是状态分散在两处一旦页面复杂排查数据从哪边改的就得多花点心思。所以我的经验是能单向就单向确实需要双向才用Link。还有一种更工程化的选择就是使用回调函数子组件不直接持有父组件状态而是通过调用父组件传入的函数来传递“修改请求”。这种写法虽然代码量多一些但解耦程度最高在某些复杂场景下反而更好维护不过不在这一节的核心范围里。为了帮大家快速决策我整理了一个对照表装饰器数据流方向子组件能否修改典型场景传值语法State组件内部可修改自己页面内部临时状态无需传值Prop父传子单向可改但不同步父组件展示型子组件propName: $parentValueLink父子双向可改且同步父组件需要子组件直接改父数据linkName: $parentValueWatch配合以上三者—状态变化的监听回调—4. 组合实例完整演示四个装饰器的协同工作前面拆开讲了这里把它们组合起来做一个有实际意义的例子——一个购物车商品卡片。父组件维护购物车列表和总价商品卡片子组件负责展示单个商品并支持修改数量、删除商品。先定义数据类型// 商品数据类型 class Goods { id: number 0 name: string price: number 0 count: number 0 constructor(id: number, name: string, price: number, count: number) { this.id id this.name name this.price price this.count count } }然后写购物车页面Entry Component struct ShoppingCartPage { State goodsList: Goods[] [ new Goods(1, 苹果, 5.5, 2), new Goods(2, 香蕉, 3.2, 5), new Goods(3, 牛奶, 8.8, 1) ] State totalPrice: number 0 Watch(calcTotal) State countChangedFlag: number 0 // 说明实际需要在商品数量变化时重新计算总价这里用Watch监听一个标志位来演示 calcTotal() { let total 0 this.goodsList.forEach((item: Goods) { total item.price * item.count }) this.totalPrice total } build() { Column({ space: 12 }) { Text(购物车总价${this.totalPrice} 元) .fontSize(22) .fontWeight(FontWeight.Bold) ForEach(this.goodsList, (item: Goods) { GoodsCard({ goodsName: item.name, goodsPrice: item.price, goodsCount: item.count, onCountChange: (newCount: number) { item.count newCount this.calcTotal() }, onDelete: () { let index this.goodsList.indexOf(item) if (index 0) { this.goodsList.splice(index, 1) this.calcTotal() } } }) }, (item: Goods) item.id.toString()) Button(添加一件商品) .onClick(() { let newId this.goodsList.length 1 this.goodsList.push(new Goods(newId, 新商品, 9.9, 1)) this.calcTotal() }) } .width(100%) .padding(16) } }商品卡片子组件Component struct GoodsCard { // 商品名和价格使用Prop单向展示子组件不修改 Prop goodsName: string Prop goodsPrice: number 0 // 数量同时需要展示和修改使用LocalState模拟本地状态 State localCount: number 0 // 接收父组件传过来的操作回调 onCountChange: (newCount: number) void () {} onDelete: () void () {} build() { Row({ space: 12 }) { Column({ space: 4 }) { Text(this.goodsName).fontSize(18) Text(单价${this.goodsPrice} 元).fontSize(14).fontColor(#888888) } .layoutWeight(1) .alignItems(HorizontalAlign.Start) Row({ space: 8 }) { Button(-) .onClick(() { if (this.localCount 0) { this.localCount-- this.onCountChange(this.localCount) } }) Text(${this.localCount}).fontSize(18) Button() .onClick(() { this.localCount this.onCountChange(this.localCount) }) } Button(删除) .onClick(() { this.onDelete() }) } .width(100%) .padding(12) .backgroundColor(#F5F5F5) .borderRadius(8) } }代码里我用了Prop接收商品名和价格用State维护本地数量通过回调函数把数量变化和删除操作通知父组件。这里数量用了本地State加回调的组合而不是Link是想给大家展示另一种同样实用的写法——子组件只提交“意图”由父组件做最终的数据变更数据流更可控。如果想把数量改成Link写法只需要把子组件的State localCount改成Link goodsCount父组件传$绑定然后在改动数量时去掉onCountChange回调Link会自动双向同步。两种方案没有绝对优劣看团队规范和页面复杂度自己权衡这也是我前面强调选型逻辑的原因。5. 实战过程中容易踩的坑与排查技巧踩坑是学习的捷径我把这几年见到的高频问题整理成一个排查速查表每个问题都是真实发生过的建议大家直接收藏。问题现象可能原因解决方案数据改了UI不刷新变量没有用State/Prop/Link修饰确认变量是否已加装饰器父组件赋值后子组件没反应传值时漏掉$前缀检查父组件模板传参是否写$子组件改了Prop父组件数据变了这是正常行为不父组件不应该变若变了说明用成了Link检查子组件用的装饰器类型Watch回调不触发函数名写错或不是字符串检查装饰器里传入的字符串和函数名是否一致Watch回调里再改同一个变量递归触发多次调用增加判断条件或拆分成不同变量数组的某个元素属性变了UI不刷新直接将元素赋值给非响应式变量确认变量是State且操作确实是在数组上做的还有一个极其隐蔽的细节Watch回调的触发时机是在变量变化之后所以回调里读取this.count拿到的是新值不是旧值。如果你需要旧值做对比必须在回调触发前手动缓存一份。这个需求不常见但一旦遇到没有缓存用起来就很别扭。关于Watch递归触发我举个例子大家自己体会。如果你监听变量A在回调里又给A赋值就会无限循环触发。规避的办法是在回调里判断值是否真的需要变更或者用一个额外的标志位控制。我在购物车的calcTotal方法里没有直接修改监听的变量所以不会有这个风险。最后聊一个关于数组和对象的经验。State修饰数组当数组里某个元素的某个属性变化时UI是可以感知的但要确保你是直接修改这个元素对象本身。比如this.goodsList[0].count 5这样写是能触发刷新的。但如果你先把元素取出来存到一个普通变量里再改这个普通变量的属性UI就不会有任何反应因为那个普通变量已经不是响应式数据了。类似的坑非常多很多学员卡在这里很久排查到头才发现是因为多了一步临时变量赋值。6. 从这节内容往外延伸下一步学什么搞懂了这四个装饰器你已经能处理绝大多数页面级的状态管理需求。但ArkTS的V1体系里还有几个和这节紧密衔接的能力放在一起学效果更好。一是Provide和Consume。和Prop/Link需要在父子组件间显式传递不同Provide/Consume实现的是跨层级的状态共享爷爷组件提供数据孙子组件直接消费中间的层级完全不用管传参。页面层级深的时候它俩能省掉大量“中转站”代码。二是Observed和ObjectLink。这节里State对数组元素内部的修改能感知是因为框架对数组做了处理。但当对象的属性还是另一个对象时深层嵌套对象的属性修改能不能刷新V1体系需要借助Observed和ObjectLink才能做到精细控制。在列表套对象、对象再套对象的复杂场景中尤其重要。三是V2状态管理。这一节讲的是V1V2是新一代的状态管理方案在装饰器命名、观测能力、性能上都有比较大的升级。新项目是不是可以直接上V2社区里有一些讨论但V1仍然值得认真学一方面存量项目大量在用另一方面理解V1的设计思路能帮你更明白V2为什么要改。我个人带项目的体感是状态管理是ArkTS开发里最需要“动手试”的知识点光看文档很容易产生“我会了”的错觉一写代码就露馅。建议学完这节后自己动手把计数器案例改成购物车、改成表单、改成多页面共享数据的场景直到闭着眼能写出装饰器的基本用法。这个投入非常值得。
阅读完成 · 觉得有帮助？
