Вложенные встроенные фрагменты в graphql - PullRequest
Новая
       7

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

0 голосов
/ 25 сентября 2018

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

union SearchResult = Human | Droid | Starship

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

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

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

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

1 Ответ

0 голосов
/ 26 сентября 2018

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

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
  }
}

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

...