Используйте @skip для «пустых» полей, используя graphql
Учитывая следующий GQL
query getMembers {
repository(owner: "nasa", name: "cumulus") {
mentionableUsers(first: 100) {
nodes {
login
organization(login: "nasa") {
login
}
}
}
}
}
(Запрос к GitHub v4 GraphQL)
значение для login под organization равно "nasa" или null
Я пытаюсь выяснить, можно ли использовать @skip для входа в систему/организации, чтобы отображались только участники репо, которые являются членами организации НАСА. Я считаю, что для этого конкретного запроса вы можете сделать это по-другому, но это всего лишь пример.
Как бы вы использовали @skip/@include с нелогическим значением. Документации по этому поводу минимум. Хотя я мог бы отфильтровать ответ JSON в своем клиентском приложении, было бы более эффективно получать меньше данных, отправляемых по сети, а затем анализировать их в моем приложении.
Играя в GraphQLi, я получал ошибки, пытаясь использовать это разными способами - может быть, это возможно только в том случае, если поле само возвращает логическое значение?
например, я не мог сделать login @skip(if login==null). Я также попытался установить значение null в разделе переменных и сослаться на него в запросе, но ни один из вариантов, которые я пробовал, не работает.
Что бы я действительно хотел сделать, так это не включать родителя, если дочернее поле имеет какое-то значение. например, если login=null, то не включайте упомянутого пользователя. В упомянутом пользователе нет опции поля поиска. Из того, что я прочитал, я предполагаю, что единственный способ сделать это - изменить API, чтобы добавить поле поиска или фильтра для упоминаний пользователей, иначе мне нужно было бы сделать это с моим клиентом?
Ответы 1
Пара точек.
Обе директивы @skip и @include обеспечивают одинаковую функциональность — позволяя клиенту произвольно выбирать, следует ли включать поле в запрос.
Допустим, у нас есть запрос вида:
query ($skipBar: Boolean!) {
foo
bar @skip(if: $skipBar)
}
Если я установлю skipBar на true, я фактически просто отправлю этот запрос:
query {
foo
}
Если я установлю его на false, я фактически просто отправлю этот запрос:
query {
foo
bar
}
Как клиент, моя логика должна определить значение, которое нужно присвоить skipBar, но я мог бы так же легко использовать ту же логику, чтобы решить, отправлять ли один из этих двух запросов. Другими словами, как и переменные и фрагменты, @skip и @include — это просто удобный способ сохранить СУХИЕ вещи на стороне клиента. Их нельзя использовать для фильтрации результата, возвращаемого сервером.
Синтаксис GraphQL не поддерживает выражения (или любые ссылки на части ответа). Кроме того, @skip и @include принимают только один аргумент (if), и этому аргументу должен передается логическое значение — либо как переменная, либо как буквальное значение. Даже если бы вы могли каким-то образом передать выражение аргументу if, директивы определяют, будет ли поле включено в запрос, и точка. Таким образом, если пропущенное поле является частью возвращаемого списка (например, списка узлов), оно будет отсутствовать в узле каждый, когда оно будет пропущено.
Итак, есть ли обходной путь?
Не совсем :( Как вы уже догадались, если API GitHub не предоставляет способ фильтрации поля, вы как клиент мало что можете сделать — вам придется применять логику фильтрации на стороне клиента.
На самом деле здесь нет компромисса, поскольку у вас нет выбора, но да. На самом деле это ничем не отличается от того, если вы используете REST — фильтрация возвращаемых данных — это то, что должно обрабатываться кодом сервера, поэтому, если сервер не реализует это, клиент ничего не может с этим поделать.
Возможность произвольной фильтрации результатов была бы удобной, но я полагаю, что это также было бы несовместимо с другими функциями, которые может реализовать API, такими как нумерация страниц.
Таким образом, компромисс заключается в том, что я могу получить больше в одном запросе, но я рискую получить много данных, которые могут занять больше времени для загрузки, а затем для обработки? Кажется, что с GQL вы ограничены выбором дизайнеров API.