Using updateQueryData in injectEndpoints

[dorbaruchh]

Hello,
I have the following code to create an API using the recommended approach described in the "Code Splitting" section:

Main API:

const api = createApi({
  baseQuery: baseQueryWithReAuth,
  endpoints: () => ({}),
});

Injecting additional endpoints to main API:

export const notificationsService = api.injectEndpoints({
  endpoints: (build) => ({
    getNotifications: build.query<Notification[], void>({
      query: () => ({
        url: "get_notifications/",
        method: "POST",
      }),
      transformResponse: (response: { data: Notification[] }) => response.data || []
    }),
    markNotificationsRead: build.mutation<void, void>({
      query: () => ({
        url: "mark_notifications_read/",
        method: "POST",
      }),
      async onQueryStarted(args, { dispatch, queryFulfilled }) {
        await queryFulfilled;
        dispatch(
          api.util.updateQueryData("getNotifications", undefined, notifications => {
            return notifications.map(notification => ({...notification, "status": "read"}))
          })
        );
      }
    }),
  }),
  overrideExisting: false,
})

As you can see, inside the markNotificationsRead endpoint I have a call to updateQueryData with the endpoint name "getNotifications" which is also defined above in the same API.
Doing so, I get the following error for the endpoint parameter in the updateQueryData call: "Argument of type 'string' is not assignable to parameter of type 'never'."
I am very new to Typescript so I'm not completely sure what the issue is.
I suspect that the issue is that my original API was created without any endpoints so when calling updateQueryData we can't type check that getNotifications is really a valid endpoint name.

Assuming this is really the issue, is there any way to fix it without having to move the getNotifications definition to the main API definition?
One option I tried is to split the injected API to 2, like so:

const _notificationsService = api.injectEndpoints({
  endpoints: (build) => ({
    getNotifications: build.query<Notification[], void>({
      query: () => ({
        url: "get_notifications/",
        method: "POST",
      }),
      transformResponse: (response: { data: Notification[] }) => response.data || []
    }),
  }),
  overrideExisting: false,
})

export const notificationsService = _notificationsService.injectEndpoints({
  endpoints: (build) => ({
    markNotificationsRead: build.mutation<void, void>({
      query: () => ({
        url: "mark_notifications_read/",
        method: "POST",
      }),
      async onQueryStarted(args, { dispatch, queryFulfilled }) {
        await queryFulfilled;
        console.log("Marking notifications");
        dispatch(
          _notificationsService.util.updateQueryData("getNotifications", undefined, notifications => {
            return notifications.map(notification => ({...notification, "status": "read"}))
          })
        );
      }
    }),
  }),
  overrideExisting: false,
}

Would this be the recommended approach?

Thank you in advance for the help!

[phryneas]

Even in your original code, you should just be able to notificationsService.updateQueryData.

[phryneas]

Hmm, in a TypeScript CodeSandbox?

[DevTGhosh]

@phryneas here is the codesanbox.
Check the postApi.ts file at updateQueryData. getPost is showing Argument of type 'string' is not assignable to parameter of type 'never'.ts(2345)
I am still facing the same issue. Let me know if I need to create a Github issue for this.

[phryneas]

@DevTGhosh you are using the empty api. You need to use postsApi.util.updateQueryData("getPost"

[DevTGhosh]

Oh I didn't realize that. My thought was since we are injecting the endpoints in the main api file the dispatch actions will also make use of that as well.

Maybe we need to add it as a tip to the code splitting documentation?

Thanks a lot though!

[phryneas]

I'm pretty sure it is called emptyApi in the code splitting docs - that should be pretty telling ;)
Generally: they are injected, but we cannot modify the types after the fact, so it is safer you go off the new api.