How to put RTK query into store/slice?

Question

I just started using RTK query, but facing a problem

My app has all the setting in one big JSON, so I create an RTK query to fetch the setting. In the tutorial, the examples are about using the useQuery hook in the component and immediately display the result, but because the setting is so big that it has multiple pages/components to display it and allow the user to change the setting

Because the setting needs to be changed, so I think it's a good idea to put the state in the store, my question is how can I put the API result into the store?

I can see a couple of methods around it

1. Use useQuery in a component and when it has resulted, then do a dispatch to put the data onto the store

2. put useQuery from API in all components use it and use it to get cached data, then there is no need to put it on the store and use the component state for setting changes (I'm not sure about this approach as there are a lots of settings - even divided across different pages, it doesn't seems right use component state to manage it)

I'm new to RTK and RTK query, just wondering what's the best/good approach?

Ideo

Answer 1

Using RTK Query implicitly means "putting your data in the store". It creates a store slice that manages all your data for you. You can just use useQuery wherever you need that data and you either get it out of the store or request it new when necessary.

Most of the time you should not copy that data elsewhere as you will have to do stuff like manual cleanup etc. then.

I can also recommend going through the tutorial chapters for RTK-Q that were just added to the official Redux tutorial. They are very in-depth.

https://redux.js.org/tutorials/essentials/part-7-rtk-query-basics

Teston

thanks for the tutorial link, I was looking at the RTK Query doc and didn't look at the Redux doc, so I should use useQuery wherever needed and use useState hook to provide edit? – Ideo

I'm not 100% sure what you mean with the "to provide edit", but if this is about component-local input fields, yes, those would usually stay in local state. – Teston

Yes, that's what I mean, to provide settings and using local state seems to be the way to go then. Thanks! – Ideo

@Teston I'm completely new to rtk and rtk-query as well so I thought asking my question here would be appropriate. I'm getting a board that contains lists and every list may also contain multiple cards. So, theoretically, there exists 3-4 level nesting. By using query and getting all the data I want and rendering all my data (passing it down via props etc...) What happens if I attach a mutation to a single card (utmost nested entity) and update that card ? How would you structure this scenario Phry ? – Trusty

If you have control over the API, don't make one endpoint that returns everything, but more fine-grained endpoints. If that's not possible, there's probably no helping to retrieve that data back from the server on ever leaf change, assuming you don't want to manually manage it. – Teston

@Teston I can either pull everything from one endpoint or create composite state by visiting multiple endpoints. But lists and cards are relational and I'll be updating them frequently. If I use fine-grained approach then wouldn't I be forced to 'compose' them by visiting multiple endpoints since they are relational ? – Trusty

Well, if you only update one part you would only need to refresh that one part from the server, opposed to "always having to fetch everything", so a finer-grained approach where you always pass ids into the components and use the respective useQuery(id) hook in the components that need the data seems preferrable. But in the end you'll have to try it out. – Teston

What about if we have multiple fetches like we display github repos and the starts count. So we fetch for each repo with rtk query. Now, how do we sort the repos by stars count? – Valorize

Answer 2

From the docs:

However, when you use RTK Query, there is a mindset shift that happens. We're no longer thinking about "managing state" per se. Instead, we now think about "managing cached data". Rather than trying to write reducers ourselves, we're now going to focus on defining "where is this data coming from?", "how should this update be sent?", "when should this cached data be re-fetched?", and "how should the cached data be updated?". How that data gets fetched, stored, and retrieved becomes implementation details we no longer have to worry about.

Fredericton

Answer 3

import { configureStore } from "@reduxjs/toolkit";

import { TodosApi } from "./todosReducer";

import { PostApi } from "./postReducer";

export const store = configureStore({

  reducer: {

 [TodosApi.reducerPath]: TodosApi.reducer,

 [PostApi.reducerPath]: PostApi.reducer,

  },

  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware()
    
    .concat(TodosApi.middleware)

    .concat(PostApi.middleware)

}

)

Blane

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Stakeout