Hi! Do Data Builders support mutations / queries i...

# apollo-kotlin

[scana]

Hi!
Do Data Builders support mutations / queries in multi-module projects?

Assuming I have a schema and some base mutations defined in a base module and an additional mutation in feature module, which depends on that base one.

I see the following inside of a feature mutation:

public fun Data(resolver: FakeResolver = DefaultFakeResolver(__Schema.all),
        block: MutationBuilder.() -> Unit = {}): Data = buildData(
      CreateAddressMutation_ResponseAdapter.Data,
      CreateAddressMutationSelections.__root,
      "Mutation",
      GlobalBuilder.buildMutation(block),
      resolver,
      __CustomScalarAdapters,
    )

That MutationBuilder is in turn located in the base module and knows nothing about CreateAddressMutation, so I cannot do something like:

CreateAddressMutation.Data {
   createAddress = buildAddressNode {

   }
}

because I cannot access "createAddress".

I wonder if I'm approaching the whole concept in a wrong way 🤔

[scana]

A sample mutation:

mutation CreateAddress(
  $fullName: String!
  $addressLine1: String!
) {
  createAddress(
    fullName: $fullName
    line1: $addressLine1
  ) {
    address {
      ...Address
    }
  }
}

[Stylianos Gakis]

Is this perhaps a matter of your main module having to know which types are in fact needed so that it knows to generate all the code for them?

https://github.com/HedvigInsurance/android/blob/develop/app%2Fapollo%2Fapollo-octopus-public%2Fbuild.gradle.kts#L34-L51

Also in 4.x this as I understand would be improved, you are on 3.x now I assume right?

[Stylianos Gakis]

Prior discussion https://slack-chats.kotlinlang.org/t/16051277/so-speaking-of-more-multi-module-stuff-i-got-a-query-like-th#976bd846-3cb0-4815-80a1-f73a853fe962 which I think is the same as yours.

[scana]

Thanks for pointing that out!
So the thing is that we use lots of TestBuilders and it seems that we cannot switch to v4 without migrating Test Builders to Data Builders first, so I wanted to just do that partially over time.

Is this perhaps a matter of your main module having to know which types are in fact needed so that it knows to generate all the code for them?

It's not necessarily the type itself, just the mutation / query - unless that's considered a "type" as well?

[Stylianos Gakis]

Yeah in 3.x your schema module only knows about the queries inside that schema module by default. The submodule queries/mutations are not taken into account as to what to generate for those.
Can you try adding things in your gradle like we do in the link above to see if that solves your issue?

[scana]

Not sure if I follow your changes under alwaysGenerateTypesMatching 🤔

Given this schema:

createAddress(
    city: String
    fullName: String
  ): CreateAddressMutation

type CreateAddressMutation {
  address: AddressNode
}

I tried the following:

alwaysGenerateTypesMatching.set(
    [
      ...
      "CreateAddressMutation"
      ...
    ]

But the MutationBuilder does not seem to pick it up - I suppose I could have just keep that mutation declared within the base module, but it kills the multi-module setup.

[Stylianos Gakis]

What if you add AddressNode?

[Stylianos Gakis]

Also you could try (alwaysGenerateTypesMatching.set(listOf("*")) as discussed in the original thread I linked above, and if that works you can work your way backwards to the minimum required code to make it work.

[scana]

But does it work for you? Meaning does it expand MutationBuilders and QueryBuilders this way? My understanding was that this would fix generation of duplicate classes in your case.
I'll try it out in few hours once I'm back home.

[scana]

Ok - so .* does work - I'll try to figure out required steps now.
@mbonnin I feel bad for pinging you again but maybe you have some ideas on how to satisfy types generation for mutations to show up in a MutationBuilder 😅

[Stylianos Gakis]

Did you try this? https://kotlinlang.slack.com/archives/C01A6KM1SBZ/p1715192327122589?thread_ts=1715176190.330959&cid=C01A6KM1SBZ

[scana]

I did - and then retroactively started adding other dependencies but nothing changes 🤔

[scana]

Narrowed it down to:

".*createAddress",
"CreateAddressMutation",

and now it works:

public var createAddress: CreateAddressMutationMap? by __fields

Although it still does not generate AddressNode inside of it, despite adding "AddressNode" - I'll keep digging.

[scana]

Ok - so it seems that I have to do it like this:

".*createAddress",
"CreateAddressMutation.*",

Otherwise it won't include mutation response fields. I wonder if there is some verbose mode which would let me see how those types are actually named 🤔