降低Mobx技术债问题-React前端数据流方案调研整理
我们现在主要是使用Mobx，但是Mobx的易于上手和灵活度也带来了很多预期以外的问题，随着项目的增长我们的代码技术债变得愈加沉重，不同的模块杂糅一起、单一store无限膨胀。
为此我们的调研是希望能找到一个更好的state配置、数据流的约定方案。
我们预期解决的问题：
- 更好地控制Mobx的复杂度，正确地拆分Store和管理内部的state。
- 虽然做不到单向数据流，但是数据流走向可追溯。
- 是否能借鉴其他方案的分层管理、人为约定出一个更清晰的处理方案？
- 如何调试组件内Mobx的管理？
- mobx dev tool。
- mobx本身提供的spy API的能力。
- 特殊场景下的方案：
- 能否做到compute 缓存之前的记忆，或者之前的数据和之后对比。
- 主动订阅场景（已解决：通过mobx的reaction）
查阅的相关文章
浅谈React数据流管理
Mvvm 前端数据流框架精讲
前端数据流选型
React 体系下关于 Mobx 与 Redux 的一些思考
数据流管理方案的调研投票
目前来说主要有以下几个投票方案。
react-redux
现有比较火的是react-redux-toolkit，国内常用的umi+dva的方案也是redux的一个封装。
结论
在下面的redux vs mobx
Mobx
Mobx的文档
Mobx-长篇源码解读，一文搞懂原理
MobX State Tree数据组件化开发
浅析了一些源码处理，可作为入门读物：一次搞懂Mobx，项目再也不踩坑_(:3」∠)_
- Mobx
- Mobx-state-tree
- Mobx+immer
结论
经过调研，Mobx-state-tree不就是mobx+immer嘛。然后immer的调研结论在下面，为了不让我们的改造变得更复杂，这些东西都可以以后考虑，因此就不扩展了。
Immer
（讲了使用方式和一些注意事项，但是没有源码解析，推荐阅读） Immer 最佳实践（走心教程）
重构利器：如何用 Immer 优雅地管理应用状态
为什么说 90% 的情况下，immer 完胜 immutable？
(一般)[ Immer 源码 ] 来聊聊 Immer 实现不可变数据结构
不可变数据流的完美解决方案——Immer 源码解读
(一个基础的todolist demo)不可变数据 - Immer.js 改造 reducer
结论
很好的东西，是为了解决副作用问题，但是我们项目应该用不太上，或者说不是必须的。可以先改重要的东西，不要太着急引入新技术栈，否则反而增加开发负担+增加改造的复杂度。
zustand
类似于轻量级的context+redux结合体。有中间件可以方便处理数据。
不过觉得有一个数据流管理就行啦，多了增加开发心智负担，因此不引入。
jotai
懒得看了。
Redux vs Mobx
经过组内讨论，Redux使用起来实在更复杂步骤更多，我们的项目已经很成熟了，转换过去一是浪费大量时间，二是Redux也不一定能解决我们项目现有的技术债问题。
因为我们的问题主要是历史原因，导致store无限膨胀、不同的模块杂糅。
而且相较而言，Mobx有如下优点：
- 作为响应式编程，渲染更快；
- 同一改动的代码量更少。
- 使用高阶hook自动进行浅比较优化性能。
综上，再加上我们原本就是用的mobx，就酱紫了。
Mobx使用约定
- 明确规定不同的模块在不同的mobx store中。
- 非必要不提升状态。页面业务级的数据应当考虑放在context中。明确我们的数据类型，暂时将数据类型分为两部分：1. 业务数据。2. UI状态数据。
mobx存放的是：
- @action需处理和的公共业务数据。
- 涉及多个组件的公共业务数据。
- 控制页面的UI状态数据。
除此之外，下面数据将考虑放置在context / state中。
- 涉及当前组件的UI状态数据。
- 涉及当前组件及子组件的UI状态数据、非公共业务数据。
- 降低复杂度，数据可追溯：一个observable的变量对应一个action，参考redux的形式。
调试Mobx
使用mobx-devtool查看mobx内的数据如何流转，进行调试
- 安装谷歌插件
MobX Developer Tools，可以看到具体的数据变化和字段值。比较可视化。（还有不要下错了还有一个Pro的插件，我试了一点用没有） - mobx spy观察。
import { spy } from 'mobx';
spy(e=>console.log(e))