https://kotlinlang.org logo
Title
j

Joe

10/29/2021, 6:40 PM
Anyone already thought about the new GraphQLContext map and type-safe context storage? We currently have a context object with some well defined/typed properties; moving to a string key + a cast of the returned value feels like a step back even though it'd probably be fine. Possibly extensions to GraphQLContext for these well defined properties might make sense, but haven't fully thought this through yet, so wondering if others had?
d

Dariusz Kuc

10/29/2021, 6:54 PM
s

Shane Myrick

10/29/2021, 6:54 PM
The “cast” is still happening on our end in the old object. We just take the context and send it to the argument that we hope will match so in a way that is less safe. You also don’t have to store in the map by string, you can store by anything that can be used as a key, even another object For example, the graphql-java engine now uses this method internally to pass around config options for the parser https://github.com/graphql-java/graphql-java/blob/992d95fe43e7b86a9299921d2ac1822bd3e9e204/src/main/java/graphql/ParseAndValidate.java#L50
d

Dariusz Kuc

10/29/2021, 6:54 PM
lol timing
s

Shane Myrick

10/29/2021, 6:55 PM
🦥 ⌨️
j

Joe

10/29/2021, 9:15 PM
thanks, getting away from string keys does help a bit actually.
dealing with
mapOf()
when creating the context but dealing with
GraphQLContext
when consuming it is a little confusing, but that looks to be a graphql-java issue, not a graphql-kotlin one