⚡ 30 秒速记
- 可观察属性在跟踪函数中被读取，建立依赖
- 改动只通知依赖它的计算或反应
computed表达派生数据，reaction处理副作用action约束写入与批量更新- 异步回调里的读取不会沿用之前的同步跟踪
MobX 会记住一段受跟踪代码读过哪些可观察属性，属性变化后再通知相关工作。 组件、派生计算和副作用因此不必手写大量订阅关系，但读取必须发生在正确的跟踪范围内。派生值放在计算属性，修改集中在动作里，外部订阅则保留清理函数。异步回调稍后读取的数据不会自动算进先前那次依赖收集，排查不更新时要看实际读取位置。
版本校准： 本文若分析 ReactDOM.render、旧生命周期或栈调和，应把它视为理解架构演进的历史路径。React 19 已移除 ReactDOM.render，当前客户端入口使用 createRoot；并发渲染也必须区分可中断的渲染阶段与同步提交阶段。迁移前对照 React 19 官方升级指南。
# 一、认识MobX
打印
mobx，看看mobx中有什么
MobX的整个流程
MobX 和 Redux 的比较
Redux是单一数据源，而MobX往往是多个store。MobX可以根据应用的UI、数据或业务逻辑来组织store，具体如何进行需要你自己进行权衡Redux store使用普通的JavaScript对象结构，MobX将常规JavaScript对象包裹，赋予observable的能力，通过隐式订阅，自动跟踪observable的变化。MobX是观察引用的，在跟踪函数中（例如：computed value、reactions等等），任何被引用的observable的属性都会被记录，一旦引用改变，MobX将作出反应。注意，不在跟踪函数中的属性将不会被跟踪，在异步中访问的属性也不会被跟踪Redux的state是只读的，只能通过将之前的state与触发的action结合，产生新的state，因此是纯净的（pure）。而MobX的state即可读又可写，action是非必须的，可以直接赋值改变，因此是不纯净的（Impure）Redux需要你去规范化你的state，Immutable数据使Reducer在更新时需要将状态树的祖先数据进行复制和更新，新的对象会导致与之connect的所有UI组件都重复渲染。因此Redux state不建议进行深层嵌套，或者需要我们在组件中用shouldComponentUpdate优化。而MobX只自动更新你所关心的，不必担心嵌套带来的重渲染问题
redux管理的是 (STORE->VIEW->ACTION) 的整个闭环，而mobx只关心STORE->VIEW的部分
优点
- 基于运行时的数据订阅
mobx的数据依赖始终保持了最小，而且还是基于运行时。而如果用redux，可能一不小心就多订阅或者少订阅了数据。所以为了达到高性能，我们需要借助PureRenderMixin以及reselect对selector做缓存 - 通过 OOP 的方式组织领域模型 (domain model)
OOP的方式在某些场景下会比较方便，尤其是容易抽取domain model的时候。进而由于mobx支持引用的方式引用数据，所以可以非常容易得形成模型图 (model graph )，这样可以更好地理解我们的应用。 - 修改数据方便自然
mobx是基于原生的JavaScript对象、数组和Class实现的。所以修改数据不需要额外语法成本，也不需要始终返回一个新的数据，而是直接操作数据
