Missing all local fields when a field resolver is not implemented

apollographql / apollo-client

:rocket: A fully-featured, production ready caching GraphQL client for every UI framework and GraphQL server.

https://apollographql.com/client

MIT License

19.33k stars 2.65k forks source link

Missing all local fields when a field resolver is not implemented #10768

Open nathanschwarz opened 1 year ago

nathanschwarz commented 1 year ago

Issue Description

What's happening : when querying multiple local fields with the @local directive, if one of the field resolver wasn't implemented, all local fields are missing.
What should happen : only the field missing implementation should be undefined

Link to Reproduction

https://codesandbox.io/s/adoring-diffie-4krgf6?file=/src/index.jsx:0-2604

Reproduction Steps

add 2 new local fields to one of your graphql schema
only implement one resolver in your typePolicies
run the query

bignimbus commented 1 year ago

Hi @nathanschwarz 👋🏻 thanks for letting us know about this - can you help us understand more about your use case here? I'm curious as to why you'd query a field with @client without defining a field policy. Thanks!

nathanschwarz commented 1 year ago

hi @bignimbus ✋ ! Thank you for taking time on the matter ! I'm working on a project which is heavily relying on local fields (more than 20). I made a typo error while defining a new field policy (forgot a s in the field name). At this point my whole application started crashing since all local fields went missing. Since all errors where popping progressively on some non related local fields I was completely clueless about why it was happening, and started looking for the issue elsewhere. Took me a while to figure it out. This is something that should be at least documented somewhere. But it makes more sense not to discard all local fields / type policies if one is "missing". In my case, if only the wrongly defined field was missing I would have notice the issue right away.

bignimbus commented 1 year ago

Thanks for the quick reply @nathanschwarz - I agree that more documentation is warranted here. I'm not certain what, if any, behavior changes are warranted here. I'll leave this issue open in case others want to give feedback. In the meantime if you have any suggestions as to how we should document this behavior we'd be interested in hearing them!