Naming conflicts on generated Query Mock Object

[tonyarnold]

Question

I'm currently facing an issue in the project I'm working on where I have two different queries:

query Screen1() {
  eventList: anEventQuery(…) { … }
}

query Screen2() {
  eventList: someOtherEventQuery(…) { … }
}

Unfortunately, this leads to the generated Mock in my module ending up with only one of those two variants available.

Is there a way to do this short of ensuring that the top-level fields and aliases in my queries are unique?

[BobaFetters]

Not sure if I am fully understanding the question, it sounds like you are expecting to have a mock generated for each of the 2 queries you mentioned? Mocks are generated based on your schema objects so that you can programmatically create instances of those objects and use those to initialize response models to mock a query. There is further explanation for why this is done this way here.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.

[tonyarnold]

Maybe our project is misconfigured, but we seem to have a Mock Query "god" object being generated, and our developers have been using Mock<Query>(…) to build the expected mock responses for these screens.

It looks like this:

public class Query: MockObject {
  public static let objectType: ApolloAPI.Object = MyCompanySchema.Objects.Query
  public static let _mockFields = MockFields()
  public typealias MockValueCollectionType = Array<Mock<Query>>

  public struct MockFields {
    @Field<[GroupModeChatChannel]>("availableChannels") public var availableChannels
    @Field<[GroupModeChatChannel]>("availableOpenChannels") public var availableOpenChannels
    @Field<Node>("channel") public var channel
    @Field<Client>("client") public var client
    @Field<ClientAddressLookup>("clientAddressLookup") public var clientAddressLookup
    @Field<ClientAddress>("clientFindAddress") public var clientFindAddress
    @Field<SpecificEventList>("eventsList") public var eventsList
    // …
}

So you can see there the eventsList at the bottom - that's one of two fields that should be present, but the names for them are the same.

I'm just not sure what we're doing wrong here — I assume it's a lack of name spacing somewhere, but I'm not fluent enough in GraphQL to know how to resolve this issue.

I was hoping that someone here might recognise the problem and guide me in the right direction?

[BobaFetters]

Ok I think I see what's going on, so in your schema you probably have something like:

type Query {
  eventList: [Events]
}

and then you have 2 separate operations like you mentioned:

query Screen1() {
  eventList: anEventQuery(…) { … }
}

query Screen2() {
  eventList: someOtherEventQuery(…) { … }
}

So the generated Query+Mock.graphql.swift file that contains the public class Query: MockObject generates entries for all of the queries defined in your schema (the first code snippet above). Your operations don't get mocks generated for them because that is what you are building with your mocks, so the Event type in your schema will have a file like Event+Mock.graphql.swift generated for it with all possible fields available on it as optionals.

So to build mocks for your 2 examples you would do something like:

let screenOneMock = Mock<Query>(
  eventList: [
    Mock<Event>(
      name: "eventName1"
    ),
    Mock<Event>(
      name: "eventName2"
    )
  ]
)

let screenTwoMock = Mock<Query>(
  eventList: [
    Mock<Event>(
      id: "eventId1",
      type: "eventType1"
    ),
    Mock<Event>(
      id: "eventId2",
      type: "eventType2"
    )
  ]
)

So you can create mocks for any operation by just assigning data to the appropriate fields on your mock types. A reference in our documentation can be found here. Hope this helps!

[tonyarnold]

That was super helpful, thanks @BobaFetters!

In a lot of places, the project this is affecting was using .init(…) instead of specifying the required type — obviously that works once there's no ambiguity, but I had to specify the full, proper Mock<…> for my second-level parameters, too.

Thanks again.