RTK Query typing .select function

[joel-stewart]

Hey everyone,

Have recently started using RTK Query and am loving it. I had a question that I have been unable to solve myself and have been unable to find an answer for in the docs or in the forums.

I am wondering if there is an exportable type from the library for the expected return response of the .select function.

With a relatively simple setup like this:

type OrdersResponse = {
  id: 'string'
}

export const getBaseQuery: BaseQueryFn<{
  url: string
  method: AxiosRequestConfig['method']
  data?: AxiosRequestConfig['data']
}, unknown, FetchBaseQueryError> =
  async (args, api) => {
    const {
      url,
      method
    } = args
    const store = api.getState() as ConsumerAppStore // Custom App store typing
    try {
      const result = await createPortalApi(store)[method](url) // Custom Axios instance that handles request auth
      return { data: result }
    } catch (e) {
      const error = e as AxiosError
      return {
        error: { status: error.response?.status, data: error.response?.data }
      }
    }
  }

export const ordersService = createApi({
  baseQuery: getBaseQuery,
  endpoints: (build) => ({
    getOrders: build.query<OrdersResponse[], void>({
      query: () => {
        return {
          url: '/orders',
          method: 'get'
        }
      }
    })
  })
})

How would you go about typing the following?

export const ordersSelector: <HOW TO TYPE THIS> = state => ordersService.endpoints.getOrders.select()(state)

Or is it best to simply allow the typing to be inferred? I would like to type this to make it clear at a glance what is expected to be returned by this selector method.

My understanding is that the typing should look something like the following:

type SelectReturnType = (state) => {
  status: QueryStatus
  originalArgs?: string | void
  data?: OrdersResponse
  error?: FetchBaseQueryError | SerializedError
  requesId?: undefined
  endpointName?: string
  startedTimeStamp?: number
  fulfilledTimeStamp?: number
}

Thank you very much everyone, I hope to contribute to the library at some point if this is encouraged by the maintainers :)

[markerikson]

As a general observation, TS works best when you infer as much as possible, and that's also true for working with RTK.

Note that the use of ordersSelector there is a bit off, because endpoint.select() actually creates a new selector instance every time. Also, if you have any query args involved here, those need to be passed in as endpoint.select(sameQueryArgsHere) so that it knows which cache entry to retrieve.

I'm pretty sure that if you just do const ordersSelector = ordersService.endpoints.getOrders.select(), this should be typed correctly already.

And sure, contributions are always welcome! :)

[phryneas]

Yes, generally, RTK is written for types to be inferred. There is so much type info going in there (endpoint definition, error type of your base query) and it is also not a normal interface, but also a discriminated union that you should not really cannot hand-type that and it would also not be easier if we would explicitly export types for that.

[joel-stewart]

Thanks guys, inferred typing here makes sense.

@markerikson, regarding your comment about the incorrect usage of endpoint.select,- there was one thing I was unsure about after re-reading the docs. In my example above, my query is not based on any kind of parameter that I could use as a cache memorisation key so I am unsure as to how I would go about modifying the above to ensure that a new selector is not returned every time.

Apologies if I am missing something obvious here or misunderstanding usage, I would be extremely grateful if you could provide an example of what would need to change in this scenario to address the issue 🙏

[phryneas]

Don't do

export const ordersSelector: <HOW TO TYPE THIS> = state => ordersService.endpoints.getOrders.select()(state)

but just

export const ordersSelector = ordersService.endpoints.getOrders.select()

[joel-stewart]

Oh I see, I had mis understood your previous comment. This makes perfect sense. Thanks again!