LegendState 项目中 computed() 函数的最佳实践演进

在状态管理库 LegendState 的演进过程中，computed() 函数的使用方式经历了重要变化，开发者需要理解这些变化背后的设计理念和优化思路。

computed() 函数的历史演变

LegendState 早期版本中存在 observableComputed 和 computed 两种计算属性实现。在版本迁移过程中，observableComputed 被重命名为 computed，这是最初的标准化过程。然而，随着框架的持续优化，computed() 函数本身也面临着进一步的演进。

当前推荐模式

最新实践表明，在作为子属性使用时，直接使用普通函数比 computed() 包装更为推荐。这种模式具有以下优势：

1. 性能优化：函数模式减少了不必要的包装层，降低了内存开销
2. 简化依赖追踪：避免了嵌套可观察对象带来的复杂依赖关系
3. 代码简洁性：减少了样板代码，使逻辑更清晰

具体使用场景分析

根级使用场景

在根级别创建计算属性时，computed() 仍然有效，它会自动创建一个可观察对象。这种用法目前保持兼容，但未来可能会被更简单的模式替代。

子属性使用场景

对于作为子属性的计算逻辑，强烈建议迁移到纯函数模式。例如：

// 旧模式 (不推荐)
const store = observable({
  data: [],
  totalSlides: computed((): number => store.data.length)
})

// 新模式 (推荐)
const store = observable({
  data: [],
  get totalSlides(): number { return this.data.length }
})

设计理念解析

这种变化反映了 LegendState 对状态管理简化的追求。通过减少不必要的可观察对象嵌套，框架能够：

1. 降低内部依赖追踪的复杂度
2. 提高状态更新的效率
3. 提供更直观的开发者体验

迁移建议

对于现有项目，可以逐步将子属性中的 computed() 调用替换为函数形式。这种迁移不会影响功能，但能获得更好的性能表现。对于根级别的计算属性，可以暂时保持现状，等待框架后续的明确指导。

理解这些变化背后的设计思想，有助于开发者更好地利用 LegendState 构建高效、可维护的应用程序状态管理方案。