useQuery re-render even if cached when neighbor data (but not retrieved by useQuery) is newly retrieved about urql HOT 4 CLOSED

I haven't fully looked at this admittedly, but looking at this, are you referring to tags i.e. a scalar list of string[] / [String]?

If so, if you have two queries that, instead of defining fragments and hoisting & spreading them in a single query, load the same scalar field then the two values cannot be equal.

This is because two queries will launch two operations that will both be fulfilled by the API, even if they overlap. In turn, this means that tags: [String] will be loaded twice and the resulting value, given that it's a reference, is not normalised and can never be reference equal to itself — i.e. since it's unrealistic to expect them to be deeply compared, since we treat all scalars as opaque values, they'll never be equal once they've been fetched from the API twice.

This could of course be prevented by somehow treating API results in a special manner and assuming that they're JSON-equal, and comparing that. However, this would have a significant impact on the performance of cache reads. After all, the cache reads are expected to visit each field in the query AST and process them.

So, I don't think that this is behaviour that's unexpected, and I'd recommend you to — if you expect this to behave differently in a real app — to hoist and combine queries as much as possible and otherwise either make sure that you deep-diff parts of data where you need (which of course shouldn't be needed often) or strategically memoise rendering results or computed values.

Sorry if that's not the answer you were looking for though!

from urql.

Thanks for the reply. In the reproduction, individual Todo (query TodoDetail) does not include tags, but when query TodoDetail is executed, tags in TodoList is updated.
I think there might be a case that the client want to retrieve non-detailed list for the performance reason (server dependent, maybe), so the reproduction pattern would be a possible case.

from urql.

Yea, the reason is because the List of strings is seen as updated which is being queried from the list, and afterwards from the details/... Tbh, I would not really see this as a bug as much as a maybe-optimization but I reckon comparing those lists is more expensive than just doing a React-render that bails out anyway as it sees no changes.

from urql.

I am going to close this out as we can't really make assumptions about these scalars, generally speaking the issue would be here where the array reference isn't the same, this makes sense but we can't really deep compare as this could be a Date, ...

from urql.