说我有一个简单的切换:
单击按钮时,“颜色”组件在红色和蓝色之间变换
我可以通过这样做来实现这个结果。
index.js
Button: onClick={()=>{dispatch(changeColor())}}
Color: this.props.color ? blue : red
container.js
connect(mapStateToProps)(indexPage)
action_creator.js
function changeColor(){
return {type: 'CHANGE_COLOR'}
}
reducer.js
switch(){
case 'CHANGE_COLOR':
return {color: true}
但这是一个很多代码的地狱,我可以用jQuery,一些类和一些css在5秒内完成一些代码......
所以我想我真正想问的是,我在这里做错了什么?
答案 0 :(得分:123)
Redux主要用于"应用程序状态。"也就是说,任何与您的应用程序逻辑相关的事构建在它之上的视图是该状态的反映,但不必专门为其所做的一切使用该状态容器。
只需提出以下问题:此状态对于应用程序的其余部分是否重要?应用程序的其他部分是否会根据该状态的不同行为?在许多小案例中,情况并非如此。下拉菜单:它打开或关闭的事实可能不会对应用程序的其他部分产生影响。因此,将它连接到您的商店可能有点过分。它当然是一个有效的选择,但并不能真正为您带来任何好处。您最好使用this.state
并将其称为一天。
在您的特定示例中,该按钮的颜色是否会切换为在应用程序的其他部分中产生任何差异?如果它为您的应用程序的主要部分进行某种全局开/关切换,它肯定属于商店。但是,如果您在单击按钮时切换按钮颜色,则可以将颜色状态保留在本地定义。单击按钮的操作可能具有需要操作调度的其他效果,但这与应该是什么颜色的简单问题是分开的。
通常,尽量保持应用程序状态尽可能小。你不必在那里推送所有。在必要时这样做或者在那里保留一些东西很有意义。或者,如果它在使用Dev Tools时让您的生活更轻松。但是不要过分重视它的重要性。
答案 1 :(得分:12)
Redux FAQ: Organizing State
redux官方文档的这一部分很好地回答了你的问题。
使用本地组件状态很好。作为开发人员,您的工作是确定应用程序的哪种状态,以及 每个州应该居住的地方。找到适合的余额 你,和它一起去。
确定应该是哪种数据的一些常用经验法则 投入Redux:
- 应用程序的其他部分是否关心此数据?
- 您是否需要能够根据此原始数据创建更多衍生数据?
- 是否使用相同的数据来驱动多个组件?
- 能否将此状态恢复到给定时间点(即时间旅行调试)是否对您有价值?
- 您是否要缓存数据(例如,如果已经存在,请使用状态,而不是重新请求数据)?
答案 2 :(得分:4)
为了突出@ AR7提供的优秀链接,并且因为该链接移动了一段时间:
将React用于与全局应用无关的短暂状态,并且不会以复杂的方式进行变异。例如,某个UI元素中的切换,表单输入状态。将Redux用于全局重要或以复杂方式变异的状态。例如,缓存用户或帖子草稿。
有时你会想要从Redux状态转移到React状态(当在Redux中存储某些东西变得笨拙时)或者反过来(当更多组件需要访问某些曾经是本地的状态时)。
经验法则是:做任何不那么尴尬的事情。
Dan Abramov:https://github.com/reactjs/redux/issues/1287#issuecomment-175351978
答案 3 :(得分:-4)
是的,值得将所有组件状态存储在Redux中。如果这样做,您将受益于Redux的许多功能,例如时间旅行调试和可重播的错误报告。如果您不这样做,则这些功能可能完全不可用。
每当您不在Redux中存储组件状态更改时,该更改将完全从Redux更改堆栈中丢失,并且您的应用程序UI将与存储不同步。如果这对您不重要,请问自己为什么要使用Redux?没有它,您的应用程序将不再那么复杂!
出于性能方面的考虑,您可能希望退回到this.setState()
来处理重复执行许多操作的所有操作。例如:每次用户键入键时,在Redux中存储输入字段的状态可能会导致性能下降。您可以通过将其视为事务来解决此问题:用户操作“提交”后,将最终状态保存在Redux中。
您的原始文章提到Redux方式是如何“编写大量代码的”。是的,但是您可以将抽象用于常见的模式,例如本地组件状态。