降低Mobx技术债问题-React前端数据流方案调研整理

我们现在主要是使用Mobx，但是Mobx的易于上手和灵活度也带来了很多预期以外的问题，随着项目的增长我们的代码技术债变得愈加沉重，不同的模块杂糅一起、单一store无限膨胀。
为此我们的调研是希望能找到一个更好的state配置、数据流的约定方案。
我们预期解决的问题：

1. 更好地控制Mobx的复杂度，正确地拆分Store和管理内部的state。
2. 虽然做不到单向数据流，但是数据流走向可追溯。

• 是否能借鉴其他方案的分层管理、人为约定出一个更清晰的处理方案？

3. 如何调试组件内Mobx的管理？

• mobx dev tool。
• mobx本身提供的spy API的能力。

4. 特殊场景下的方案：

• 能否做到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有如下优点：

1. 作为响应式编程，渲染更快；
2. 同一改动的代码量更少。
3. 使用高阶hook自动进行浅比较优化性能。

综上，再加上我们原本就是用的mobx，就酱紫了。

Mobx使用约定

1. 明确规定不同的模块在不同的mobx store中。
2. 非必要不提升状态。页面业务级的数据应当考虑放在context中。明确我们的数据类型，暂时将数据类型分为两部分：1. 业务数据。2. UI状态数据。

mobx存放的是：

• @action需处理和的公共业务数据。
• 涉及多个组件的公共业务数据。
• 控制页面的UI状态数据。

除此之外，下面数据将考虑放置在context / state中。

• 涉及当前组件的UI状态数据。
• 涉及当前组件及子组件的UI状态数据、非公共业务数据。

3. 降低复杂度，数据可追溯：一个observable的变量对应一个action，参考redux的形式。

调试Mobx

使用mobx-devtool查看mobx内的数据如何流转，进行调试

• 安装谷歌插件MobX Developer Tools，可以看到具体的数据变化和字段值。比较可视化。（还有不要下错了还有一个Pro的插件，我试了一点用没有）
• mobx spy观察。

import { spy } from 'mobx';
spy(e=>console.log(e))