portalicious: fix request caching #6007
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aberonni
force-pushed
the
aberonni/portalicious-caching
branch
from
b82d27a
to
4a83d56
Compare
AB#31036 On some requests in the export functionality, the same request + http parameters were being sent to the backend, even when the http parameters being used to make the request in the service were different. I started by changing the `generateQueryOptions` function to have an exhaustive list of query keys, thinking that the lack of `requestOptions` in this array was the culprit. It was not. So then I refactored the `HttpWrapper.performRequest` to only accept HttpParam _objects_ instead of HttpParam _class instances_. My thinking here was that tanstack-query was struggling to serialize class instances as opposed to objects. This was partially true, but did not solve the problem entirely. I ultimately added the `paginateQuery` option to the `generateQueryOptions`, because I realised that the issue was that the call to the Signal `paginateQuery` needed to happen _inside_ the `queryFn` in order to allow the "signals to signal". I'm not sure any of my thought process actually makes any sense, but hopefully you find the resulting code cleaner either way, given that now we don't have to worry about creating HttpParams anywhere anymore, and we just deal with objects.
aberonni
force-pushed
the
aberonni/portalicious-caching
branch
from
4a83d56
to
2a379d5
Compare
PeterSmallenbroek
approved these changes
Oct 31, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
AB#31036
Describe your changes
On some requests in the export functionality, the same request + http parameters were being sent to the backend, even when the http parameters being used to make the request in the service were different.
I started by changing the
generateQueryOptionsfunction to have an exhaustive list of query keys, thinking that the lack ofrequestOptionsin this array was the culprit.It was not.
So then I refactored the
HttpWrapper.performRequestto only accept HttpParam objects instead of HttpParam class instances. My thinking here was that tanstack-query was struggling to serialize class instances as opposed to objects.This was partially true, but did not solve the problem entirely.
I ultimately added the
paginateQueryoption to thegenerateQueryOptions, because I realised that the issue was that the call to the SignalpaginateQueryneeded to happen inside thequeryFnin order to allow the "signals to signal".I'm not sure any of my thought process actually makes any sense, but hopefully you find the resulting code cleaner either way, given that now we don't have to worry about creating HttpParams anywhere anymore, and we just deal with objects.
Testing
There is nothing to test in the UI - as in, everything should work like before because the original buggy behaviour was only encountered in #6000
Checklist before requesting a review