深入剖析NanoStores中嵌套deepMap的旧值监听问题

在状态管理库NanoStores的开发过程中，我们发现了一个关于嵌套deepMap监听时旧值传递不准确的技术问题。这个问题涉及到状态管理的核心机制，值得开发者深入理解。

问题背景

当使用NanoStores的deepMap功能创建嵌套状态结构时，如果对状态变化进行监听(onNotify)，在某些情况下会收到不正确的旧值(oldValue)。特别是在多级嵌套结构中，这个问题表现得尤为明显。

问题复现

考虑以下测试用例：

type DeepValue = { a: number; b: { nested: { deep: number } } }

let $store = deepMap<DeepValue>({
  a: 0,
  b: {
    nested: {
      deep: 0
    }
  }
})

onNotify($store, ({ oldValue }) => {
  // 这里收到的oldValue可能不正确
})

当连续修改不同层级的属性时，监听器收到的旧值可能不是预期的完整状态快照。

技术分析

这个问题本质上源于JavaScript的对象引用机制。在状态变更时，如果不进行深度克隆，直接传递旧值会导致引用共享，后续的修改会影响之前保存的"旧值"。

NanoStores的设计哲学与Redux不同，它不强制要求不可变状态，而是允许直接修改状态。这种灵活性带来了性能优势，但在监听旧值时需要特别注意。

解决方案

经过讨论，团队决定在核心的onNotify钩子中使用structuredClone来确保传递正确的旧值。这种方案有几个关键考虑：

1. 性能考量：虽然克隆操作有一定开销，但现代浏览器的structuredClone实现已经足够高效
2. 兼容性：需要明确文档说明对structuredClone的支持要求
3. 数据类型限制：由于structuredClone只能克隆可序列化数据，使用onNotify时需要确保状态中不包含不可序列化的对象

实现细节

最终的修复方案包含以下关键点：

• 仅在onNotify内部使用structuredClone，不影响核心状态更新性能
• 添加适当的错误处理，防止不可克隆数据导致崩溃
• 在文档中明确说明相关限制

总结

这个问题展示了状态管理中引用与值传递的微妙之处。NanoStores通过针对性的克隆策略，在保持性能的同时解决了旧值准确性问题。开发者在使用嵌套状态时应当注意这些细节，特别是在需要访问旧值的场景下。

理解这一机制有助于开发者更好地利用NanoStores进行复杂状态管理，同时避免潜在的陷阱。