鸿蒙 状态管理-组件装饰器

前提：基于官网3.1/4.0文档。参考官网文档
基于Android开发体系来进行比较和思考。（或有偏颇，自行斟酌）

1.概念

Android中使用过Jetpack MVVM框架知道状态管理，包括React前端所使用的状态管理框架，都有所设计这点。——>通过数据状态来进行UI的渲染更新。

自定义组件拥有变量，变量必须被装饰器装饰才可以成为状态变量，状态变量的改变会引起UI的渲染刷新。如果不使用状态变量，UI只能在初始化时渲染，后续将不会再刷新。

状态管理会涉及一些需要思考的点：
1.在后台数据状态变化时，是否会触发更新
2.短事件重复数据设置，是否会触发多次更新

2. 用法

这里涉及了状态装饰器的概念。

1.@State装饰器：组件内状态

变量前面加上@State来修饰，适用于基本数据类型。Android中而是通过特别的变量来定义。（LiveData）
从标题可知，它是用于组件内。（全局肯定是不可以的）

@State装饰的变量与子组件中的@Prop装饰变量之间建立单向数据同步，与@Link、@ObjectLink装饰变量之间建立双向数据同步。
@State装饰的变量生命周期与其所属自定义组件的生命周期相同。

初始化规则

这张图先看看就是，等到实际用时才知道它们之间的关系。

特别注意
@State修饰的变量，如果是class对象：
1.其属性是基本数据类型，值发生变化时，能被观察者发现
2.其属性是class类型，该class的属性的值发生变化时，不能被观察者发现

为什么要这样规定？
可能是为了减少复杂性吧，若是嵌套观察，可能就没完没了了。因此编程的时候也尽量使用简单、易懂的逻辑来实现。

2.@Prop装饰器：父子单向同步

是什么？
类似@State，只不过人为将其认为是接受参数？官方说明文档跟坨*一样设计上感觉划分太啰嗦，官方举得案例很复杂。
我们从它的命名来理解它。Prop即参数的意思，那么是可以作为参数来承接传入的值（或者引用），这里因为官方将其和@State放在一块，它是可以承接传过来的@State参数。（这样理解的话，那么可以推测@State不可以将对象传递给另外的@State对象，只能传递给具有@Prop的对象？）

为什么这样设计？
不懂。目前来看，设计得比较复杂，是否真正需要有这么定义？

怎么使用？
对象上加上 @Prop修饰符。

2.@Link装饰器：父子双向同步

是什么？
@Prop是父组件向子组件状态变量的单向同步，而这个是双向，意味着@Link修饰的状态变量在子组件发生值变更时，会引发父组件进行更新。类似于liveData+dataBinding。

怎么用？
修饰符都是一样的用法。

3.@Provide装饰器和@Consume装饰器：与后代组件双向同步

是什么？

@Provide装饰的变量是在祖先节点中，可以理解为被“提供”给后代的状态变量。@Consume装饰的变量是在后代组件中，去“消费（绑定）”祖先节点提供的变量。

为什么是一对？
因为它们类似于Android中的ContentProvider与ContentResolver。一个是提供者，一个是消费者。

怎么用？

@Component
struct CompD {
  // @Consume装饰的变量通过相同的属性名绑定其祖先组件CompA内的@Provide装饰的变量
  @Consume reviewVotes: number;

  build() {
    Column() {
      Text(`reviewVotes(${this.reviewVotes})`)
      Button(`reviewVotes(${this.reviewVotes}), give +1`)
        .onClick(() => this.reviewVotes += 1)
    }
    .width('50%')
  }
}

@Component
struct CompC {
  build() {
    Row({ space: 5 }) {
      CompD()
      CompD()
    }
  }
}

@Component
struct CompB {
  build() {
    CompC()
  }
}

@Entry
@Component
struct CompA {
  // @Provide装饰的变量reviewVotes由入口组件CompA提供其后代组件
  @Provide reviewVotes: number = 0;

  build() {
    Column() {
      Button(`reviewVotes(${this.reviewVotes}), give +1`)
        .onClick(() => this.reviewVotes += 1)
      CompB()
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

简而言之，父组件指定@Provider变量，子组件中指定@Consume变量来消费，它们是一对多的关系。

4.@Observed装饰器和@ObjectLink装饰器：嵌套类对象属性变化

是什么？

@ObjectLink和@Observed类装饰器用于在涉及嵌套对象或数组的场景中进行双向数据同步：
被@Observed装饰的类，可以被观察到属性的变化；
子组件中@ObjectLink装饰器装饰的状态变量用于接收@Observed装饰的类的实例，和父组件中对应的状态变量建立双向数据绑定。这个实例可以是数组中的被@Observed装饰的项，或者是class object中的属性，这个属性同样也需要被@Observed装饰。
单独使用@Observed是没有任何作用的，需要搭配@ObjectLink或者@Prop使用。

emmm，@ObjectLink算作是@Link的升级版吧。
是否可以将所有的状态修饰符作为@Observed的子类？
@Observed是用来给class变量来作为状态修饰符的，不同于@State常用于基本数据类型变量。（此处说法不一定准确，属于个人理解）

怎么用？
暂时不表。

3.结论

一遍粗略看下来，这个状态修饰符其实只用一个就可以了，它细分这么多出来是为了解决目前所能看到的场景，但是实际上把问题搞复杂了。

最直观的来说，Android中会对类似的状态变量修饰符定义这么多种么？按照Java中的类、属性的修饰符基本规则：局部变量、全局变量、静态变量来进行逻辑上的架构设计，而不是为了发现某个场景后增加一种修饰符来填补，这样对后续开发、维护来说，包袱会越来越重。

架构设计越往底层越简单越好！