Pattern for loading indicator when a mutation triggers a refresh query

[fuzl-llc]

I'm using react/redux with RTK Query. I have a component A that runs an API query that returns a list of objects and creates a list of component B instances inside it, one component B for each returned object. Component B can trigger an API mutation that will update its object's data on the server (since that object is "owned" by the API query, and I don't know that I can just manually update that data client-side). To see the change reflected in the UI, I'm re-running the original API query to return all objects (which will have the mutated state for that one object) and refresh the UI.

Normally when I store data in redux state I can just update it but in the case of returned data from an API call, I'm not sure I can (or want to) which is why my first attempt has just been to re-request the data from the original query. Is this normal practice?

It also leads to a "loading indicator" UI issue where I show a loading spinner while the mutation API call is happening, but then there is a separate delay while the triggered refresh query is happening. To solve that I changed the loading spinner from showing just when the mutation was pending to a new "componentAQueryIsLoading" value in redux state (which I set to true using an onQueryStarted function on the mutation query and then back to false in an onQueryStarted function after waiting for queryFulfilled to complete on the refresh query). It works well but it seems a bit weird and perhaps overcomplicated.

I'm new to this and trying to absorb Typescript, React, Redux, and RTK query all at once so I'm just wondering if what I'm doing makes any sense or if there is a simpler best practice for this type of situation. Thanks for any thoughts or feedback you may have.

[markerikson]

Yeah, the basic approach is indeed: run a "mutation" to update data on the server, have that "invalidate" a query endpoint, and the query will automatically refetch the data to keep the client in sync with the server.

If you want to have the data component be a bit smarter about when it shows a loading spinner, you can change the logic to check the isFetching and currentData fields to continue showing existing data in the UI and just replace it with the new data once it comes back. You shouldn't need to track separate flags yourself for that.

You can also do "optimistic updates" to modify the client cache as the mutation completes if it happens to include the values you need already, and then the refetch can update things silently in the background.

I'd recommend reading through the full "Essentials" tutorial in our main docs to get an idea of the things you can do with RTK Query:

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

and see these RTK Query usage guide sections as well:

• https://redux-toolkit.js.org/rtk-query/usage/queries
• https://redux-toolkit.js.org/rtk-query/usage/automated-refetching
• https://redux-toolkit.js.org/rtk-query/usage/manual-cache-updates

[fuzl-llc]

Thank you so much! It sounds like the currentData thing is what I was missing (I was just using isFetching before). I think I actually read all that but I did it all up front to get an overview before diving into coding. I definitely need to go back and re-read now that I've been hands on with it for a while. I'll try the optimistic updates too - sounds like that is the way to edit that local cached data and if that immediately updates the UI it will cut the loading spinner display time in half which is great. Thanks again. This stuff is amazing. I feel like I tried and failed at coming up with a really proper state management solution for many years and so far this is covering everything I've wanted and more. Thanks for creating and sharing this great project!

[markerikson]

Sure, glad this is working out well for you!