RTK Query查询失败时显示通知的最佳实践：哪种方案更可取？

问题 #

在RTK Query调用API出错时需要显示Toast通知，目前有两种实现方式：

方式一：包装查询函数 #

const loadFooWithToast = async () => {
    const { error } = await loadFooQuery()
    if (error) showErrorToast("Error loading Foo")
}

注：可以封装成接收查询函数和错误信息的通用自定义Hook，逻辑保持一致。

方式二：使用Listener Middleware #

startAppListening({
    predicate: (action) => {
        return action.type === "api/executeQuery/rejected"
    },
    effect: ({
        meta: {
            originalArgs: { errorMessage }
        },
    }) => {
        showErrorToast(errorMessage)
    },
})

loadFooQuery({ errorMessage: "Error loading Foo" })

请问这两种方法哪种更可取，原因是什么？

回答 #

这两种方案各有适用场景，具体选择得看项目需求：

优先选Listener Middleware的情况 #

• 全局统一处理：如果项目里大部分API错误都要显示Toast，这种方式能一次性搞定全局逻辑，不用在每个调用点重复写错误判断，减少冗余代码。
• 解耦业务与通知逻辑：错误通知属于UI交互逻辑，和数据请求的业务逻辑分开，后续要改Toast样式或规则时，只需要调整Listener，不用动每个查询调用的地方。
• 自动捕获所有查询错误：只要是api/executeQuery/rejected类型的action都会被监听到，不管哪里发起的查询，不用手动包装每个查询函数。

优先选包装查询函数的情况 #

• 局部特殊处理：只有少数API需要显示Toast，或者不同API的错误通知逻辑不一样（比如自定义文案、额外操作），这种方式更灵活，能针对单个查询定制逻辑。
• 简单场景快速落地：项目规模小、API数量少的话，直接包装函数的写法更直观，上手快，不用额外配置Listener Middleware。
• 错误时需执行额外业务操作：如果除了Toast，还要在错误时做特定业务逻辑（比如重置表单、更新本地状态），包装函数能把这些逻辑放在一起，代码更集中，可读性更强。

总结 #

中大型项目需要全局统一处理API错误通知的话，Listener Middleware是更优选择，能提升代码可维护性，减少重复；小型项目或需要局部定制错误逻辑时，包装查询函数更简单直接。

内容的提问来源于stack exchange，提问作者user1032752