状态管理@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
不影响的,这俩使用场景不一致。即使业务合并起来,也可以结合起来使用吧,例如 react 的 state 和 context
更多关于状态管理@state和@provide的问题(HarmonyOS 鸿蒙Next)的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
我还没有使用过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
可以在组件树中跨层级共享状态。