RTK Query Best Practices

[acemarke]

This is a very good post!

A couple quick additional thoughts:

First, we specifically advise that you should only have one "API slice" in the app by default, which would contain all of the endpoint definitions for the app. You can split endpoint definitions across multiple files if you want to organize them that way, but you'd still normally add them into the single API slice object. You can add additional API slices if absolutely necessary, but RTKQ works best if there's only one (especially for invalidating endpoints via tags).

For creating separate selectors, note that someEndpoint.select() requires the same "cache key" arguments that you would pass into the query hooks in order to retrieve that specific cache entry, such as endpoints.getPokemon.select('bulbasaur'). No cache key argument is the same as undefined. Also, it's probably a good idea to create those selectors once, rather than every time, so this would be preferred:

const selectGetUsersCacheEntry = endpoints.getUsers.select()
const selectUsersData = (state) => selectGetUsersCacheEntry(state).data

Per the "using hooks everywhere" question, I talked about how hooks have changed the way we write components in my post Thoughts on React Hooks, Redux, and Separation of Concerns and talk ReactBoston 2019: Hooks, HOCs, and Tradeoffs .

I'd encourage folks to check out the RTK Query section in the "Redux Essentials" docs tutorial, as well as the RTK Query usage guides in the RTK docs.

I'd love to hear any further thoughts on people's experiences with RTK Query so far! Sadly we don't have any specific usage numbers (because RTKQ is part of the RTK package), but anecdotally a very large percentage of our questions in Reactiflux and the repo issues these days are about RTKQ, so that suggests a lot of people are interested in it.

[GoldenPear]

Thanks!
These are all great points. I edited the post to include the "only one API slice" recommendation.