Redux

对于SPA应用来说,前端所需要管理的状态越来越多,需要查询、更新、传递的状态也越来越多, 如果让每个组件都存储自身相关的状态,理论上来讲不会影响应用的运行, 但在开发及后续维护阶段,我们将花费大量精力去查询状态的变化过程。

1、预备知识

先提出个疑问:我们为什么需要状态管理?

对于SPA应用来说,前端所需要管理的状态越来越多,需要查询、更新、传递的状态也越来越多, 如果让每个组件都存储自身相关的状态,理论上来讲不会影响应用的运行, 但在开发及后续维护阶段,我们将花费大量精力去查询状态的变化过程, 在多组合组件通信或客户端与服务端有较多交互过程中, 我们往往需要去更新、维护并监听每一个组件的状态,在这种情况下, 如果有一种可以对状态做集中管理的地方是不是会更好呢? 状态管理好比是一个集中在一处的配置箱,当需要更新状态的时候, 我们仅对这个黑箱进行输入,而不用去关心状态是如何分发到每一个组件内部的, 这可以让开发者将精力更好的放在业务逻辑上。

但状态管理并不是必需品,当你的UI层比较简单、没有较多的交互去改变状态的场景下, 使用状态管理方式反倒会让你的项目变的复杂。 例如Redux的发明者Dan Abramov就说过这样一句话: “只有遇到React实在解决不了的问题,你才需要Redux”。

一般来讲,在以下场景下你或许需要使用状态管理机制去维护应用:

  • 用户操作较为繁琐,导致组件间需要有状态依赖关系,如根据多筛选条件来控制其他组件的功能。
  • 客户端权限较多且有不同的使用方式,如管理层、普通层级等。
  • 客户端与服务端有大量交互,例如请求信息实时性要求较高导致需要保证鲜活度。
  • 前端数据缓存部分较多,如记录用户对表单的提交前操作、分页控制等。

另外,本篇文章更关注业务模型层的数据流, 业务模型是指所处领域的业务数据、规则、流程的集合。 即使抛开所有展示层,这一层也可以不依赖于展示层而独立运行, 这里要强调一点,Redux之类的状态管理库充当了一个应用的业务模型层, 并不会受限于如React之类的View层。 假如你已经明白了Redux的定位及应用场景的话,我们来对其原理一探究竟。

2、与react结合使用

3、原理

4、数据流向

我们先来看一下一个完整的Redux数据流是怎样的:

参考资料

Was this helpful?

0 / 0

发表评论 0

Your email address will not be published. Required fields are marked *