Abstract Types

Use __typename to specify a concrete type for an abstract field.

note

This page assumes familiarity with the concept of scenario. If you want to learn about scenarios, read the "Mocking queries" section of the docs.

By default, when Kimera needs to generate mocks for a field which is an interface or a union, it will do so as if the field were a concrete type. It will do so by automatically selecting the first concrete type defined in the schema for that interface or union.

Let's use the following schema as an example:

type Query {
  ships(model: String!): [Ship]!
  assets: [Asset]!
}

interface Ship {
  id: ID!
  model: String!
}

union Asset = Powerplant | Starship | Rocket

type Rocket implements Ship {
  id: ID!
  model: String!
}

type Starship implements Ship {
  id: ID!
  model: String!
  class: String!
}

type Powerplant {
  address: String!
}

With no configuration, Kimera will return:

a list of Powerplants for the assets query because the first concrete type defined in the schema for the Asset union is Powerplant;
a list of Rockets for the ships query because the first concrete type defined for the Ship interface is Rocket.

Customize mocks using `__typename`

To tell Kimera which concrete type you want it to mock, you need to define a __typename meta field in your scenario.

const executableSchema = getExecutableSchema({
  typeDefs: schema,
  mockProvidersFn: (context) => ({
    scenario: {
      ships: [{ __typename: 'Starship' }, { __typename: 'Rocket' }],
      assets: [{ __typename: 'Starship' }, { __typename: 'Rocket' }, {}],
    },
  }),
});

note

Customize mocks using __typename#

Customize mocks using `__typename`