连续性契约

一旦一个框架选择了 subtree replacement，它就必须回答一个非常实际的问题：

子树被替换之后，哪些交互态应该被保留？

Ansiq 对这个问题的当前答案，就是 continuity contract。

当前已经覆盖的状态

目前 continuity contract 已经覆盖：

• focus
• input cursor
• list selection
• table selection
• tabs selection
• scroll positions

这不是“顺手优化”，而是 subtree replacement 能否成立的关键条件。

continuity key 的作用

当结构发生变化，但你希望某个交互节点仍然被认为是“同一个对象”时，就需要 continuity key。

它的作用很像稳定身份标识：

• rerender 了，但还是同一个逻辑节点
• 兄弟节点顺序变了，状态仍然保住
• subtree replacement 不会把交互态直接清掉

为什么不能只靠位置

如果只靠位置，很多情况会出错：

• 列表插入/重排
• pane 结构调整
• 条件渲染切换

这时“第 2 个子节点”并不等于“原来的那个控件”。

这和虚拟 DOM 的 key 是一样的吗

有相似之处，但不完全一样。

Ansiq 当前的 continuity key 更直接服务于：

• subtree replacement
• focus continuity
• widget runtime state continuity

它是 runtime 稳定性的一部分，而不只是 diff 算法的输入。

为什么这件事应该是 runtime 契约

因为 continuity 不是某个 widget 的局部小技巧，而是：

• 输入
• focus
• 选择态
• 滚动态

这些交互行为跨 rerender 的统一规则。

如果每个 widget 各玩各的，runtime 很快就会失去一致性。

下一步

继续阅读：

1. 子树替换
2. 局部重排与 damage model
3. 终端 session 与 viewport