能否仅使用RTK Query而无需Redux Toolkit切片、动作？性能及场景疑问

1. 性能差异与是否无需手写切片/Reducer #

• 性能几乎无差异：RTK Query本身就是基于Redux Toolkit核心API（如createSlice、createAsyncThunk）构建的，底层逻辑和你手动写RTK代码一致。而且它内置了请求去重、缓存复用、自动过期等优化，在数据请求场景下反而可能比手动实现更高效。
• 可完全无需手写切片/Reducer：RTK Query会自动生成对应的切片、Reducer和动作创建函数。你只需要定义API接口（endpoints），它就会处理数据缓存、请求状态（加载/成功/失败）、数据同步这些工作。但如果是纯本地状态（比如UI弹窗开关、临时表单草稿），还是得手动写切片管理。

2. 认证场景的实现选择 #

• 不是必须依赖Reducer，但要分场景处理：
  • 登录、刷新token这类和后端交互的认证流程，用RTK Query的mutation来实现很合适，请求成功后可以把用户信息、token存到手动创建的切片里；
  • 后续接口请求需要携带token的话，可通过RTK Query的baseQuery统一配置拦截器，自动在请求头里加token，不用每个请求单独处理；
  • 如果你的认证完全依赖后端cookie，前端只需要根据请求返回状态判断登录状态，那也可以不用切片，但这种场景比较少见，大部分还是需要本地存储用户状态。

3. 表格行本地编辑的实现 #

• 可以用RTK Query实现，但要结合它的缓存更新能力：
  • 如果编辑后直接提交后端，用RTK Query的mutation即可，提交成功后它会自动更新对应缓存的表格数据；
  • 如果是先做本地临时编辑（未提交后端），可以用RTK Query提供的updateQueryData方法直接修改缓存数据，效果类似手动更新切片状态，示例代码：

    // 假设你的表格数据query名为getTableData
    dispatch(api.util.updateQueryData('getTableData', undefined, (draft) => {
      const targetRow = draft.find(item => item.id === editedRowId);
      if (targetRow) {
        Object.assign(targetRow, editedData);
      }
    }))
    

  • 注意：这种修改是临时的，后续重新发起请求会被后端数据覆盖，适合做编辑预览场景；如果需要长期保存未提交的编辑状态，还是建议用单独的切片来管理。

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