https://kotlinlang.org logo
Channels
100daysofcode
100daysofkotlin
100daysofkotlin-2021
advent-of-code
aem
ai
alexa
algeria
algolialibraries
amsterdam
android
android-architecture
android-databinding
android-studio
androidgithubprojects
androidthings
androidx
androidx-xprocessing
anime
anko
announcements
apollo-kotlin
appintro
arabic
argentina
arkenv
arksemdevteam
armenia
arrow
arrow-contributors
arrow-meta
ass
atlanta
atm17
atrium
austin
australia
austria
awesome-kotlin
ballast
bangladesh
barcelona
bayarea
bazel
beepiz-libraries
belgium
benchmarks
berlin
big-data
books
boston
brazil
brikk
budapest
build
build-tools
bulgaria
bydgoszcz
cambodia
canada
carrat
carrat-dev
carrat-feed
chicago
chile
china
chucker
cincinnati-user-group
cli
clikt
cloudfoundry
cn
cobalt
code-coverage
codeforces
codemash-precompiler
codereview
codingame
codingconventions
coimbatore
collaborations
colombia
colorado
communities
competitive-programming
competitivecoding
compiler
compose
compose-android
compose-desktop
compose-hiring
compose-ios
compose-mp
compose-ui-showcase
compose-wear
compose-web
confetti
connect-audit-events
corda
cork
coroutines
couchbase
coursera
croatia
cryptography
cscenter-course-2016
cucumber-bdd
cyprus
czech
dagger
data2viz
databinding
datascience
dckotlin
debugging
decompose
decouple
denmark
deprecated
detekt
detekt-hint
dev-core
dfw
docs-revamped
dokka
domain-driven-design
doodle
dsl
dublin
dutch
eap
eclipse
ecuador
edinburgh
education
effective-kotlin
effectivekotlin
emacs
embedded-kotlin
estatik
event21-community-content
events
exposed
failgood
fb-internal-demo
feed
firebase
flow
fluid-libraries
forkhandles
forum
fosdem
fp-in-kotlin
framework-elide
freenode
french
fritz2
fuchsia
functional
funktionale
gamedev
ge-kotlin
general-advice
georgia
geospatial
german-lang
getting-started
github-workflows-kt
glance
godot-kotlin
google-io
gradle
graphic
graphkool
graphql
graphql-kotlin
graviton-browser
greece
grpc
gsoc
gui
hackathons
hacktoberfest
hamburg
hamkrest
helios
helsinki
hexagon
hibernate
hikari-cp
hire-me
hiring
hongkong
hoplite
http4k
hungary
hyderabad
image-processing
india
indonesia
inkremental
intellij
intellij-plugins
intellij-tricks
internships
introduce-yourself
io
ios
iran
israel
istanbulcoders
italian
jackson-kotlin
jadx
japanese
jasync-sql
java-to-kotlin-refactoring
javadevelopers
javafx
javalin
javascript
jdbi
jhipster-kotlin
jobsworldwide
jpa
jshdq
juul-libraries
jvm-ir-backend-feedback
jxadapter
k2-early-adopters
kaal
kafka
kakao
kalasim
kapt
karachi
karg
karlsruhe
kash_shell
kaskade
kbuild
kdbc
kgen-doc-tools
kgraphql
kinta
klaxon
klock
kloudformation
kmdc
kmm-español
kmongo
knbt
knote
koalaql
koans
kobalt
kobweb
kodein
kodex
kohesive
koin
koin-dev
komapper
kondor-json
kong
kontent
kontributors
korau
korean
korge
korim
korio
korlibs
korte
kotest
kotest-contributors
kotless
kotlick
kotlin-asia
kotlin-beam
kotlin-by-example
kotlin-csv
kotlin-data-storage
kotlin-foundation
kotlin-fuel
kotlin-in-action
kotlin-inject
kotlin-latam
kotlin-logging
kotlin-multiplatform-contest
kotlin-mumbai
kotlin-native
kotlin-pakistan
kotlin-plugin
kotlin-pune
kotlin-roadmap
kotlin-samples
kotlin-sap
kotlin-serbia
kotlin-spark
kotlin-szeged
kotlin-website
kotlinacademy
kotlinbot
kotlinconf
kotlindl
kotlinforbeginners
kotlingforbeginners
kotlinlondon
kotlinmad
kotlinprogrammers
kotlinsu
kotlintest
kotlintest-devs
kotlintlv
kotlinultimatechallenge
kotlinx-datetime
kotlinx-files
kotlinx-html
kotrix
kotson
kovenant
kprompt
kraph
krawler
kroto-plus
ksp
ktcc
ktfmt
ktlint
ktor
ktp
kubed
kug-leads
kug-torino
kvision
kweb
lambdaworld_cadiz
lanark
language-evolution
language-proposals
latvia
leakcanary
leedskotlinusergroup
lets-have-fun
libgdx
libkgd
library-development
lincheck
linkeddata
lithuania
london
losangeles
lottie
love
lychee
macedonia
machinelearningbawas
madrid
malaysia
mathematics
meetkotlin
memes
meta
metro-detroit
mexico
miami
micronaut
minnesota
minutest
mirror
mockk
moko
moldova
monsterpuzzle
montreal
moonbean
morocco
motionlayout
mpapt
mu
multiplatform
mumbai
munich
mvikotlin
mvrx
myndocs-oauth2-server
naming
navigation-architecture-component
nepal
new-mexico
new-zealand
newname
nigeria
nodejs
norway
npm-publish
nyc
oceania
ohio-kotlin-users
oldenburg
oolong
opensource
orbit-mvi
osgi
otpisani
package-search
pakistan
panamá
pattern-matching
pbandk
pdx
peru
philippines
phoenix
pinoy
pocketgitclient
polish
popkorn
portugal
practical-functional-programming
proguard
prozis-android-backup
pyhsikal
python
python-contributors
quasar
random
re
react
reaktive
realm
realworldkotlin
reductor
reduks
redux
redux-kotlin
refactoring-to-kotlin
reflect
refreshversions
reports
result
rethink
revolver
rhein-main
rocksdb
romania
room
rpi-pico
rsocket
russian
russian_feed
russian-kotlinasfirst
rx
rxjava
san-diego
science
scotland
scrcast
scrimage
script
scripting
seattle
serialization
server
sg-user-group
singapore
skia-wasm-interop-temp
skrape-it
slovak
snake
sofl-user-group
southafrica
spacemacs
spain
spanish
speaking
spek
spin
splitties
spotify-mobius
spring
spring-security
squarelibraries
stackoverflow
stacks
stayhungrystayfoolish
stdlib
stlouis
strife-discord-lib
strikt
students
stuttgart
sudan
swagger-gradle-codegen
swarm
sweden
swing
swiss-user-group
switzerland
talking-kotlin
tallinn
tampa
teamcity
tegal
tempe
tensorflow
terminal
test
testing
testtestest
texas
tgbotapi
thailand
tornadofx
touchlab-tools
training
tricity-kotlin-user-group
trójmiasto
truth
tunisia
turkey
turkiye
twitter-feed
uae
udacityindia
uk
ukrainian
uniflow
unkonf
uruguay
utah
uuid
vancouver
vankotlin
vertx
videos
vienna
vietnam
vim
vkug
vuejs
web-mpp
webassembly
webrtc
wimix_sentry
wwdc
zircon
Powered by
Title
w

wasyl

01/17/2022, 12:07 PM
Hello 👋 Is it possible to attach an arbitrary object as a
tag
to an Apollo call, so that the tag can be read in an
okhttp3.Interceptor
class? The goal is to pass an object when triggering an Apollo call, and read it later from
okhttp3.Request#tag()
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?
m

mbonnin

01/17/2022, 12:12 PM
You can use
ApolloCall.addExecutionContext()
with your own context
w

wasyl

01/17/2022, 12:36 PM
Ah, I thought there was something in v3 🙂 We’re waiting for https://github.com/apollographql/apollo-kotlin/issues/3774 before we update to v3 but that’s ok 🙂 Thanks! Btw let me know if there’s a chance #3774 will be fixed relatively soon or if we’re better off adding manual `__typename`s for the time being. We don’t mind waiting a bit, but also would rather migrate sooner than later 🙂
m

mbonnin

01/17/2022, 12:40 PM
Yea sorry, that one's on me. I haven't had the opportunity to work as much as I wanted on this last week but it's still on top of the todo list
w

wasyl

01/17/2022, 12:43 PM
No worries, just wanted to clarify the prioritization 🙂
s

Stylianos Gakis

03/11/2022, 12:32 AM
Just wondering @wasyl if you’ve gone through the migration and what approach you took to this. I’m also trying to get back to finishing this migration and I now have ~300 errors and I am not looking forward to adding them all individually 😅 I do however think that all of the references I got are for some test data and not production code, so I am guessing I could add
__typename = ""
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 😅
w

wasyl

03/11/2022, 7:54 AM
Not sure quite honestly, I’m gonna ping @mateusz.kwiecinski who leads the migration on our end (although https://github.com/apollographql/apollo-kotlin/issues/3774 is still in progress and I’m not sure if it’ll change anything wrt how typename fields are created/handled). I’m somewhat sure we removed some of our test models, as our tests mostly use prerecorded json responses anyway
m

mateusz.kwiecinski

03/11/2022, 8:09 AM
☝️ What Lukasz said. During the migration Instead of adding
__typename
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 the
__typename
field 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
__typename
, 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
__typename
value) Our app heavily relies on valid cache so the 3774 is a blocker for us, we’re still on 2.x
s

Stylianos Gakis

03/11/2022, 8:40 AM
Yeah I’ve thought of replacing everything with the test builders but it’s like hundreds of them, probably would rather work around it atm, but you’re probably right that it’s the best approach. I think I’ll try out just using “” as the typename for now to make everything build again, and I’ll see if this breaks stuff. Then maybe patch some of those places by looking at what the builders use for typename and copy that (Or is the important part that it’s just consistent? Like adding “foo” instead would still work as long as it’s consistent right) and if not just go straight to the builders. The way we use this in our code-base is a bit unique I guess, we have a bunch of builders that we use in places like here and we use those models to pass to the UI in an “Engineering Mode” (notice how this is all under a
testdata
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 😄
w

wasyl

03/11/2022, 8:59 AM
There’s good chance that https://github.com/apollographql/apollo-kotlin/issues/3774 will also reduce the number of generated
typename
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
🙌 1
s

Stylianos Gakis

03/11/2022, 9:03 AM
Nice, yeah it’d reduce them by a bunch for us too. Thanks a lot for your input!