Redux 使用原则

一、你可能真不需要Redux

首先明确一点，Redux 是一个有用的架构，但不是非用不可。事实上，大多数情况，你可以不用它，只用 React 或 React Native 就够了。
曾经有人说过这样一句话：“如果你不知道是否需要 Redux，那就是不需要它。”
Redux 的创造者 Dan Abramov 又补充了一句： “只有遇到 React 实在解决不了的问题，你才需要 Redux 。”
(以上摘自阮一峰老师的博客：Redux 入门教程（一）：基本用法)

我是一位移动端开发者，用 React Native 构建 APP，曾经在两个项目中使用过 Redux。
我的总结是：移动端开发，绝大多数应用场景不需要使用 Redux，除非你的界面状态控制真的很复杂。

二、Redux 需要明确的几个原则

首先，你得明确，Redux 是一个提供单向控制的状态机，状态机！

在此基础上，我总结几个使用误区：

1. 别把 Redux 当作全局存储器。Redux 是状态机，不是数据存储器。“状态”是和页面绑定的，一旦“状态”更新，必定会引起对应页面的重新渲染。如果仅仅是数据处理和存储，为什么要用 Redux 呢？

2. 一个 reducer/state 只对应一个界面 （这个界面可以有很多子控件）。不要搞一对多，否则 state 一旦变化，多个页面会跟着刷新，会产生预期之外的行为。手机端界面和Web是有本质区别的，手机端页面所见即所得，而且页面复杂度比Web页面低，不需要太多联动。

3. 别把 Redux 用作页面之间跳转时的数据传递工具。这个怎么理解呢？本来从页面 A 跳转到页面 B 需要传递数据，一般通过传参就可以。但有人会想到在 A 中把请求到的数据存入 Redux 中的一个状态中，到了页面 B 后把这个数据再取出来。别这样。这就好比，A 要给 B 还钱，本来应该亲手把钱递给 B，而现在 A 把钱压在了路边的一块石头下，让 B 去石头那取钱。这风险得有多高啊。如果需要做隔层传递，可以考虑用 Context。

4. 状态要纵向管理，不要横向管理。一个 state 可以用于一个页面上的多个子控件，这叫纵向管理。但是不要一个 state 用于多个页面。这条类似上述第二条。这里解释一下，有时候有个别场景有这么一个需求：每个界面都要显示一个全局性的信息，比如说用户名，这个用户名可以在设置界面修改，改完之后每个界面都得及时更新。类似这种情况可以用 Redux 。

5. 不要通过 state 的状态变化来判断是否需要跳转。有这样一个场景：在 A 界面发一个请求，如果请求成功，就跳转到 B 界面。之前犯过一个错误，API 返回数据存在 State 中，在 A 界面用 UseEffect 监听这个数据，如果数据有效，则跳转 B 界面。这会导致一个问题，如果第二次进入 A 界面，之前那个 API 返回数据没有被清理，它会自动直接跳转 B 界面。最好的办法是在 dispatch().then 中跳转，不要依赖数据状态。

三、实践结论

• 一般情况下，React Native 项目不需要用 Redux。自带的状态机制可以满足绝大部分应用场景。除非一个页面上，有很多很多控件，这些控件要根据一个或多个状态集体响应。换句话说，就是某个复杂的界面上一个动作会触发很多控件的响应。

• 在做技术选型和框架选择时，应该把“是否适合业务”放在第一位，而不是根据框架“是否流行”或“是否炫酷”。