Ember.js 内部机制Glimmer 响应式系统的 Tag 组合Tag Composition代数原理解析【免费下载链接】ember.jsEmber.js - A JavaScript framework for creating ambitious web applications项目地址: https://gitcode.com/gh_mirrors/em/ember.jsGlimmer 的响应式系统建立在一个极简的代数原语 ——Tag之上Tag 运行在一条单调递增的修订时间线revision timeline上并通过跟踪帧tracking frame完成组合。本文以仓库文档 internal-docs/guides/reactivity/tag-composition.md 为主体骨架结合glimmer/validator生产实现与internal-docs/guides/reactivity/pseudocode伪代码逐层拆解 Tag、Mutable Tag、Combined Tag、Tracking Frame 的代数语义与源码实现。读完你将理解 Glimmer 如何在不重算值、不做相等比较的前提下完成细粒度的失效验证以及tracked、createCache等抽象如何在这套代数上搭建起来。Tag验证代数的最小原语Glimmer 的响应式系统并不像大多数响应式框架那样围绕值展开而是围绕如何判断一个值是否需要重新计算展开。文档明确指出Tags intentionally exist as a separate layer from the reactive values they represent, creating a clean separation between validation algebra and value semantics.即Tag 与其所代表的值是分离的两个层面一层是验证代数validation algebra负责回答某个快照是否仍然有效另一层是值的语义value semantics负责承载实际数据。这种分离使 Glimmer 可以在不重算值、也不执行相等比较的情况下完成对响应式计算的有效性验证——虽然它因此不提供基于引用相等的失效传播截断reference-equality-based cutoff但换来了可靠的细粒度验证以及通过等价规则对根状态失效进行受控管理。文档给出了这一体系的核心代数原语汇总如下原语语义Revision Timeline修订时间线一条单调递增的序列每次递增代表一次原子变更新修订严格大于所有历史修订Tag有状态对象表示其关联值/计算在时间线上最后一次变更时的修订号时间戳可被保留用于在不重算值的前提下判断旧快照是否仍有效所有 Tag 都支持[Consume]操作即在被访问时记录到当前跟踪帧中Value Tag值 Tag最基本的 Tag 类型跟踪单个值何时变化Mutable Tag可变 Tag可被显式更新的 Tag支持[Update]推进时间线并记录新修订与[Freeze]将 Tag 标记为不可变使其访问不再被记录进跟踪帧Combined Tag组合 Tag多个 Tag 修订的 join取最大值代数上保证只要任一组成 Tag 失效组合 Tag 必然失效Tracking Frame跟踪帧收集一次计算过程中被消费的 Tag 的收集器支持[Begin]创建有界的收集上下文与[Commit]关闭收集作用域并产出组合 TagTracking Stack跟踪栈由嵌套跟踪帧构成的层级结构表示当前计算层次使响应式跟踪可以跨函数边界组合这套原语在伪代码 internal-docs/guides/reactivity/pseudocode/tags.ts 中有最直接的定义Tag接口只暴露一个revision读取器Runtime接口定义了consume、current、advance、begin、commit五个操作恰好对应上述[Consume]、[Update]经由advance、[Begin]、[Commit]的代数操作而MutableTag类内部持有一个#revisionupdate()方法调用runtime.advance()后把新修订写回自身。修订时间线Revision Timeline的代数规则文档对修订时间线给出了四条精确规则初始修订Initial Revision时间线从修订1开始常量修订Constant Revision特殊修订0表示永不变更的值修订为0的 Tag 不参与跟踪时间线推进Timeline Advancement每次原子更新恰好把全局时间线推进一次修订比较Revision Comparison两个 Tag 可以通过比较各自的修订号来判断先后。常量修订0的特殊待遇文档特别强调修订0常量修订在代数中享受特殊待遇——修订为0的 Tag 不参与跟踪且一个只包含常量 Tag 的帧本身被视为常量。这一规则在生产代码packages/glimmer/validator/lib/validators.ts中有完全对应的实现export const CONSTANT: Revision 0; // 常量修订 export const INITIAL: Revision 1; // 初始修订 export const VOLATILE: Revision NaN; // 易变修订见下文 export let $REVISION INITIAL; export function bump(): void { $REVISION; }见 validators.ts可以看到全局修订计数器$REVISION从INITIAL即1起步bump()每次只递增一次——这正是单调递增与每次原子更新恰好推进一次的实现证据。此外时间线上还有第三个特殊值VOLATILE NaN它表示每次读取都视为已变更用于处理无法静态跟踪的动态值如某些 DOM 相关读取这是文档没有展开、但源码中可以确认的补充细节。在跟踪帧层面修订为0的 Tag 不参与跟踪在packages/glimmer/validator/lib/tracking.ts的Tracker.add中直接体现add(tag: Tag) { if (tag CONSTANT_TAG) return; // 常量 Tag 直接被丢弃不进入收集集合 this.tags.add(tag); ... }见 tracking.ts而Tracker.combine()同样遵循代数语义集合为空返回CONSTANT_TAG只有一个成员直接返回该 Tag多于一个才真正执行combine见 tracking.ts。验证而不重算valueForTag / validateTag不重算值即可判断有效性在源码中的落地是valueForTag与validateTag两个函数export function valueForTag(tag: Tag): Revision { return tag[COMPUTE](); } export function validateTag(tag: Tag, snapshot: Revision): boolean { return snapshot tag[COMPUTE](); }见 validators.tsvalueForTag从 Tag 上取一个不透明的修订快照之后把同一个 Tag 与新取得的修订交给validateTag只要snapshot 当前修订就认为仍然有效。整个验证过程只比较数字不触碰任何值、不执行任何相等比较——这正是文档开头所述架构选择的直接体现。Combined Tag 的组合语义join取最大值Combined Tag 是这套代数中最关键的组合机制。文档给出的定义是A tag that represents the join (maximum) of multiple tag revisions. This join operation maintains the algebraic property that if any constituent tag invalidates, the combined tag also invalidates.即组合 Tag 是多个 Tag 修订的join最大值并保持如下代数性质任一组成 Tag 失效 ⇒ 组合 Tag 失效。这是反向的与关系——只要有一个依赖失效整体就必须失效。生产实现MonomorphicTagImpl.combinepackages/glimmer/validator/lib/validators.ts完整地实现了这一语义static combine(this: void, tags: Tag[]): Tag { switch (tags.length) { case 0: return CONSTANT_TAG; // 空组合 常量 case 1: return tags[0] as Tag; // 单成员组合 该成员自身 default: { let tag: MonomorphicTagImpl new MonomorphicTagImpl(COMBINATOR_TAG_ID); tag.subtag tags; // 多成员组合 组合器持有全部子 Tag return tag; } } }见 validators.ts组合器的[COMPUTE]实现逐一遍历子 Tag取所有修订的最大值作为自身修订if (Array.isArray(subtag)) { for (const tag of subtag) { let value tag[COMPUTE](); revision Math.max(value, revision); // join max } }见 validators.ts由此可以推断组合 Tag 的修订恒等于所有组成 Tag 修订的最大值任何组成 Tag 的dirtyTag内部执行revision $REVISION见 validators.ts都会把最大值推高从而让组合 Tag 失效——这就是文档所述代数性质在源码层面的印证。同时combine对0 / 1 / n三种情况的分别处理保证了组合操作在代数上是零开销短路的空组合直接是常量单成员组合不产生任何新对象。值得注意的还有updateTag[Update]的生产实现导出为UPDATE_TAG见 validators.ts它允许一个 Updatable Tag 的动态子 Tag 被替换并利用subtagBufferCache处理父 Tag 已缓存而新子 Tag 修订更大的时序问题——第一次挂载新子 Tag 时记录其计算值只有当它真正变更后才让父 Tag 反映新修订从而避免缓存被错误击穿。这与MutableTag的[Update]语义一一对应。Tracking Frame 与 Tracking Stack跨函数边界的组合跟踪跟踪帧是 Tag 组合在执行期的载体。文档定义了帧的两个操作[Begin]创建一个有界的 Tag 收集上下文[Commit]关闭收集作用域把期间收集到的所有 Tag 合成一个 Combined Tag。而跟踪栈则是帧的嵌套结构代表当前计算层次使组合可以跨函数边界进行——内层函数消费的 Tag 会随着内层帧的Commit冒泡到外层帧最终汇入最外层计算的整体依赖集合。生产实现Tracker 与帧栈packages/glimmer/validator/lib/tracking.ts用Tracker类 显式帧栈实现了这套语义class Tracker { private tags new SetTag(); private last: Tag | null null; add(tag: Tag) { ... } // 收集被消费的 Tag跳过常量 Tag combine(): Tag { ... } // 0/1/n 三种情况的组合 } let CURRENT_TRACKER: Tracker | null null; const OPEN_TRACK_FRAMES: (Tracker | null)[] []; export function beginTrackFrame(debuggingContext?: string | false): void { OPEN_TRACK_FRAMES.push(CURRENT_TRACKER); // 保存外层帧 CURRENT_TRACKER new Tracker(); // 建立新帧 ... } export function endTrackFrame(): Tag { ... CURRENT_TRACKER OPEN_TRACK_FRAMES.pop() || null; // 恢复外层帧 return unwrap(current).combine(); // 产出组合 Tag }见 tracking.tsOPEN_TRACK_FRAMES数组就是文档所说的Tracking StackbeginTrackFrame把当前帧压栈并新建帧endTrackFrame把当前帧的收集结果combine成 Tag 并弹栈恢复外层帧。代码注释还点明了嵌套组合的关键行为每个被跟踪计算都有一个 Tag对应它自身内部包括子计算消费过的所有被跟踪属性且子帧产出的 Tag 会被添加到父帧——这就是跨函数边界的组合式跟踪。伪代码中的 Runtime 契约伪代码 tags.ts 把同样的语义抽象成Runtime接口便于独立验证代数正确性consume(tag)在当前帧若有中记录一次 Tag 消费current()返回时间线当前修订advance()推进修订计数器并返回新修订begin()开启新帧之后的consume都归属于该帧commit()结束当前帧返回该帧期间所有消费 Tag 的组合 Tag若存在外层帧则外层帧会消费这个返回值完成向上冒泡。从代数原语到响应式抽象伪代码验证internal-docs/guides/reactivity目录下的 pseudocode/primitives.ts 与 pseudocode/composition.ts 展示了如何在这套 Tag 代数之上搭建真实可用的响应式抽象——它们是生产代码的简化示意但完整保留了代数约束目录入口 index.md 对此有明确说明。PrimitiveCell一份根状态存储内部持有一个MutableTagwrite()先tag.update()再写值保证值变更 修订推进的原子对应关系。Snapshot在某个修订点捕获值 Tag二元组作为后续有效性判断的基准。PrimitiveCache带缓存的公式计算。read()时若缓存修订仍 其 Tag 修订则直接消费 Tag 并返回缓存值否则begin()→ 执行计算 →commit()得到组合 Tag → 缓存值 组合 Tag 当前修订。这正是文档中公式formula的修订是其上次计算所用成员的最新修订的落地。composition.ts中的tracked装饰器实现读取属性时tag.consume()写入时tag.update()——从源码可见tracked的本质就是一个MutableTag 一对 getter/setter完全建立在本篇文章的代数原语之上。这也呼应了姊妹文档 laws.md 中定义的六大响应式定律依赖跟踪、值一致性、事务一致性、快照不可变、定义粒度、等价性约定——所有抽象都必须满足这些定律才能保证组合后的系统可靠。想深入理解抽象如何满足定律、以及渲染与自动跟踪的联动可以继续阅读 reactive-abstractions.md、system-phases.md 与 autotracked-rendering.md。总结Tag 组合体系为 Glimmer 提供了三层清晰的能力时间线给出全局单调的失效度量初始1、常量0、易变NaN三种特殊修订Tag 家族Value / Mutable / Combined提供单点与聚合的失效表达组合 Tag 通过 join取最大值保证任一依赖失效则整体失效跟踪帧与跟踪栈把运行时的一次次consume收集为组合 Tag并跨函数边界向上冒泡。验证路径valueForTag/validateTag全程只比较修订数字不重算值、不做相等比较——这正是 Glimmer 响应式系统在可预测性与性能上独树一帜的根源也是tracked、createCache等日常 API 得以成立的地基。【免费下载链接】ember.jsEmber.js - A JavaScript framework for creating ambitious web applications项目地址: https://gitcode.com/gh_mirrors/em/ember.js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Ember.js 内部机制：Glimmer 响应式系统的 Tag 组合（Tag Composition）代数原理解析
Ember.js 内部机制Glimmer 响应式系统的 Tag 组合Tag Composition代数原理解析【免费下载链接】ember.jsEmber.js - A JavaScript framework for creating ambitious web applications项目地址: https://gitcode.com/gh_mirrors/em/ember.jsGlimmer 的响应式系统建立在一个极简的代数原语 ——Tag之上Tag 运行在一条单调递增的修订时间线revision timeline上并通过跟踪帧tracking frame完成组合。本文以仓库文档 internal-docs/guides/reactivity/tag-composition.md 为主体骨架结合glimmer/validator生产实现与internal-docs/guides/reactivity/pseudocode伪代码逐层拆解 Tag、Mutable Tag、Combined Tag、Tracking Frame 的代数语义与源码实现。读完你将理解 Glimmer 如何在不重算值、不做相等比较的前提下完成细粒度的失效验证以及tracked、createCache等抽象如何在这套代数上搭建起来。Tag验证代数的最小原语Glimmer 的响应式系统并不像大多数响应式框架那样围绕值展开而是围绕如何判断一个值是否需要重新计算展开。文档明确指出Tags intentionally exist as a separate layer from the reactive values they represent, creating a clean separation between validation algebra and value semantics.即Tag 与其所代表的值是分离的两个层面一层是验证代数validation algebra负责回答某个快照是否仍然有效另一层是值的语义value semantics负责承载实际数据。这种分离使 Glimmer 可以在不重算值、也不执行相等比较的情况下完成对响应式计算的有效性验证——虽然它因此不提供基于引用相等的失效传播截断reference-equality-based cutoff但换来了可靠的细粒度验证以及通过等价规则对根状态失效进行受控管理。文档给出了这一体系的核心代数原语汇总如下原语语义Revision Timeline修订时间线一条单调递增的序列每次递增代表一次原子变更新修订严格大于所有历史修订Tag有状态对象表示其关联值/计算在时间线上最后一次变更时的修订号时间戳可被保留用于在不重算值的前提下判断旧快照是否仍有效所有 Tag 都支持[Consume]操作即在被访问时记录到当前跟踪帧中Value Tag值 Tag最基本的 Tag 类型跟踪单个值何时变化Mutable Tag可变 Tag可被显式更新的 Tag支持[Update]推进时间线并记录新修订与[Freeze]将 Tag 标记为不可变使其访问不再被记录进跟踪帧Combined Tag组合 Tag多个 Tag 修订的 join取最大值代数上保证只要任一组成 Tag 失效组合 Tag 必然失效Tracking Frame跟踪帧收集一次计算过程中被消费的 Tag 的收集器支持[Begin]创建有界的收集上下文与[Commit]关闭收集作用域并产出组合 TagTracking Stack跟踪栈由嵌套跟踪帧构成的层级结构表示当前计算层次使响应式跟踪可以跨函数边界组合这套原语在伪代码 internal-docs/guides/reactivity/pseudocode/tags.ts 中有最直接的定义Tag接口只暴露一个revision读取器Runtime接口定义了consume、current、advance、begin、commit五个操作恰好对应上述[Consume]、[Update]经由advance、[Begin]、[Commit]的代数操作而MutableTag类内部持有一个#revisionupdate()方法调用runtime.advance()后把新修订写回自身。修订时间线Revision Timeline的代数规则文档对修订时间线给出了四条精确规则初始修订Initial Revision时间线从修订1开始常量修订Constant Revision特殊修订0表示永不变更的值修订为0的 Tag 不参与跟踪时间线推进Timeline Advancement每次原子更新恰好把全局时间线推进一次修订比较Revision Comparison两个 Tag 可以通过比较各自的修订号来判断先后。常量修订0的特殊待遇文档特别强调修订0常量修订在代数中享受特殊待遇——修订为0的 Tag 不参与跟踪且一个只包含常量 Tag 的帧本身被视为常量。这一规则在生产代码packages/glimmer/validator/lib/validators.ts中有完全对应的实现export const CONSTANT: Revision 0; // 常量修订 export const INITIAL: Revision 1; // 初始修订 export const VOLATILE: Revision NaN; // 易变修订见下文 export let $REVISION INITIAL; export function bump(): void { $REVISION; }见 validators.ts可以看到全局修订计数器$REVISION从INITIAL即1起步bump()每次只递增一次——这正是单调递增与每次原子更新恰好推进一次的实现证据。此外时间线上还有第三个特殊值VOLATILE NaN它表示每次读取都视为已变更用于处理无法静态跟踪的动态值如某些 DOM 相关读取这是文档没有展开、但源码中可以确认的补充细节。在跟踪帧层面修订为0的 Tag 不参与跟踪在packages/glimmer/validator/lib/tracking.ts的Tracker.add中直接体现add(tag: Tag) { if (tag CONSTANT_TAG) return; // 常量 Tag 直接被丢弃不进入收集集合 this.tags.add(tag); ... }见 tracking.ts而Tracker.combine()同样遵循代数语义集合为空返回CONSTANT_TAG只有一个成员直接返回该 Tag多于一个才真正执行combine见 tracking.ts。验证而不重算valueForTag / validateTag不重算值即可判断有效性在源码中的落地是valueForTag与validateTag两个函数export function valueForTag(tag: Tag): Revision { return tag[COMPUTE](); } export function validateTag(tag: Tag, snapshot: Revision): boolean { return snapshot tag[COMPUTE](); }见 validators.tsvalueForTag从 Tag 上取一个不透明的修订快照之后把同一个 Tag 与新取得的修订交给validateTag只要snapshot 当前修订就认为仍然有效。整个验证过程只比较数字不触碰任何值、不执行任何相等比较——这正是文档开头所述架构选择的直接体现。Combined Tag 的组合语义join取最大值Combined Tag 是这套代数中最关键的组合机制。文档给出的定义是A tag that represents the join (maximum) of multiple tag revisions. This join operation maintains the algebraic property that if any constituent tag invalidates, the combined tag also invalidates.即组合 Tag 是多个 Tag 修订的join最大值并保持如下代数性质任一组成 Tag 失效 ⇒ 组合 Tag 失效。这是反向的与关系——只要有一个依赖失效整体就必须失效。生产实现MonomorphicTagImpl.combinepackages/glimmer/validator/lib/validators.ts完整地实现了这一语义static combine(this: void, tags: Tag[]): Tag { switch (tags.length) { case 0: return CONSTANT_TAG; // 空组合 常量 case 1: return tags[0] as Tag; // 单成员组合 该成员自身 default: { let tag: MonomorphicTagImpl new MonomorphicTagImpl(COMBINATOR_TAG_ID); tag.subtag tags; // 多成员组合 组合器持有全部子 Tag return tag; } } }见 validators.ts组合器的[COMPUTE]实现逐一遍历子 Tag取所有修订的最大值作为自身修订if (Array.isArray(subtag)) { for (const tag of subtag) { let value tag[COMPUTE](); revision Math.max(value, revision); // join max } }见 validators.ts由此可以推断组合 Tag 的修订恒等于所有组成 Tag 修订的最大值任何组成 Tag 的dirtyTag内部执行revision $REVISION见 validators.ts都会把最大值推高从而让组合 Tag 失效——这就是文档所述代数性质在源码层面的印证。同时combine对0 / 1 / n三种情况的分别处理保证了组合操作在代数上是零开销短路的空组合直接是常量单成员组合不产生任何新对象。值得注意的还有updateTag[Update]的生产实现导出为UPDATE_TAG见 validators.ts它允许一个 Updatable Tag 的动态子 Tag 被替换并利用subtagBufferCache处理父 Tag 已缓存而新子 Tag 修订更大的时序问题——第一次挂载新子 Tag 时记录其计算值只有当它真正变更后才让父 Tag 反映新修订从而避免缓存被错误击穿。这与MutableTag的[Update]语义一一对应。Tracking Frame 与 Tracking Stack跨函数边界的组合跟踪跟踪帧是 Tag 组合在执行期的载体。文档定义了帧的两个操作[Begin]创建一个有界的 Tag 收集上下文[Commit]关闭收集作用域把期间收集到的所有 Tag 合成一个 Combined Tag。而跟踪栈则是帧的嵌套结构代表当前计算层次使组合可以跨函数边界进行——内层函数消费的 Tag 会随着内层帧的Commit冒泡到外层帧最终汇入最外层计算的整体依赖集合。生产实现Tracker 与帧栈packages/glimmer/validator/lib/tracking.ts用Tracker类 显式帧栈实现了这套语义class Tracker { private tags new SetTag(); private last: Tag | null null; add(tag: Tag) { ... } // 收集被消费的 Tag跳过常量 Tag combine(): Tag { ... } // 0/1/n 三种情况的组合 } let CURRENT_TRACKER: Tracker | null null; const OPEN_TRACK_FRAMES: (Tracker | null)[] []; export function beginTrackFrame(debuggingContext?: string | false): void { OPEN_TRACK_FRAMES.push(CURRENT_TRACKER); // 保存外层帧 CURRENT_TRACKER new Tracker(); // 建立新帧 ... } export function endTrackFrame(): Tag { ... CURRENT_TRACKER OPEN_TRACK_FRAMES.pop() || null; // 恢复外层帧 return unwrap(current).combine(); // 产出组合 Tag }见 tracking.tsOPEN_TRACK_FRAMES数组就是文档所说的Tracking StackbeginTrackFrame把当前帧压栈并新建帧endTrackFrame把当前帧的收集结果combine成 Tag 并弹栈恢复外层帧。代码注释还点明了嵌套组合的关键行为每个被跟踪计算都有一个 Tag对应它自身内部包括子计算消费过的所有被跟踪属性且子帧产出的 Tag 会被添加到父帧——这就是跨函数边界的组合式跟踪。伪代码中的 Runtime 契约伪代码 tags.ts 把同样的语义抽象成Runtime接口便于独立验证代数正确性consume(tag)在当前帧若有中记录一次 Tag 消费current()返回时间线当前修订advance()推进修订计数器并返回新修订begin()开启新帧之后的consume都归属于该帧commit()结束当前帧返回该帧期间所有消费 Tag 的组合 Tag若存在外层帧则外层帧会消费这个返回值完成向上冒泡。从代数原语到响应式抽象伪代码验证internal-docs/guides/reactivity目录下的 pseudocode/primitives.ts 与 pseudocode/composition.ts 展示了如何在这套 Tag 代数之上搭建真实可用的响应式抽象——它们是生产代码的简化示意但完整保留了代数约束目录入口 index.md 对此有明确说明。PrimitiveCell一份根状态存储内部持有一个MutableTagwrite()先tag.update()再写值保证值变更 修订推进的原子对应关系。Snapshot在某个修订点捕获值 Tag二元组作为后续有效性判断的基准。PrimitiveCache带缓存的公式计算。read()时若缓存修订仍 其 Tag 修订则直接消费 Tag 并返回缓存值否则begin()→ 执行计算 →commit()得到组合 Tag → 缓存值 组合 Tag 当前修订。这正是文档中公式formula的修订是其上次计算所用成员的最新修订的落地。composition.ts中的tracked装饰器实现读取属性时tag.consume()写入时tag.update()——从源码可见tracked的本质就是一个MutableTag 一对 getter/setter完全建立在本篇文章的代数原语之上。这也呼应了姊妹文档 laws.md 中定义的六大响应式定律依赖跟踪、值一致性、事务一致性、快照不可变、定义粒度、等价性约定——所有抽象都必须满足这些定律才能保证组合后的系统可靠。想深入理解抽象如何满足定律、以及渲染与自动跟踪的联动可以继续阅读 reactive-abstractions.md、system-phases.md 与 autotracked-rendering.md。总结Tag 组合体系为 Glimmer 提供了三层清晰的能力时间线给出全局单调的失效度量初始1、常量0、易变NaN三种特殊修订Tag 家族Value / Mutable / Combined提供单点与聚合的失效表达组合 Tag 通过 join取最大值保证任一依赖失效则整体失效跟踪帧与跟踪栈把运行时的一次次consume收集为组合 Tag并跨函数边界向上冒泡。验证路径valueForTag/validateTag全程只比较修订数字不重算值、不做相等比较——这正是 Glimmer 响应式系统在可预测性与性能上独树一帜的根源也是tracked、createCache等日常 API 得以成立的地基。【免费下载链接】ember.jsEmber.js - A JavaScript framework for creating ambitious web applications项目地址: https://gitcode.com/gh_mirrors/em/ember.js创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
