Type casting error response per endpoint

[KhubaibQaiser]

Hi, is there a way to specify error response per endpoint? Like we can specify Result & Request type when defining a query or mutation. I did went through the documentation and updated the base query. I am getting the generic success/error response types but still trying to figure out how to define error type per endpoint.

[phryneas]

No, not at the moment.

The general problem is that an "error" can always - no matter how much you type there - can always be pretty much anything.
There are lots of "expected" edge cases that can always happen such as connection loss of a 503 on the server.
Then there are also lots of edge cases that can never be expected - for example just an exception thrown in your transformResponse (or, in this case probably a transformError) callback.

So, we have

• expected error from the server
• expected errors from the baseQuery (parsing errors, connection loss etc)
• unexpected errors (throw)

So it's kinda the same case as you have with a catch block in TypeScript that is always just any or unknown, but never something specific.

We currently model that as "the known error type from the baseQuery" or "SerializedError for unexpected (thrown) errors".

I don't know how expected errors from the server could just be modeled into that successfully.

[KhubaibQaiser]

But we can still handle all those errors in the custom base query function and return a response (either success, or error) that follows a specific interface?
For example, if we consider following code:
Custom Base Query:

  { baseUrl }: { baseUrl?: string } = {
    baseUrl: process.env.NEXT_PUBLIC_BASE_URL,
  }
): BaseQueryFn<
  {
    url: string;
    method: ApisauceConfig["method"];
    data?: ApisauceConfig["data"];
    routeParams?: Record<string, string>;
    queryParams?: ApisauceConfig["params"];
    forceTokenRefresh?: boolean;
    dropTokenFromHeader?: boolean;
  },
  unknown,
  iApiErrorResponse<E>
> => {
  // Use closure to avoid re-fetching from localstorage for every request
  let token = getUserToken();

  return async ({
    url,
    method,
    data,
    routeParams,
    queryParams,
    forceTokenRefresh,
    dropTokenFromHeader,
  }) => {
    if (forceTokenRefresh) {
      token = getUserToken();
    }

    if (!dropTokenFromHeader && Boolean(token)) {
      apiSauce.setHeader("Authorization", `Bearer ${token}`);
    }

    try {
      const result = await apiSauce.any<any, E>({
        baseURL: baseUrl,
        url: compile(url || "", { encode: encodeURIComponent })(routeParams),
        params: queryParams,
        paramsSerializer: (params) =>
          qs.stringify(clean(params), { arrayFormat: "repeat" }),
        method,
        data,
      });

      if (result.ok) {
        return { data: result.data };
      } else {
        return {
          error: {
            status: result.status,
            data: result.data as E,
          },
        };
      }
    } catch (err) {
      return {
        error: {
          status: 400,
          data: err,
        },
      };
    }
  };
};

API:

const SomeApi = createApi({
 baseQuery: apiSauceBaseQuery<string>(),
 reducerPath: "some_reducer_path",
 endpoints: (builder) => ({
   getData: builder.mutation<
     iGetDataResponse,
     iGetDataRequest
   >({
     query: (data) => ({
       method: "GET",
       url: "/some/endpoint",
       queryParams: data,
     }),
   }),
})
});

Slice:

...
extraReducers: (builder) => {
builder.addMatcher(
      SomeApi.endpoints.getData.matchRejected,
      (state, { payload }) => {
      // We should be able to type case the error `payload` here
}
);

So, talking about the error case specifically, can't we still parse the error response to follow the generic type of the custom base query (which in this case is iApiErrorResponse), but still can control the exact type of data to expect by passing the specific type to iApiErrorResponse<T> by maybe doing something like:

endpoints: (builder) => ({
    getData: builder.mutation<
      iGetDataResponse,
      iGetDataRequest,
      iEndpointSpecificErrorType
    >({
      query: (data) => ({
        method: "GET",
        url: "/some/endpoint",
        queryParams: data,
      }),
    }),
})

and then expect iApiErrorResponse<iEndpointSpecificErrorType> as the error type in the extra reducer matcher?

[phryneas]

That suggestion is unfortunately technically not possible since we cannot instantiate iApiErrorResponse with a different generic at any point from our code (TypeScript cannot do that).

Also, in that extra reducer matcher, payload will always be possibly undefined in the case an actual bug occurs (a throw anywhere in query, baseQuery, providesTags etc.). In that case, action.error will be a SerializedError of what was thrown there instead.

Honestly, in my eyes the most sane thing would be to write a type guard function and apply that in your reducer case once. Errors can just be too many things.

And reducer matchers are only the easy case because there you can distinguish between action.error and action.payload - but in hooks, everything is just error. You pretty fast get to the point where really only a Type Guard starts to make sense.

[KhubaibQaiser]

thanks a lot for the detailed reply.