Redux 三大原则

原创
2019/01/17 23:44
阅读数 645

1.单一数据源

在传统的MVC架构中,我们可以根据需要创建无数个Model,而Model之间可以互相监听、触发事件甚至循环或嵌套触发事件,这些在Redux中都是不被允许的。 因为在Redux的思想里,一个应用永远只有唯一的数据源。我们的第一反应可能是:如果有一个复杂应用,强制要求唯一的数据源岂不是产生一个特别庞大的JavaScript对象。 实际上,使用单一数据源的好处在于整个应用状态都保存在一个对象中,这样我们随时可以提取整个应用的状态进行持久化(比如实现一个针对整个应用的即时保存功能)。此外,这样的设计也为服务端渲染提供了可能。

2.状态是只读的

这一点和Flux思想不谋而合,,不同的是在Flux,因为store没有setter而限制了我们直接修改应用状态的能力,而在Redux中,这样的限制被执行得更加彻底,因为我们压根没有store。 在Redux中,我们并不会自己用代码来定义一个store。取而代之的是,我们定义一个reducer,它的功能是根据当前触发的action对当前应用状态(state)进行迭代,这里我们并没有直接修改应用状态,而是返回了一份全新的状态。

3.状态修改均由纯函数完成

这是Redux与Flux在表现上最大的不同。在Flux中,我们在actionCreator 里调用AppDispatcher.dispatch 方法来触发action,这样不仅有冗余的代码,而且因为直接修改了store中的数据,将导致无法保存每次数据变化前后的状态。 在Redux里,我们通过定义reducer来确定状态的修改,而每一个reducer都是纯函数,这意味着它没有副作用,即接受一定的输入,必定会得到一定的输出。 这样的设计的好处不仅在于reducer里对状态的修改变得简单、纯粹、可测试,更有意思的是,Redux利用每次新返回的状态生成酷炫的时间旅行(time travel)调试方式,让跟踪每一次因为触发action而改变状态的结果成为了可能。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部