:wave: I want to manually modify Apollo cache state. 2.x exposed `ApolloStore#writeAndPublish` whic...

# apollo-kotlin

[mateusz.kwiecinski]

👋
I want to manually modify Apollo cache state. 2.x exposed ApolloStore#writeAndPublish which required query and query data only. 3.x exposes ApolloStore#writeOperation but in my scenario it also requires passing customScalarAdapters: CustomScalarAdapters (to properly handle passed data object)
Is there any way to access customScalarAdapters set previously on ApolloClient instance?

[mateusz.kwiecinski]

More context: My ApolloClient is configured using addCustomScalarAdapter so I never have reference to CustomScalarAdapters instance. AFAICS the only way to properly use the writeOperation is to manually build CustomScalarAdapters, save it and pass it via ApolloClient.Builder#customScalarAdapters.

I chcecked I can’t access ApolloClient#customScalarAdapters because it’s private, I can’t access ApolloClient.executionContext[CustomScalarAdapters] because it’s not part of the context 👀

[mateusz.kwiecinski]

I think I can share a screenshot of what I’m trying to achieve 😅

[mbonnin]

Good catch. I don't think there's anything like that so the short term solution is to construct your customScalarAdapters ahead of time and then keep a reference to that

[mbonnin]

If you don't wan't to have it as a separate reference, you could also put it in the execution context manually, that'd work 😅

[mbonnin]

Now for the slightly longer term solution, I think we can make ApolloClient.customScalarAdapters public

[mbonnin]

Want to open a PR about this?

[mbonnin]

That's the nice thing with everything being immutable is that exposing this should be pretty safe

[mbonnin]

We still default fields to private or internal because it's always easier to add rather than remove but in this specific case, I think it's pretty valid to have it public

[mateusz.kwiecinski]

Yeah, making it public seems to be the easiest what the library can do.
I’m yet wondering if there isn’t anything smarter that can be done. To somehow default to apollo’s execution context instead of using Empty as the default argument 👀
I’ll browse through the code for a while (I’m still catching up with all the changes 3.x introduces) and if I can’t think of anything reasonable I’ll raise a PR to make the field public 🙂

[mbonnin]

ApolloStore doesn't know much about ApolloClient and I kind of like that they are decoupled

[mbonnin]

Something we could do is pass customScalarAdapters once during ApolloStore construction (and remove the parameter in all calls) but it's pretty late to make such a big API change (stable ships tomorrow 😅 )

[mateusz.kwiecinski]

I guess there aren’t many people manually accessing ApolloStore so yeah for sure it wouldn’t be worth making any significant api changes right now 🙂 The thing I stumbled upon seems to be fairly easy to work around, so 🤷
Alternatively, instead of making a PR to expose the field publicly I can file an issue which you can discuss internally how you’d like to handle it 🙂

[mbonnin]

Sounds good 👍. We'll most likely make the field public in all cases, that seems an easy way

[mbonnin]

https://github.com/apollographql/apollo-kotlin/pull/3714

[mateusz.kwiecinski]

Ah, sorry. I missed that and created new issue: https://github.com/apollographql/apollo-kotlin/issues/3721 😕

[mbonnin]

No worries at all, it's always good to have issues and context behind the PRs

[mbonnin]

Thanks for opening this!