面试必备：Redux 使用心得

晴转多云

首先我们需要弄清 Redux 模型中的几个组成对象：action 、reducer、store ：

• action：官方的解释是 action 是把数据从应用传到 store 的有效载荷，它是 store 数据的唯一来源；要通过本地或远程组件更改状态，需要分发一个 action；

• reducer：action 发出了做某件事的请求，只是描述了要做某件事，并没有去改变 state 来更新界面，reducer 就是根据 action 的 type 来处理不同的事件；

• store：store 就是把action和 reducer 联系到一起的对象，store本质上是一个状态树，保存了所有对象的状态。任何 UI 组件都可以直接从 store 访问特定对象的状态。

特性

• 唯一数据源：整个应用的 state 被储存在一棵 object tree 中，并且这个 object tree 只存在于唯一一个 store 中。
• 保持状态只读：唯一改变 state 的方法就是触发 action，action 是一个用于描述已发生事件的普通对象。
• 数据改变只能通过纯函数：这里的纯函数就是 Reducer 它函数中包含两个参数 state、action，大致的意思就是通过 action 去改变 state，一般来说是返回一个新的 state
• 预见性：所有的用户的行为都是提前定义好的
• 统一管理 state：所有的状态都在一个store中分配管理

与使用 setState 改变状态的区别

setState

• 使用 setState 时应用程序状态流程
  
  

这种改变状态带来的后果：

• 性能：祖父子组件之间多余的状态传递，导致宝贵的内存资源浪费，同时在界面渲染的速度也会变慢，用户体验就会变差。
• 状态管理：当程序不断的迭代，界面布局也越来越复杂，就会产生许多的 state 状态，没有办法有效的管理这些状态，并且会导致 UI 多次渲染，搞不清楚是哪一步导致 UI 多次渲染，可能我们还会选择 shouldComponentUpdate 来减少子组件中没必要的渲染，但最终还是解决不了状态管理复杂的难题。

Redux

• 使用 Redux 后应用程序状态修成
  
  具体的工作流程
  

在什么情况下用 Redux

• 像父子组件之间相互传值相互调用的情况，并且值的适用范围仅限于父子组件之间，这时不需要使用 Redux.
• 当某个子组件去更新某种状态时，比如更新组织机构数据。而其他的页面又需要依赖这些数据时，此时可以考虑使用 Redux，把这些状态值放入到 Redux 中进行管理。

用之前应该思考两个问题

1. 状态是否同时被多个组件依赖。
2. 状态改变时，是否会引起 UI 的变化。

• 如果不满足第一条，可以直接用组件内部state管理。
• 如果满足第一条但不满足第二条，用全局变量就可以了。

官方文档里也说了，“如果你还在犹豫要不要用的时候，就不要用了”