Should contractInterface (& overrides?) be removed from queryKey?

[gpxl-dev]

At present queryKeys for contractReads are pretty massive, because they contain the entire interface for the contract.

Since the interface will not affect the result, I'd ideally like to see this removed. I think the same applies to overrides, too, at least for reads?

Finally, it would be nice to be able to pass our own queryKey to override the default - is there any reason this shouldn't be added as an option?

[gpxl-dev]

Realised this is not included in the hashed key, so what is there is probably fine.

[gpxl-dev]

Nah, coming back to this again. The cache gets very large very quickly because the ABIs are stored in it - I don't see this as being useful.

Check localStorage.get('wagmi.cache') for even a small app and I think it'll be large.

[gpxl-dev]

We think we have narrowed it down to a specific key in local storage.

One more thing - the browser will crash 99% of the time when that key is in local storage for us.

I had problems with this key working with the react query devtools...

[gpxl-dev]

We may still need part of the ABI to uniquely identify the key (could probably just serialize the function names), but yeah, the whole thing isn't needed.

@jxom - I'm not sure you need any of the ABI do you? I had to shift to my own implementation and used:

[ sender.toLowerCase(), chainId, contractAddress.toLowerCase(), functionName, args ]

sender (i.e. from) is the only part of overrides I can imagine having an impact. The ABI is constant unless it's an upgradable proxy, and in that specific case I think it's fair to expect UIs to implement a cachebuster migration, or just to not aggressively cache the value by keeping a low staletime.

Note that keeping the keys pretty simple, and hierarchical (least specific to most specific) makes them easy to invalidate, e.g. queryClient.invalidateQueries([ account ]) will invalidate all queries specific to one account, and of course you can go to e.g. contract level or the specific method without having to find ABIs etc.

[jxom]

@gpxl-dev – yeah, you are right. We probably don't need it at all. I just remembered addressOrName (w/ functionName) would already be sufficient enough to uniquely identify the key.

[jxom]

@niratodev @gpxl-dev – let me do some digging. We will get this fixed.

[jxom]

ICYMI – this is fixed in 0.6.4.