wasyl01/17/2022, 12:07 PM
to an Apollo call, so that the tag can be read in an
class? The goal is to pass an object when triggering an Apollo call, and read it later from
in the interceptor. There’s https://github.com/apollographql/apollo-kotlin/issues/2527 so I assume there isn’t (though maybe something appeared in v3?) and that the only way to do that now is to set a request header, read it in the interceptor, and strip before sending to the server?
mbonnin01/17/2022, 12:12 PM
with your own context
wasyl01/17/2022, 12:36 PM
mbonnin01/17/2022, 12:40 PM
wasyl01/17/2022, 12:43 PM
Stylianos Gakis03/11/2022, 12:32 AM
to all of them right? If this is not in production code it should be fine? With that said, if it does end up in production code, what does this break exactly? Not so proficient in the GraphQL spec tbh 😅
__typename = ""
wasyl03/11/2022, 7:54 AM
mateusz.kwiecinski03/11/2022, 8:09 AM
I removed all of the models we had in favor of more functional tests with pre-recorded jsons. If you prefer keeping models then maybe https://www.apollographql.com/docs/kotlin/testing/test-builders/ could help here? According to the documentation
They automatically populate thefield and deduplicate merged fields whenever possible.
if it does end up in production code, what does this break exactly?If you have queries structured like this it will cause cache misses. (basically you can’t reliably watch the cache due to missing
, and depending on your configuration, if there is an active watcher already it’ll trigger refetch fetcher to make additional network call to fetch the missing
value) Our app heavily relies on valid cache so the 3774 is a blocker for us, we’re still on 2.x
Stylianos Gakis03/11/2022, 8:40 AM
module, not used in production) version of the app we have where you can look browse like a list of possible cases at how screens would look like with different configurations and we use those builders to setup these different scenarios. We also use them for tests though sometimes so there I might have to be a bit more careful. This is a bit irrelevant to my question but I just thought I’d give you some context as to why I am asking the question in the first place 😄
wasyl03/11/2022, 8:59 AM
fields for you significantly. Depending on your schema it might be most models (for us it’s almost everything). But overall what can break with wrong typename is caching, so if you’re only using the models statically for tests then having some empty typename shouldn’t be a big deal
Stylianos Gakis03/11/2022, 9:03 AM