Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

portalicious: fix request caching #6007

Merged
merged 1 commit into from
Oct 31, 2024
Merged

Commits on Oct 31, 2024

  1. portalicious: fix request caching

    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 committed Oct 31, 2024
    Configuration menu
    Copy the full SHA
    2a379d5 View commit details
    Browse the repository at this point in the history