react redux介绍
React Redux 是 Redux 的官方 React UI 绑定层。它允许您的 React 组件从 Redux 存储中读取数据，并将操作分派到存储以更新状态。
简单来说，就是一个react官方支持的状态管理库。star数超2W,不可谓不火。但是今天要谈的不是他的优点和主流地位，而是谈使用它过程中可能遇到的陷阱。
陷阱——陈旧props和僵尸children
陈旧props和僵尸children（Stale Props and "Zombie Children）
简单来说，在某些条件下（因为长，等会细说），会触发这两个问题。
陈旧props：数据源中明明修改了数据，但是给子组件的props不更新 僵尸children：数据源中明明删掉了children对应的项，但是视图上children顽强的活着。
根据官方说法：在实践中，这些问题很少见——我们收到的关于文档中这些问题的评论远远多于关于这些问题是应用程序中真正问题的实际报告。
官方大意就是这是一个广受关注，但实际上发生次数很少的问题。接下来我，详细说一下，他们发生的条件：
陈旧props触发条件：
- 选择器函数依赖于该组件的 props 来提取数据
- 作为一个动作的结果，父组件会重新渲染并传递新的道具
- 但是这个组件的选择器函数在这个组件有机会用这些新道具重新渲染之前执行
选择器函数指的是： A "selector function" is any function that accepts the Redux store state (or part of the state) as an argument, and returns data that is based on that state. “选择器函数”是接受 Redux 存储状态（或状态的一部分）作为参数并返回基于该状态的数据的任何函数。 不了解基础概念的，看一看官方链接： Basic Selector Concepts
其中前两个操作是我们经常使用，最后一个在没有渲染之前重新执行，恐怕只有回调事件（网络访问，异步事件回调等）才会满足。这时候，如果做了检查就不会有问题了，是可以避免的。
陈旧props触发条件：
- 多个嵌套的连接组件在第一遍中安装，导致子组件在其父组件之前订阅商店
- 调度一个从存储中删除数据的操作，例如待办事项 结果，父组件将停止渲染该子组件
- 但是，因为子项先订阅，所以它的订阅会在父项停止呈现之前运行。
- 当它根据 props 从 store 中读取一个值时，该数据不再存在，如果提取逻辑不小心，这可能会导致抛出错误。
嗯，其实我觉得这是一个使用方式的问题，这种bug可以说是设计之初就决定不能这样使用的。想要更改，代价颇大，不如开个会说明白就好了。
当然，在陈旧props和僵尸children（Stale Props and "Zombie Children）一文中，官方说了用useSeletor()拦截问题的方法，有兴趣的同学可以瞅瞅。
以上，就是我关于react redux 陷阱的分享。欢迎交流，提建议。拜拜。
