我一直在Redux上阅读和观看视频,并且看到很多关于在组件或Redux中管理状态的争论。我没有看到的是关于使用标准全局变量完全在组件之外管理状态的任何事情。
例如,我可以像这样设置一个全局状态变量:
let state = {
player: {
username: "BillyBob",
score: 100
}
}
然后在React组件中,我可以有这样的东西:
incrementScore() {
state.player.score += 1
props.update()
}
然后在App.js中,我可以拥有这个:
update() {
this.forceUpdate()
}
我意识到我仍然必须通过树传递更新功能,但我至少能够在组件级别设置功能而不必担心传递多个部分子组件的状态和功能。
我是React的新手,但我唯一能想到的缺点就是无法要求propTypes。还有什么我想念的吗?
编辑:根据我要求澄清问题,上面的实施是否有任何重大缺点我应该考虑甚至会影响相对简单的应用程序?
答案 0 :(得分:2)
如果你看一下redux
或其他一些状态管理库的实现(例如mobx
或mobx-state-tree
),基本上它们都维护组件之外的状态作为一个独立的对象。
但是,为了有效地检测更改并触发重新渲染,它们实现了HOC,connect
中的redux
和inject
中的mobx
,HOC(更高) order component)将你的组件包装在另一个可以访问全局state
的组件中,并通过它的props传递你的组件所需的一部分状态。这样,只有当组件所需的数据发生更改时,组件才会重新呈现。
与这些流行的库方法相比,您提出的解决方案存在一些问题。
第一个是使用forceUpdate
,基本上,您可能要做的最后一件事是在应用的根节点上调用forceUpdate
,在有人输入输入时考虑场景整个应用程序重新渲染每一次击键。
第二个是将update
函数传递给多个级别的子级,如果你只有1个或2个嵌套组件,那就没问题了,但是你的应用程序增长会是个大问题。随着您的应用程序的增长以及您的状态变得更加复杂,使用单个update
函数来控制整个state
对象可能不是最佳选择。
答案 1 :(得分:1)
React的存在是为了解决创建用户界面的问题,该用户界面由几个独立的部分组成,这些部分可以并行开发并且可以相互无缝地交互。
如果您打算使用全局命名空间来定义您的状态,那么您将绕过React的大部分关键功能,例如:
1.生命周期方法
2.虚拟DOM
3.受控组件
4.渲染优化
简而言之,您将最终得到运行React的所有间接成本,同时错失其优势。
学习新框架或范式的“捕获”是理解如何以导致阻力最小的路径来定义问题。这可以通过引入约束然后在该约束内解决问题来实现。
通过支持vanilla JavaScript进行状态管理,你不会给React和Redux一个公平的机会。
答案 2 :(得分:0)
坚持使用redux,不要为自己复杂化事情:)
答案 3 :(得分:0)
我已经为此用例创建了一个库:)
React的简单?快速⚡️和小?(500字节)全局状态管理,也可以在React组件之外使用!