大家好，我是卡颂。
在咱们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一把梭，看待这种执（憨）着（憨）的人，牢记四字箴言：
发表回复