RTK query feature request: Initial Query Data and Updates from Mutation Responses

[DouglasDev]

Hi, I've been converting a medium size app to use RTK query and I have mixed feelings about it. 90% of the time, RTK query fits my use case well and is very pleasant to work with, but the other 10% of the time, I feel like I'm trying to fit a square peg into a round hole. My main issues:

1. No easy way to set initial query data. I need to do this in the case of loading user session data from a cookie. Once I load the data from the cookie, I use a saved token to request fresh session data from the server. RTK supports "optimistic updates", which seems like would fit this use case, but it appears that I can only do an optimistic update if I already have cached data, which is impossible in this case.

2. Related to number 1, user session data is also returned by the response to the account login and register endpoints in my api, so I need a way to add this response to the same user session state slice. It seems that a "pessimistic update" would fit this use case, but again, I cannot do the update if there is no cached data, which of course I don't have if the user isn't logged in.

Because of the above 2 issues, I needed to create another user session state slice without the use of RTK query, that is managed differently than all my other api state, entirely because the RTK query api could not accommodate my use case (which I think is fairly common).

I later ran into another similar issue. I have a page where a user can edit some data and then save it to the server. The first time they edit it, the initial data is generated client side. Then when they make the post request to save the data, the server returns the updated data in the response. The problem is nearly identical to the one above: I need a simple way to set initial query data and then update it based on the server response.

Because of the difficulty I encountered doing this, I'm considering switching to react query which has these features built in:
https://react-query.tanstack.com/guides/initial-query-data
https://react-query.tanstack.com/guides/placeholder-query-data
https://react-query.tanstack.com/guides/updates-from-mutation-responses

Unrelated, I've gotten used to using the "state" tab in the redux dev tools, where I can see the current state at a glance. However, with the rtk query dev tools, I need to click through multiple nested objects in order to get to the data field for a query, meaning that I often resort to console.logging the data rather than using the dev tools. I realize that technically rtk query saves lots of other types of state, but most of the time, I'm only interested in the data that is actually being used in my app.

Lastly, there's a part of my app where I need to make multiple parallel requests to the same endpoint. I eventually figured out how to accomplish this in RTK query, but it required writing a couple of helper functions and wasn't straight forward. So perhaps this is not a missing feature per se, but either a built in helper function or an example in the docs would help a lot with this.

I hope this post doesn't come across as too critical. I appreciate the hard work of the redux developers and overall I think rtk query is an excellent library, but the two features that I mentioned would save devs a lot of frustration. Thanks!

[markerikson]

Hiya. A couple quick thoughts:

• The "initial data" scenario may be doable via the hydration support that was added in 1.7 ( https://redux-toolkit.js.org/rtk-query/usage/persistence-and-rehydration , https://redux-toolkit.js.org/rtk-query/api/createApi#extractrehydrationinfo ), although I haven't tried doing anything like that myself. That said, just glancing at those it feels like it probably wouldn't be as simple as R-Q's option for that atm.
• I'm not sure I'm following the data flow you're describing for the user session data scenario. When you say "add this response to the same user session state slice", are you talking about an RTKQ endpoint cache entry for something like a /getUser endpoint?

There is a draft PR for an upsertQueryData util method that would potentially help here, but we haven't gotten back around to looking at it: #2007 . But, it is something that seems like a good candidate for RTK 1.9 (per #2003 ). If you get a chance, could you maybe try out the build from that PR and see if it's helpful? Feedback on the API would be useful here.

I also haven't had time to use the RTK Query DevTools monitor much, but I'd agree that it would probably be useful to focus more on the data. I just filed reduxjs/redux-devtools#1126 with that suggestion.

Finally, what aspect of the "parallel requests" did you feel was confusing and not straightforward? What did the final result look like?

[DouglasDev]

For your user auth data though: we are recommending to keep that outside of RTK Query in a normal Redux slice/httpOnly cookie or somewhere else in the first place. That would need it's own hydration with redux-persist/whichever tool would be fitting.

That is the approach I went with but for the reasons I mentioned above, I don't think it's an ideal approach.

If that initial data contains anything else I would suggest that you are probably overoptimizing - if that data fits into a <4kb cookie, it should not have any real impact on the application to just make that query again on application load.

My issue is not related to optimization or trying to avoid making a query. It's that I need to load some initial data from a cookie before I can even make the other requests or load the app at all since the data in the cookie contains the auth token and other essential data.

And you can always just use a default initiailizer if you want initial/default data, I don't really see why that would need to be an extra feature:

const { data = initialData, isLoading } = useMyQuery(arg)

That is fine except RTK query doesn't allow me to perform manual cache updates without any initial cached data, which is necessary for my use case.

[phryneas]

For your user auth data though: we are recommending to keep that outside of RTK Query in a normal Redux slice/httpOnly cookie or somewhere else in the first place. That would need it's own hydration with redux-persist/whichever tool would be fitting.

That is the approach I went with but for the reasons I mentioned above, I don't think it's an ideal approach.

To make this clear: RTK Query keeps cache data from a request for you, nothing more.

Something like an auth token should definitely not be "somewhere in your cache", but in a dedicated place. At no point we do or will encourage just having that value hang around in your cache, where it might get collected and thrown away, re-queried for various reasons etc.
A cache is a cache (data that can at any point just be thrown away and rerequested) and application data is application data.

[DouglasDev]

For your user auth data though: we are recommending to keep that outside of RTK Query in a normal Redux slice/httpOnly cookie or somewhere else in the first place. That would need it's own hydration with redux-persist/whichever tool would be fitting.

That is the approach I went with but for the reasons I mentioned above, I don't think it's an ideal approach.

To make this clear: RTK Query keeps cache data from a request for you, nothing more.

Something like an auth token should definitely not be "somewhere in your cache", but in a dedicated place. At no point we do or will encourage just having that value hang around in your cache, where it might get collected and thrown away, re-queried for various reasons etc. A cache is a cache (data that can at any point just be thrown away and rerequested) and application data is application data.

That exactly describes my use case. I just need to read the initial data from a cookie for the initial loading of my app. After that there are other endpoints that will return fresh user data (this is what is saved in the cookie) so it's totally fine if that initial data is thrown away and rerequested, and in fact that is what my app is currently doing. So I would argue that it definitely does belong in my cache and it is not client-side application data.

[phryneas]

Your authentication token is not a cache value.
As the author of RTK Query, I can say with confidence that it was never intended to hold this kind of data and the sub-library has not been designed to hold this type of data. RTK Query is still part of RTK and a normal RTK Slice is much more suited to hold this type of data.

(Either way, since you are already using cookies and seem to have control over your server, something like an authentication token should not even be held in JavaScript in the first place, as a security best practice. It should be a secure httpOnly cookie, set by your server and read by your server without JavaScript ever touching it.)

[DouglasDev]

The cookie contains several other types of data in addition to the token, and they are all used for the initial loading of my app, so I think my point still stands. But I do appreciate the security tip! Didn't know about the secure httpOnly cookie.