数据树的依赖注入：mobx-keystone Contexts如何让子模型摆脱父级结构耦合

数据树的依赖注入：mobx-keystone Contexts如何让子模型摆脱父级结构耦合

【免费下载链接】mobx-keystoneA MobX powered state management solution based on data trees with first class support for Typescript, support for snapshots, patches and much more项目地址: https://gitcode.com/gh_mirrors/mo/mobx-keystone

在 mobx-keystone 中，Contexts（上下文）就是数据树的"依赖注入"机制：它让任意层级的子模型向上查找并共享环境数据，而无需关心数据具体来自哪个父节点。掌握它之后，你的模型代码更松耦合，单元测试也不再被迫构造完整的根存储。

为什么需要 Contexts：数据树里的"找爸爸"难题 🧩

mobx-keystone 把应用状态组织成一棵受保护的数据树，每个模型节点都可以通过 getRoot 拿到根节点。但一旦深层子模型开始依赖getRoot()，两个问题就出现了：

官方文档的比喻很到位：把 Contexts 理解为树节点的依赖注入（dependency injection for tree nodes）。典型场景——深层子模型需要"当前用户名"。不用 Contexts 时它只能getRoot()去爬；用了之后，父级负责提供值，子级只负责取用，彼此不知道对方是谁。

三步上手：Contexts 的核心用法

整个机制围绕一个createContext创建的类型安全上下文对象展开，核心 API 定义见 packages/lib/src/context/context.ts。

第 1 步：创建一个上下文

const usernameCtx = createContext<string>()

第 2 步：父级提供（Provider）

在父模型的onInit里把值"挂"到树上，可以是静态值，也可以是响应式的计算值：

class SomeParent extends Model({ username: prop<string>() }) { onInit() { // 推荐：计算值，父级 username 变化时子级自动感知 usernameCtx.setComputed(this, () => this.username) } }

第 3 步：子级取用（Consumer）

任意深度的子模型在动作或 computed 中直接取值即可：

@computed get someComputedThatRequiresUsername() { return usernameCtx.get(this) + " is awesome!" }

ctx.get(node)的解析规则只有一条：从该节点出发向上逐级查找，命中最近一个"提供者"就停；一个都没有就用默认值。这个"最近祖先优先"的设计正是解耦的关键——子模型完全不关心值来自哪一层。

Contexts 完整 API 速查表 📋

以下方法全部定义在Context接口中，实现见 ContextClass：

💡 小建议：get(node)返回的是响应式值，切勿缓存它——父级一变，缓存就过期了。官方文档在 apps/site/docs/contexts.mdx 中特别强调了这一点。

进阶技巧：apply 注入"无状态数据"

有一类数据不属于模型属性、不该进快照（比如当前会话、构造时的一次性参数），但onInit里却要用。这时用apply包裹构造过程：

const envCtx = createContext(0) const m = envCtx.apply(() => new M({}), 9000) // m 在 onInit 中读到 9000；apply 结束覆盖自动失效

apply的价值在于它同样适用于fromSnapshot、clone等 API——重建整棵子树时也能让每个节点在初始化阶段读到指定环境值。相关行为在测试文件 packages/lib/test/context/context.test.ts 中有完整覆盖，包括apply后子节点、快照再还原后都正确生效的断言。

单元测试：Contexts 最大的红利 ✅

对比一下没有 Contexts 的测试写法，差别一目了然：

// 无需搭建根存储，给孤立的子模型注入测试值即可 const child = new SomeDeepChild({}) usernameCtx.set(child, "RandomUsername") expect(child.someComputedThatRequiresUsername) .toBe("RandomUsername is awesome!")

因为任何节点都可以成为提供者，子模型测试时直接把自己变成 provider 就行。这也意味着：

• 测试只关心"我需要什么值"，不关心"值从哪来"
• 同一份模型代码，生产环境挂在应用树上由父级供值，测试环境独立供值，零适配成本
• 值变了会触发响应式更新，reaction场景下的行为在测试中同样可验证

实践避坑清单 ⚠️

1. 静态值 vs 计算值：set是"一次定死"，setComputed才是响应式的。父级属性会变，就用setComputed，否则子级读到的是快照而非活值。
2. 提供者被移除会回落：当提供上下文的父节点从树上断开时，其下所有后代自动回落到默认值（或上层提供者）。官方测试专门验证了这个行为，写动态增删子树的逻辑时要心中有数。
3. unset是"穿透"而非"置空"：取消提供后该节点继续向上查找，可能命中更上层祖先的值，而不是变成undefined。
4. getProviderNode是调试利器：排查"这个值到底谁给的"时，它比反复断点高效得多。

什么时候用 Contexts，什么时候用 getRoot？

经验法则：如果子模型对父级的依赖"越界"了一层以上，或该依赖在测试中难以构造，就换成 Contexts。

总结：一张树、一套注入协议

mobx-keystone 的 Contexts 用"最近祖先优先"的解析规则，把前端世界里 React Context 式的依赖注入搬进了数据树：

• 🌲父级提供、子级取用，双方互不知晓，结构彻底解耦
• ⚡get响应式且自动追踪 MobX 依赖，值变更处处可感知
• 🧪 孤立节点也能自供值，单元测试摆脱根存储束缚
• 🔌apply系列补齐了"构造期注入易变数据"的最后一块拼图

从 packages/lib/src/context/ 目录开始阅读源码，配合官方文档 apps/site/docs/contexts.mdx，你花半小时就能把这套机制用到自己的模型里。数据树负责"状态怎么组织"，Contexts 负责"依赖怎么传递"——两者合起来，才是 mobx-keystone 面对大型应用时真正从容的原因。

【免费下载链接】mobx-keystoneA MobX powered state management solution based on data trees with first class support for Typescript, support for snapshots, patches and much more项目地址: https://gitcode.com/gh_mirrors/mo/mobx-keystone