I have unnecessary reference changes, is it a bug?

[RIP21]

Hi!
I have pretty simple query that looks like

query Name {
  enabled
  me {
     id
    company {
    ...Common_MeCompany
    }
    settings {
      ...Common_UserSettings
  }
  }
}

And surely I made it into reusable hook passing down TypedDocumentNode that I got generated by graphql-codegen.

And as I have a default network policy I expect that this useQuery + dedupExchange with the same DocumentNode I expect to end up with instant cache hit always hence no effects triggered (as a reference will be stable) plus usage of this same query in multiple places with dedupe means only one request with such query will be executed and I guess it's true. Problem is that on route changes (using react-router) it pretty often returns if I compare previous and next state of data something like
true, true, true, true, false, false, false, true.
Sometimes it gets changed like 70-80 times depending on the view for absolutely no reason. And there are NO network requests, so it suppose to start to listen to this query and never bother to updated unless refetch called.

This is how I test reference equality

With regular cacheExchange it works as expected all calls of the hooks endup in true x 100 times and counting
But with Graphcache it's getting broken. I have all latest versions of all exchanges.

Here is mine UrqlProvider, I also checked its reference equality (of client) and whether it rerenders ever, and no, it only renders once on app init:

export const UrqlProvider: React.FC = ({ children }) => {
  const token = useAccessToken()
  const client = useMemo(() => {
    const options: Parameters<typeof retryExchange>[0] = {
      initialDelayMs: 1000,
      maxDelayMs: 15000,
      randomDelay: true,
      maxNumberAttempts: 2,
      retryIf: (err) => !!err.networkError,
    }

    return createClient({
      url: '/graphql',
      exchanges: [
        devtoolsExchange,
        dedupExchange,
        refocusExchange(),
        cacheExchange({
          schema: (introspection as unknown) as IntrospectionQuery,
          keys: {
              //...
          },
          updates: {
            Mutation: {
            // ...
            }
        }),
        retryExchange(options),
        errorExchange({
          onError: (error) => {
            if (error.response?.status === 401) {
              AuthService.logout()
            }
          },
        }),
        fetchExchange,
      ],
      fetchOptions: () => {
        return {
          headers: { authorization: isNotEmptyOrNullish(token) ? `Bearer ${token}` : '' },
        }
      },
    })
  }, [token])

  return <Provider value={client}>{children}</Provider>
}

In the devtools screenshot below the topmost is this mentioned query and when I change to certain pages (that are full of with useMe usage) it's getting crazy with those icons above about operations or so (it also causes a lot of true x 56 and then false x 56) and it rerenders 2 times respectively (on one of the pages I call useMe in each table cell to check whether a user has isReducedMotion flag in his user preferences to disable/enable animation)
This is how it looks in console:

And in devtools

Any ideas? Is it a bad idea BTW to call some common query in the cells? (me is getting called at the load of the app, so it should be cached all the time before these cells are even rendered or anything else that uses useMe renders) :)

[JoviDeCroock]

This is not a bug, the normalized-cache will always produce fresh objects, this because it looks at the incoming query and will assemble the result you're asking for in the caching layer. This means that the results aren't referentially equal but they are deeply equal, the properties didn't change, just the object that wraps them.

When these results are in-cache the response will be quite instant so multiple queries that are synchronous aren't deduped while in-flight ones are.

[JoviDeCroock]

Exactly, everything is fresh, consider it like one big list of entity:id.property, the cache looks at your query and will start picking from the list and assemble the data you've requested. This implies that objects/arrays won't be equal while all the strings/... will be

[RIP21]

BTW @JoviDeCroock I guess it will be nice to have it documented maybe? I'm pretty surprised I haven't found anyone complaining about it before :)

[JoviDeCroock]

Noted, thank you for the bump!

Your provider looks fine, how I often look at it is we defer asynchronous parts to the back so we can have nice and snappy UI.

• We want to visualize all operations in the devtools, so we don't lose information (we could opt to put it behind dedup but is a preference)
• Dedup, we want to dedup as soon as we can we don't want to hit any exchanges in case we miss somehting.
• Cache, the in-memory/synchronous part of the exchanges, this is the last part of your chain where we can get a response that just arrives without any fetching: true
• retry, this goes behind the cache as we only want to retry the fetch anyway
• error, this way you have visibility of your errors before they hit retry
• fetch, the last part to actually fetch data when it's not in cache

[RIP21]

So no matter if 100 same queries are running simultaneously (and have their result is in cache), the Graphcache engine will build an object in the data field for each of them one by one and each reference will be different.
OK, today I learned.
Sorry for a lot of spam, just getting into advanced stuff and it's getting harder to keep it all smooth :)

[RIP21]

@JoviDeCroock thanks! Makes total sense now, sort of compose function from bottom up.

[RIP21]

@JoviDeCroock BTW, I'm still unsure how I should use data I fetched using urql useQuery in useEffect?
If it's an object I can ignore the ESLint rule about hooks and trigger it on id change let say. (still NOT what I would like to do)

But what if it's an array with 50-100 items and I want to trigger useEffect ONLY when a new array is fetched and it's different from the old one in cache, how can I ensure useEffect never gets trigger aside from relatively expensive deep comparison by id (if I have one surely).
As you may imagine it will cause A LOT of code for no reason and a lot of eslint-disable in dependencies arrays as ESLint rules for React Hooks won't be happy about that which may lead to some other nasty bugs as I'll miss adding certain dependency at times etc.

This instability kinda makes these sorts of effects very fragile.
Example:

 const [integrationsPairs, setIntegrationsPairs] = useState<IntegrationPair[]>(
    [],
  )
 
 const [selectedIntegrationId, setSelectedIntegrationId] = useState<string>()
 
 const [result] = useQuery(...)
 const { integrations } = result.data ?? {}
  useEffect(() => {
    if (isNotEmptyOrNullish(codatIntegrations)) {
      const integrationPairs = codatIntegrations.map<IntegrationPair>(
        (it) => ({
          name: it.name,
          integrationId: it.id,
        }),
      )
      setIntegrationPairs(integrationPairs)
      setSelectedIntegrationId(integrationPairs[0].integrationId)
    }
  }, [integrations])

Basically when I want to process incoming async data and set it into the local state for some purpose.
On refocus it may happen that reference changes (even tho nothing has changed) causing the state to reset.
I guess any refetch caused by refocus exchange or cache-and-network will cause a reference change? Or I'm wrong?
Because if nothing is changed in the cache after the update then it's a bit sad reference changes and all these issues appear.

Surely I can work around above with setting integration id, by just checking whether the current id is not different from new one, but it won't work if I selected another id (in select input), then it will reset again causing me issues again :(

Maybe you have some hints on how to handle that?
I don't see any other option than implementing some useDeepEqualEffect which will compare dependencies deeply but that could be MEGA expensive in some scenarios (maybe not as expensive as I think, but still) :)

[RIP21]

@kitten hey maybe you can give some thoughts :) Sorry for being a bit demanding :D (we're all getting spoiled here in urql repo with how quick you folks answer, that's a side-effect of an amazing job you all did :P)

[kitten]

Yea no worries 😅 There are several ways in which you could approach this but all are very similar. You could use fetching and operation.key as change signals. If either the key changes and fetching goes to false, it's safe to assume that the data has changed. That however obviously doesn't catch passive updates.

For those it isn't too bad of an idea to consider deriving just the data you need (compute first with a memo) and then doing deep comparisons (eg with react-fast-compare)

The overhead can be reduced (and isn't that bad in general if it's not on every query) as long as you derive a smaller piece of data first and then do a comparison over time.

[RIP21]

@kitten Good :) Anyway the perceived and actual performance boost I'm getting from aggressive caching of Graphcache is compensating all those trade-offs easily.
So I just need to write them down somewhere so my future teammates (I'm a one man band now) will get the idea without spending 5 hours checking WHY THE HELL EFFECT TRIGGERS and get productive quick :)
Thanks for all the info and hacks! Really, you guys are the best (and I'm really in love how you handle issues, you have below 20 of them and it's impressive (thanks to discussions feature too, so questions are going here))