Sonner库中Promise返回结构误判HTTP请求的解决方案

问题背景

在使用Sonner这个Toast通知库时，开发者们遇到了一个有趣的类型推断问题。当使用Promise返回一个包含ok和error字段的数据结构时，Sonner会错误地将其识别为HTTP响应，从而导致Toast显示错误的提示信息。

问题复现

典型的错误场景出现在使用Result类型封装返回结果时。例如，开发者定义了一个通用的Result类型：

export type Result<T, E = Error> =
  | { ok: true; value: T }
  | { ok: false; error: E };

当使用这个类型作为Promise的返回值时：

async function example(): Promise<Result<null, Error>> {
  return { ok: false, error: new Error("Not implemented") };
}

toast.promise(example, {
  loading: "处理中...",
  success: (result) => "成功",
  error: (e) => `错误: ${e}`
});

预期应该进入success回调并处理错误情况，但实际上会进入error回调，显示"HTTP error! status: undefined"。

问题根源

经过分析，问题的根源在于Sonner库内部对响应数据的类型判断逻辑。库中预设了如果返回数据包含ok和error字段，就认为这是一个HTTP响应，从而触发了错误的处理路径。

临时解决方案

在等待官方修复期间，开发者们提出了几种临时解决方案：

1. 手动管理Toast生命周期：

const id = toast.loading("处理中...");
try {
  const result = await apiCall();
  if (result.ok) {
    toast.success("成功", { id });
  } else {
    toast.error(result.error.message, { id });
  }
} catch (e) {
  toast.error("请求失败", { id });
}

2. 在success回调中抛出错误：

toast.promise(apiCall, {
  loading: "处理中...",
  success: (result) => {
    if (result.ok) return "成功";
    throw new Error(result.error.message);
  },
  error: (e) => e.message
});

3. 自定义CSS动画（针对手动管理Toast时的动画丢失问题）：

.custom-promise-toast [data-icon] > svg {
  opacity: 0;
  transform: scale(0.8);
  animation: fade-in 300ms ease forwards;
}

官方解决方案

Sonner 2.0版本已经修复了这个问题。更新到最新beta版即可解决：

npm install sonner@2.0.0-beta.3

最佳实践建议

1. 对于复杂的异步操作结果处理，考虑使用更明确的状态标识字段，避免使用可能引起歧义的ok字段名。

2. 对于重要的业务逻辑，建议采用手动管理Toast的方式，可以获得更精细的控制。

3. 在升级到2.0正式版后，可以安全地使用Promise和Result模式组合。

总结

这个问题展示了类型推断在实际开发中可能遇到的边界情况。Sonner库的快速响应和修复也体现了开源社区的优势。开发者在使用Toast通知时，应当注意返回数据的结构设计，避免与库的预设模式冲突。对于需要精确控制通知行为的场景，手动管理Toast生命周期通常是更可靠的选择。