Sonner项目中Promise与Server Actions的错误处理实践

背景介绍

在Next.js应用开发中，Sonner作为一款轻量级的通知组件，常被用于展示异步操作的状态反馈。当与Server Actions结合使用时，开发者经常遇到如何在Promise中优雅处理服务端错误的问题。

核心问题分析

传统方式中，开发者习惯在Server Action中直接抛出Error对象，这种方式虽然简单，但存在两个明显缺陷：

1. 错误会被打印到控制台，造成不必要的干扰
2. 在生产环境中，Next.js会屏蔽错误详情，只显示通用错误信息

解决方案演进

初始方案：直接抛出错误

// Server Action
if (user?.email === values.email) {
    throw new Error("不能删除自己的账户");
}

这种方法虽然能触发toast的错误状态，但会将错误堆栈打印到控制台，影响调试体验。

改进方案：状态对象返回

// Server Action
if (user?.email === values.email) {
    return { success: false, data: "不能删除自己的账户" };
}

// 客户端处理
toast.promise(
    deleteUser({ email }),
    {
        loading: "删除中...",
        success: ({ data }) => data,
        error: ({ message }) => message
    }
)

这种方式避免了控制台污染，但需要手动处理Promise状态转换。

最佳实践：封装Promise转换器

// 工具函数
export async function wrapPromise<T>(promise: Promise<{ success: boolean; data: T }>): Promise<T> {
    const { success, data } = await promise;
    return success ? data : Promise.reject(data);
}

// 使用方式
toast.promise(
    wrapPromise(deleteUser({ email })),
    {
        loading: "删除中...",
        success: (data) => data,
        error: (err) => err
    }
)

这种方案实现了：

1. 清晰的类型定义
2. 自动的状态转换
3. 完整的错误信息传递
4. 无副作用的控制台输出

技术原理剖析

Server Actions在Next.js中实质上是特殊的API端点。当直接抛出Error时：

1. 开发环境：能获取完整错误信息
2. 生产环境：Next.js会屏蔽敏感信息，返回通用错误

通过返回结构化对象并手动转换Promise状态，我们绕过了这个限制，同时保持了类型安全和代码整洁。

实际应用建议

1. 统一错误格式：所有Server Action应保持一致的返回结构
2. 类型安全：使用泛型确保数据类型一致
3. 错误边界：考虑添加全局错误处理器
4. i18n支持：错误消息应考虑多语言场景

总结

在Sonner与Server Actions的集成中，通过封装Promise转换器，我们实现了：

• 生产环境友好的错误处理
• 干净的控制台输出
• 类型安全的代码结构
• 良好的开发者体验

这种模式虽然需要少量样板代码，但为大型应用提供了更可靠的通知处理机制。