降低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))