状态管理@state和@provide的问题(HarmonyOS 鸿蒙Next)

状态管理@state@provide的问题(HarmonyOS 鸿蒙Next) 研究了一段时间鸿蒙,今天突然想到一个关于状态管理的问题。

文档中说到,@State@Prop或者@Link可以实现父子组件间的同步,这个只能是父子组件,不能传透到第三层。 而@Provide@Consume则可以多层组件穿透同步数据。

假如啊,我是说假如,我自己写了一个组件,使用@State@Link来同步父子组件的数据,如果某一天突然需要和另一块业务对接数据,然而那块业务是用@Provide@Consume来同步数据的。这个时候这2块业务咋整合?

所以我觉得这2种方式会不会某一天就是一个大坑呢?@State@Provide这2个同步模式是不是可以整合一成一个就行了呢? 纯瞎想,别问我为什么会有这种业务需求,纯技术方面讨论一下。


更多关于状态管理@state和@provide的问题(HarmonyOS 鸿蒙Next)的实战教程也可以访问 https://www.itying.com/category-93-b0.html

10 回复

不影响的,这俩使用场景不一致。即使业务合并起来,也可以结合起来使用吧,例如 react 的 state 和 context

更多关于状态管理@state和@provide的问题(HarmonyOS 鸿蒙Next)的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


一个字段不用同时用@State@Provide这2个注解啊,

我还没有使用过react,不清楚你指的是什么情况,

一般组件状态使用 state,全局类简单的状态可以使用 provide。如果两者需要通信,可以在组件中调用 provide 下来的方法,将数据 set 到全局。比如 state 和 provide 同时存在 name 字段,那么可以再 provide setName,提供给组件去更新 provide 的 name。

后代组件如果可以代替父子组件,可能会造成数据混乱吧

但是感觉这2个使用场景基本上是重合的,区别好像就是一个可以多层同步数据一个不行,

有时候想吧,确实是后代传值兼容父子组件传值,但是细想能区分开首先是为了防止传值乱吧,对性能有影响,其次就是为了规定不能乱用,就像大炮打蚊子,

66,我也想过这个

一起讨论下,

基本信息

  • 项目名称: My Project
  • 开始日期: 2023-01-01
  • 状态: 进行中

在HarmonyOS鸿蒙Next中,@state@provide是用于状态管理的两个关键装饰器。

@state用于标记组件的内部状态。当使用@state装饰的变量发生变化时,UI会自动重新渲染以反映最新的状态。@state通常用于管理组件内部的状态变化。

@provide用于在组件树中提供状态,使得子组件可以通过@consume装饰器来消费这个状态。@provide通常用于跨组件共享状态,避免了通过props层层传递的繁琐。

两者的主要区别在于作用范围。@state仅限于当前组件内部,而@provide可以在组件树中跨层级共享状态。

回到顶部