NgRx SignalStore 中 Object.freeze 保护机制的演进与思考

背景介绍

NgRx 作为 Angular 生态中重要的状态管理解决方案，在最新版本中引入了基于 Signal 的 SignalStore。在 v19 版本中，开发团队为 SignalStore 添加了一个重要的保护机制：递归应用 Object.freeze 方法来防止状态对象的意外变更。

保护机制的初衷

Object.freeze 的设计初衷是为了帮助开发者遵循不可变数据的原则。在状态管理中，不可变性是一个核心概念，它能带来以下优势：

• 确保状态变更的可预测性
• 简化变更检测逻辑
• 便于实现时间旅行调试
• 避免意外的副作用

现实中的挑战

然而，这一机制在实际应用中却遇到了意想不到的问题：

1. 开发者习惯冲突：许多开发者已经习惯了直接修改状态的方式，这种突变式编程模式在 JavaScript 社区中相当普遍。

2. 类型兼容性问题：某些特殊的数据结构无法被 Object.freeze 正确处理，导致运行时错误。

3. 灵活性限制：在某些特殊场景下，开发者确实需要直接修改状态来实现特定功能，严格的保护机制反而成为了障碍。

技术决策的转变

经过社区反馈和内部讨论，NgRx 团队做出了一个重要决定：在 19.0.1 版本中移除了 Object.freeze 保护机制。这一决策基于以下考虑：

1. 与 Angular Signal 的一致性：底层的 Signal 类型本身并不强制不可变性，SignalStore 的行为应当与之保持一致。

2. 开发者体验优先：当保护机制带来的困扰大于收益时，应当尊重开发者的实际需求。

3. 渐进式最佳实践：相比强制约束，更倾向于通过文档和教育引导开发者采用不可变模式。

对开发者的影响

这一变更意味着：

• 开发者现在可以自由选择是否保持不可变性
• 需要自行确保状态变更的可预测性
• 团队内部需要建立相应的代码规范

替代方案建议

虽然移除了强制保护，但仍推荐以下做法：

1. 使用扩展运算符：{...oldState, prop: newValue}
2. 采用不可变库：如 immer 等
3. 类型系统约束：通过 TypeScript 类型定义来提示不可变性
4. 代码审查：在团队中建立不可变操作的代码审查机制

总结

NgRx SignalStore 的这一演进展示了技术决策中平衡理想与实践的重要性。它提醒我们，优秀的技术方案不仅要有理论上的优势，更要考虑实际开发场景中的适用性。对于开发者而言，理解这一变更背后的思考，将有助于更好地运用 SignalStore 构建健壮的 Angular 应用。