Вложенные встроенные фрагменты в graphql

Учитывая тип объединения graphql

union SearchResult = Human | Droid | Starship

и следующий запрос graphql:

{
  search(text: "an") {
    ... on Human {
      ... on SearchResult {
        ... on Droid {
          appearsIn
        }
      }
    }
  }
}

Почему в graphql синтаксически правильно перейти от встроенного фрагмента «подтипа» (Human) к встроенному фрагменту «супертипа» (SearchResult) и обратно к другому встроенному фрагменту «подтипа» (Droid)? Есть ли для этого какие-нибудь варианты использования?

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


graphql union-types
person Koga    schedule 25.09.2018    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Без этого правила именованные и встроенные фрагменты могут вести себя одинаково, и это может иметь смысл, если у вас есть более задействованные фрагменты «получения общих битов» для типов интерфейса или объединения. Если вы разделите запрос таким образом:

fragment SearchResultBits on SearchResult {
  ...on Droid { appearsIn }
  # could have parts for other union choices too
}
query DoSearch($text: String!) {
  search(text: $text) { ... SearchResultBits }
}

Тогда по вашему запросу очень разумно повторно использовать (названный) SearchResultBits

query FromQuestion {
  search(text: "an") {
    ... on Human {
      name
      ... SearchResultBits
    }
    # or return nothing for non-humans
  }
}

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

person David Maze    schedule 25.09.2018