AC (from 3.0.0-beta.43) is raising a MissingFieldError
if a @client
query includes fields that are missing in the underlying cached object.
I can understand this, but assuming that there is no schema validation client-side, and that the field could be optional, a simple query like this:
query {
myObject @client {
optionalField
}
}
Even with { returnPartialData: true }
Will raise a MissingFieldError
if optionalField
is not initialised. For a trivial example like the Todo app (using ReactiveVar
for managing the local state), all fields can be initialised. For a real life app, it is not something always possible, and would greatly complexifies migrations.
IMHO this error should be muted by default. Checking client query fields against an eventual schema should be done offline (ie. with a graphql code generator) and should not raise warning (or errors) at runtime for fields that are potentially optional.
I disagree with the following statement in https://github.com/apollographql/apollo-client/issues/6308 and I think this should be reconsidered:
usually points to an error in your code
Agreed here. We're trying out the beta and getting a lot of MissingFieldError
s for fields that exist in the schema but just haven't been pulled from the server yet so they don't exist in cache. These cause the entire app to crash without granular error handling/boundaries across the codebase.
I think this is a valid issue - the documentation suggests that even the default behavior of cache-first
will make a network call if any fields necessary to fulfill the query are missing, so why would a warning be necessary?
Edit: I wish it was easier to find but here's the link I use to understand fetch policies:
https://www.apollographql.com/docs/react/api/react/hoc/#optionsfetchpolicy
If all the data needed to fulfill your query is in the cache then that data will be returned. Apollo will only fetch from the network if a cached result is not available.
+1 on this.
usually points to an error in your code
I disagree with that as well. So the idea of GraphQL is to fetch what you need. So without ability to mute MissingFieldError
, that force us to prefetch information because we might need it in the future doesn't sounds like its the right thing to do.
I don't mind this being a default behaviour, but giving developer ability to turn this off would not short change developer who want to take advantage GraphQL unique ability to progressively fill up their cache with only information they need, is fundamentally what make GraphQL popular.
I hope this can be muted. For now, we have to wrap it inside a try/catch
and catch MissingFieldError
explicitly to overcome this problem.
Yes, please!
I need the ability to suppress the MissingFieldError
as well. The try/catch is not a good way to handle this.
Most helpful comment
I disagree with that as well. So the idea of GraphQL is to fetch what you need. So without ability to mute
MissingFieldError
, that force us to prefetch information because we might need it in the future doesn't sounds like its the right thing to do.I don't mind this being a default behaviour, but giving developer ability to turn this off would not short change developer who want to take advantage GraphQL unique ability to progressively fill up their cache with only information they need, is fundamentally what make GraphQL popular.
I hope this can be muted. For now, we have to wrap it inside a
try/catch
and catchMissingFieldError
explicitly to overcome this problem.