@apollo/client v3.0.0 `partialRefetch: true` unexpected network status

[migueloller]

Intended outcome:

Partial refetch results in a network status change of 4 (refetching) followed by 7 (ready). This would be consistent with calling refetch.

Actual outcome:

Partial refetch results in a network status change of 1 (loading), followed by 7 (ready).

How to reproduce the issue:

Client: https://codesandbox.io/s/apollo-refetch-bug-client-snbos Server: https://codesandbox.io/s/apollo-refetch-bug-server-7j3cl

There is code that can be uncommented to see the behavior of refetch (i.e., going from 4 to 7). If todos are added by submitting the form one can see the current behavior of partial refetch (i.e., going from 1 to 7).

Versions:

@apollo/client: 3.0.0

Notes: This is a copy of https://github.com/apollographql/apollo-client/issues/5916. That issue was closed stating the problem had been fixed, but that is not the case. The network status now goes from 1 to 7 instead of 1 to 4 to 7. The intended outcome is for it to go from 4 to 7.

[hwillson]

Let us know if this is still a concern with @apollo/client@latest - thanks!

[migueloller]

@hwillson, this is still a problem using @apollo/client@latest and can be easily seen by checking the reproduction sandbox provided. Would it be possible to check the issue has been fixed before closing the issue? This is the second time this happens 😢

Can we please reopen this issue?

[hwillson]

Thanks for confirming the repro is still valid @migueloller. We're trying to get the issue backlog here under control so we can more effectively stay on top of issues moving forward. This means we have to make certain assumptions on some of our older issues, and hope that if they're still a problem people will let us know (like you just did). Re-opening - thanks again!

[migueloller]

No problem. Thanks for re-opening the issue!

[brainkim]

@migueloller May I ask what your use-case is? I ask partly because we’re currently of the mind that partialRefetch should be deprecated (https://github.com/apollographql/apollo-client/issues/7967) because all of its use-cases were superseded by improvements to the cache. You can see my investigations into a partialRefetch issue here (https://github.com/apollographql/apollo-client/issues/7861#issuecomment-816992725), which concluded with, ahhh this all here for legacy reasons.

I’m very eager to hear your reasons for continuing to use partialRefetch!

[migueloller]

@brainkim, the use-case is to avoid having to specify all fields in GraphQL mutations that create new resources. There's a very insidious bug, which might not actually be a bug anymore, in which data is undefined if there is any partial data in it. When my team used to run into these issue we'd have to chase down all queries and mutations in our app to try and figure out what field we missed in the mutation. My idea was to rely on partialRefetch so that if a mutation returns only partial data after creating a resource, any query that as a result of the mutation now has partial data, will automatically refetch. Perhaps there's a better way to achieve this end state. If so, I'm not aware of that better way.

Ultimately what we're trying to do is reduce the complexity that happens when attempting to keep the local cache in sync with the backend. The new cache methods definitely make it easier to manipulate the cache as needed, but ideally things "just work". There's some ways to do this, like returning the changed resources in a mutation's payload, but that's not always possible or enough. For example, adding a new item to a paginated list is an absolute pain. First, how is the list sorted? One might try to cache.modify to insert the item in the right place by mimicking the sorting client-side, but now there's two sources of truth for sorting. Sometimes sorting it client-side isn't even possible (i.e., the backend might sort based on information not available to the client). Then, if you really want to make sure that what you see is what's in the backend, you've got to refetch, but since it's a paginated query things aren't as straight forward. These problems aren't necessarily directly related to partialRefetch, but for us it's under the general issue of "how do we take advantage of the local cache while keeping it in sync with the backend, without adding a ton of complexity to our code". We'd love to find an elegant solution to this, but maybe it just doesn't exist and we should just poll our queries, more like SWR.

Sorry for the mild rant 😅 but hopefully this clarified the use-case we're trying to use partialRefetch for.