Type safety in RTK query endpoints

I am trying to decouple the data access layer from the rest of my app (sort of a clean code good practice).

For that I implemented the following baseQuery:

export interface DataResponseError {
    data?: never;
    error: 'string';
}

export interface DataResponseSuccess<T> extends DataResponseCommon {
    data: T;
    error?: never;
}

export type DataResponse<T = any> = DataResponseError | DataResponseSuccess<T>;

type DataAccessMethod = (payload?: any) => Promise<DataResponse<any>>;

const queryService: BaseQueryFn<DataAccessMethod, unknown, unknown> = async (dataAccessMethod, api) => {
    const { error, data } = await dataAccessMethod();

    if (error) {
        return { error };
    }

    return { data };
};

Then I will define an service interface, for example:

export interface ExampleService {
    getNumber: () => Promise<DataResponse<number>>;
}

And then implement that interface:

export const exampleService: ExampleService = {
    getNumber: async () => {
        const response = await axios.get<number>("/number");

        return response;
    },
};

Finally create the hooks using the RTK utility:

export const extendedApiSlice = serviceSlice.injectEndpoints({
    endpoints: (builder) => ({
        getNumber: builder.query<number, void>({
                query: () => exampleService.getNumber,
            }),
    }),
});

In this case everything works as expected. But what would happen if I change the return value of the getNumber endpoint from RTK, say:

export const extendedApiSlice = serviceSlice.injectEndpoints({
    endpoints: (builder) => ({
        getNumber: builder.query<**string**, void>({
                query: () => exampleService.getNumber,
            }),
    }),
});

Typescript doesn’t alert me that exampleService.getNumber returns a number and that that is incompatible with what the RTK endpoint definition (<string, void>) expects.

I am a little bit lost on what class|type|module in RTK should I overwrite to achieve this kind of type safety.

Thanks in advance!

[phryneas]

As for the toast, just using the listenerMiddleware to listen for the rejected action might be the better choice.

[markerikson]

Closing as I think this has been reasonably answered.