use options.header to re-memoize query configs

[jrea]

use options.header to re-memoize query configs

[rctbusk]

Hey @jrea, Would you be able to provide a more concrete example of what you mean? Potentially example code here or a codesandbox link?

Based on what you are saying now though, this is the solution I can think of. We very intentionally decided to only use URL and parameters when generating the default query key. We want to be as minimalistic as possible. We provide a very easy way to pass in your own query key.

A solution to your problem could be to write your own query key generator. If you include headers in every single query key, then this should cover your needs.

[jrea]

Example code would be something like:

const originalToken = 'original';
const updatedToken = 'updated';
const config = token => ({
    url: 'someURl/listData',
    options: {
      headers: {
        Authorization: token,
      },
    },
  });
useRequest(config(originalToken)); // makes request to someURL/listData with 'original'
useRequest(config(updatedToken)); // makes request to someURL/listData with 'original'
  

If I go the query key generation route, every 6 seconds will create a new queries state entry. As time goes on, memory usage will increase indefinitely.

My argument at it's core is that I would expect if I have passed a query config to redux query and it is http signature is unique, it executes. I would not expect this for different transforms or updates.

A more contrived example would be where I GET and POST to the same url + body, both would execute.

[rctbusk]

If I go the query key generation route, every 6 seconds will create a new queries state entry. As time goes on, memory usage will increase indefinitely.

I am confused about what you mean where. If we decided to instead default generate a query key based on options or on method, it would do the exact same thing. It would increase the query state if you kept sending queries that would be considered unique.

If you pass us a query key that you have passed before, it will return the memoized values. Just like if we generate a query key we have seen before.

We intentionally make our default behavior only memoize on the minimum required. We provide the customizable query key for special cases like yours.

[jrea]

If we decided to instead default generate a query key based on options or on method, it would do the exact same thing.

This is my concern. I am forced into making query keys at N rate due to the memoization. My original idea would be outside of the memoization. I understand the friction against that idea.

Would it be possible to add the ability to customize the memoization?

[rctbusk]

What do you mean customize the memoization?

[jrea]

I'd like to be able to invalidate the cache from a function I provide, vs the default one that only can use the query key.

If I had the ability to customize how config objects are memoized, I could ensure that as the authorization expires, the query config gets updated, but does not create new state.

[rctbusk]

We provide this functionality since you can pass in your own query key. You can write a function that returns a query key. This function can be written in such a way to take into account the auth and anything else it needs.

Having a custom query key solves the problem you are talking about. I am not sure why this wouldn't work for you.

[jrea]

A continually unique query key increases redux-query's state indefinitely. If I generate a unique query key for every unique authorization header, it will end up being thousands of stale entries in redux query's state.