A modern programming language that makes developers happier.

kotlinlang

:wave: 
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?

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 :eyes:

image.png

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

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

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 :sweat_smile:

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

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

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

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 :eyes:
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 :slightly_smiling_face:

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

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 :sweat_smile: )

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 :slightly_smiling_face: The thing I stumbled upon seems to be fairly easy to work around, so :shrug:
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 :slightly_smiling_face:

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

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

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

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