Custom structural sharing (merge) option for useQuery

[richsilv]

For legacy code reasons, I have a use case in which I'm using an API wrapper to access an API endpoint in my useQuery query function, and the wrapper returns an array of class instances. This is problematic since I don't get any structural sharing due to the non-JSON-serializable nature of the class instances, and there are many cases in which passing my own deepEqual function would do little to help; if only a single instance of 50 in the response genuinely differs in value (as opposed to reference), my view layer will still end up rerendering all 50.

What I'd like is a way to specify a customMerge function (like custom structural sharing), which takes the current cache TData (or undefined) and the incoming TData, and merges them into another TData, so that the consumer can dictate how to usefully retain references. In my case, a simple hash of the class properties would be enough to determine which elements of the cached array could be retained, and which need to be replaced.

I think the implementation could be very simple indeed - just checking whether a customMerge function has been passed in replaceData, and returning the result of calling it with prevData and data if so.

If I'm the only person who ever needs this, I'd be happy to hear that this was the case, but my suspicion is that others will be forced to use API wrappers (or similar) which return non-JSON-serializable objects and are essentially locked out of structural sharing as a result, even though the logic to implement the appropriate level of reference-recycling for their use-case might be pretty simple.

[TkDodo]

would it be an option to keep json serializable data in the cache and do the transformation to class instances in a different layer? The select option would come to mind, or maybe just a custom hook that creates the instances in a useMemo ?

[richsilv]

Thanks for the suggestion. I know that keeping JSON serialisable data in the cache is the canonical usage, and I can see why it's desirable, but there are a couple of problems that I can see:

• we have an existing REST API adaptor which itself has a nice API for making requests, but returns class instances. We can't change its interface without breaking things for other consumers, so this would leave us having to factor out and reuse all of the REST API communication logic it contains. This is perfectly feasible, but a huge amount more work than telling react-query how to merge the objects it returns.
• aside from that, if we wanted to use classes in the view layer, even constructing them in the selector or a useMemo hook rather than the query function would require new serialisation logic for us to be able to optimistically update the JSON in the cache. If we're constructing a Post class which has Maps and Sets in it from the JSON returned from the API, we'd need to serialise the class instance (with changes) to insert into the cache, to have it immediately deserialised again in the select function or useMemo. My natural response would be "but surely you're doing that anyway to communicate the update to the REST API", but not all APIs (and certainly not all endpoints) demand a fully-serialised version of an entity to make an update, so it's quite possible you'd be writing serialisation logic purely to update the client-side cache. For that reason, it would be nice not to allow the serialised version to bleed out of the query function, and to just be able to deal with Posts throughout. Obviously, that then breaks structural sharing, unless you're able to provide your own sharing logic.

I can completely understand reticence to increase the surface area of a library, but the change set would be an additional three lines of code (plus tests, of course). I would be very happy to provide a PR.

[TkDodo]

what do you think about this suggestion?

#3715 (reply in thread)

[richsilv]

Perfect, that would absolutely suit our use-case.

[richsilv]

fwiw I'd be very happy to implement this if you'd like.

[TkDodo]

yes, please go ahead!