Есть ли подходящий шаблон для смешивания разных типов в GraphQLUnionType?

У меня проблема, когда мне нужно создать запрос, который будет возвращать различные возможные типы для узла, я также использую свойство __typename, чтобы определить, какой из них я получил.

Причина, по которой я не использую EnumType, заключается в том, что разные подтипы могут сильно отличаться.

Некоторые из них пусты (например, не обладают никакими свойствами).

Это вызывает проблему, потому что я не могу создать UnionType.

Я попытался использовать ScalarTypes для этих пустых определений, но для Union я могу использовать только ObjectTypes, для которых требуется определение «полей».

Например, вот несколько определений классов, которые я использовал со стороны службы.

classA {
token: string
}

classB {
}

classC {
}
type returnType = classA | classB | classC

Для каждого из них я определяю тип

typeA = GraphQLObjectType ofType classA with fields => {token}
typeB = GraphQLObjectType ofType classB with fields => undefined
typeC = GraphQLObjectType ofType classC with fields => undefined

Проблема возникает при построении типа объединения для запроса

new GraphQLUnionType({
      types: [typeA, typeB, typeC]
}) 

Я хотел бы знать, как правильно справиться с этим сценарием, от клиента я просто хотел бы сделать что-то вроде

query {
   myquery {
     mode: __typename
     ... typeA {
         token
     }
  }

Я попытался ввести имя как свойство, и это сработало, потому что оно есть у каждого типа, но это избыточно.

Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Что такое Apollo Client и зачем он нужен?
Что такое Apollo Client и зачем он нужен?
Apollo Client - это полнофункциональный клиент GraphQL для JavaScript-приложений, который упрощает получение, управление и обновление данных в...
0
0
69
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Я бы, вероятно, решил обойти это, добавив какое-нибудь поле к типам объектов, которые в противном случае были бы пустыми.

"""Objects of this type don't have properties."""
type classB {
  """Just a placeholder value; always null."""
  _placeholder: Bool
}

Как только у вас есть это, он может нормально участвовать в типе объединения, и вы можете запросить его __typename как обычно. Вам не обязательно упоминать это в запросе, если вы этого не хотите.

query {
  myquery {
    __typename
    ... on classA {
      token
    }
    # No need for a fragment ...on classB
  }
}

В конце концов, это то, что я сделал, спасибо за ваш вклад

OHHH 20.12.2018 21:30

Другие вопросы по теме