Apollo-client: [AC@3] MissingFieldError should be muted by default because fields can be optional

Created on 23 May 2020  路  7Comments  路  Source: apollographql/apollo-client

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.

Most helpful comment

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.

All 7 comments

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 MissingFieldErrors 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.

Was this page helpful?
0 / 5 - 0 ratings