Stunk 状态管理库中 set 与 update 函数的优化思考

Stunk 状态管理库中 set 与 update 函数的优化思考

stunk Stunk is a framework-agnostic state management library that keeps your app’s state clean and simple. It uses a fine-grained state model, breaking state into independent, manageable chunks. 项目地址: https://gitcode.com/gh_mirrors/st/stunk

在状态管理库 Stunk 的开发过程中，我们发现 set 和 update 这两个核心函数存在功能重叠的问题。本文将从设计模式的角度分析这两个函数的异同，探讨合并它们的可行性，并提出一个更优雅的解决方案。

当前实现分析

目前 Stunk 中存在两个独立的状态更新函数：

1. set 函数：接受一个新值直接替换当前状态
2. update 函数：接受一个更新函数，基于当前状态计算新状态

从代码实现来看，这两个函数的核心逻辑几乎相同：

• 都经过中间件处理
• 都进行值变更检查
• 都会在值变化时通知订阅者

唯一的区别在于参数类型和初始值的获取方式。这种设计虽然直观，但带来了API冗余和维护成本。

问题本质

这种设计违反了DRY(Don't Repeat Yourself)原则。两个函数90%的代码是重复的，唯一的区别在于：

• set 直接接受值
• update 接受一个函数来派生值

这种微小的差异不足以证明需要两个独立函数的合理性，反而增加了使用者的认知负担和库的维护成本。

优化方案

我们可以采用函数重载的模式，将两者合并为一个更通用的 set 函数：

function set(newValue: T): void;
function set(updater: (currentValue: T) => T): void;
function set(newValueOrUpdater: T | ((currentValue: T) => T)): void {
  const newValue = typeof newValueOrUpdater === 'function' 
    ? newValueOrUpdater(value) 
    : newValueOrUpdater;
  
  const processedValue = processMiddleware(newValue, middleware);
  
  if (processedValue !== value) {
    value = processedValue as T & {};
    notifySubscribers();
  }
}

优势分析

1. API简化：使用者只需记住一个方法名
2. 类型安全：TypeScript 的类型推断能自动识别参数类型
3. 维护性提升：消除了重复代码
4. 一致性：与 React 的 useState 等流行API设计保持一致

实现考虑

在合并实现时需要注意：

1. 类型守卫：需要可靠地区分函数和值类型
2. 错误处理：当传入无效参数时提供清晰的错误信息
3. 性能：额外的类型检查对性能影响可以忽略不计
4. 向后兼容：可以通过弃用警告逐步迁移现有代码

最佳实践建议

对于状态管理库的设计，我们建议：

1. 保持核心API最小化
2. 通过参数多态而非函数重载来实现类似功能
3. 提供清晰的类型提示和文档
4. 遵循行业惯例降低学习成本

这种优化不仅适用于Stunk，对于其他状态管理库的设计也有参考价值。通过精简API表面，我们可以打造更易用、更易维护的状态管理解决方案。

stunk Stunk is a framework-agnostic state management library that keeps your app’s state clean and simple. It uses a fine-grained state model, breaking state into independent, manageable chunks. 项目地址: https://gitcode.com/gh_mirrors/st/stunk