大家好，我是卡颂。
在咱们 React 进阶源码群里，除了 React 外，状态治理 是最常探讨的话题。
诡异的是，有多个群友说过相似的话：
他的共事 / 组长 / 领导 … 让他把所有 state 都放在 Redux/Mobx… 里
他们感觉不对，又不晓得如何反驳。
明天咱们来聊聊 Redux、Mobx 等状态治理库和 React、Vue 等视图库之间的关系，心愿能解决以上困惑。
产品的外围竞争力
如果你在电梯里遇到大领导，他问你：
小 x，你们最近在做什么性能？
在电梯达到楼层前这短短 2 分钟，你该如何向大领导形容你们正在开发的性能呢？
我想你肯定会介绍性能的大体逻辑，而不会聊性能里某个按钮的具体交互逻辑吧？
你会聊 逻辑 ，而不是 交互 。因为 逻辑 是最重要的。
接下来咱们通过一个小故事理解 逻辑 与交互 的关系。
逻辑与交互的关系
一天，老板让你开发文件上传性能。
开发过程其实就是解决 文件上传 这一畛域相干的各种 状态 之间的关系（比方 上传进度 、 是否出错…）。
这部分状态，咱们称为 畛域状态。
逻辑开发完后，你基于各种 畛域状态 编写 单元测试。
为了疾速上线验证该性能是否有人用，你间接将其作为 CLI 工具公布。
几天后，通过数据验证，发现性能很受欢迎。于是你抉择 React 作为视图库，基于之前的逻辑开发视图交互。
开发视图交互过程中须要解决视图相干各种 状态 （比方loading 显隐、 关上敞开状态…）。
这部分状态，咱们称为 视图状态。
可见，一款性能齐备的产品蕴含 畛域状态 与视图状态。前者是必须的，后者是可选的。
视图库中的状态
说回 React、Vue 这样的视图库。
因为大部分视图库以 组件 作为模块边界，所以很天然的，畛域状态 与视图状态 被宰割到不同组件中，但他们被宰割的形式是齐全不同的。
举个例子，一个残缺的利用能够划分为很多组件：
从 视图状态 角度来看这些组件：
比照高低两张图，组件 1（黄色与绿色）大小统一，代表这是个交互逻辑自洽的纯组件（比方一个开关），他的交互逻辑不依赖其余组件。
除了组件 1，更多组件须要与其余组件造成大小互补，这代表他们的交互逻辑相互影响。
比方组件 5 的长宽受组件 2、组件 6、组件 8 影响，可能代表：组件 5 是个提示框，他是否弹出受 2、6、8 影响。
咱们再从 畛域状态（蓝色局部）角度来看这些组件：
整个利用的逻辑扩散在不同组件中，可能组件 1 的 didMount 回调中有一部分逻辑，组件 3 的 useEffect 回调中有一部分逻辑。
因为组件 5 是个提示框，只有提醒成果，所以他不蕴含利用运行所必须的逻辑（即 畛域状态）。
什么时候应用状态治理
回到开篇，什么样的state（状态）应该放在状态治理里？
对于 视图状态：
- 状态自洽的组件本人治理状态（如组件 1）
- 状态相互之间有影响的组件（如 5 与 2、6、8）依据利用复杂度、组件间跨度决定
如果组件跨度比拟近（如是兄弟关系），则公共状态能够晋升到独特父组件。
如果组件跨度较远且利用不简单，能够晋升到独特的 Context 中。
如果利用简单，再思考状态治理计划。
对于 畛域状态，因为其天生以碎片模式散布在不同组件中，所以：
- 简略的小利用能够任其散布在组件中，或者晋升到独特的
Context中 - 其余状况举荐用状态治理计划
甚至，对于 畛域状态 中的子畛域，能够在有 状态治理计划 的根底上再形象进去独自解决。
比方对于 服务端申请的数据 这一 畛域状态 ，其性质更相似于 缓存 ，在React 中能够应用 SWR 或React Query解决。
总结
本文咱们聊了状态的分类 —— 畛域状态 与视图状态，对于这两种状态依据其个性有不同解决计划。
尽管一股脑将所有状态都交给 Redux 解决不是不行，但势必对我的项目的可读性、性能、扩展性造成影响。
学完本文可能压服共事 / 组长 / 领导最好。如果对方执意要 Redux 一把梭，看待这种执（憨）着（憨）的人，牢记四字箴言：