Ignoring RTKQ errors from unmounting components

[nickbabcock]

When the user causes a component with a query in motion to unmount, a somewhat generic ConditionError is raised which if someone is trying to handle errors at the macro level will show a toast telling the user about the aborted request.

I workaround this by attempting to detect this error and swallow it as users don't care about these requests after they've navigated to the next page.

The below code is what I use

import {
  MiddlewareAPI,
  isRejectedWithValue,
  isRejected,
  Middleware,
} from "@reduxjs/toolkit";
import { newError } from "../features/toasts/toastSlice";
import { myApi } from "../services/myApi";
export const rtkQueryErrorLogger: Middleware =
  (api: MiddlewareAPI) => (next) => (action) => {
    if (isRejectedWithValue(action)) {
      api.dispatch(newError(action.payload.data.msg));
    } else if (
      isRejected(action) &&
      (action.type || "").startsWith(`${myApi.reducerPath}/`) &&
      action.error?.name !== "ConditionError"
    ) {
      api.dispatch(newError(action.error.message));
    }

    return next(action);
  };

Let me know if I've missed something and accidentally implemented something I didn't need to.

[phryneas]

That is why the example only shows that for isRejectedWithValue. All other rejections are either internal messaging (in this case you can use action.meta.condition to detect it better by the way) or truly a crash somewhere, at a level that should already show up during development, not during normal user runtime.

[nickbabcock]

Thanks for the suggestion. I needed to leverage isRejected to show the user when requests failed due to the server being down or fetch failing (which do not reject with a value, afaik). If you have a better philosophy or workaround, let me know.

[phryneas]

Honestly, that seems like it would better be a PR against fetchBaseQuery so that it also gracefully handles "Failed to fetch" :)