Желательно, чтобы отдельный элемент в списке допускал значение NULL из-за способа обработки ошибок GraphQL и недопустимости NULL . В частности, в отношении списков:
Если тип List является оболочкой для типа, отличного от Null, и один из элементов этого списка разрешается в null, тогда весь список должен разрешаться в null. Если тип List также заключен в ненулевое значение, ошибка поля продолжает распространяться вверх.
Итак, мы можем представить сценарий, в котором ошибка возникает при разрешении какого-либо поля на отдельном Vote пункт. Поле, в котором возникает ошибка, не допускает значения NULL, поэтому сам элемент становится нулевым. Если тип родительского поля - [Vote] или [Vote]!, то на этом доллар останавливается, и как часть списка возвращается null (с ошибкой в массиве errors, объясняющей, что пошло не так). Однако, если у нас есть [Vote!], то весь список будет обнулен. Если у нас есть [Vote!]!, то список не может быть нулевым, и ошибка будет продолжать всплывать, пока не попадет в поле, допускающее значение NULL.
Таким образом, если вы широко используете ненулевые значения, один ошибка в глубине дерева может привести к тому, что все значение data в ответе будет нулевым. Хотя в некоторых случаях это может быть нормально, часто лучше иметь возможность визуализировать хотя бы частичный результат, а не ничего вообще. По этой же причине, возможно, рекомендуется избегать ненулевых значений в целом, за исключением случаев, когда объект не может использоваться без определенного поля (например, поля id).
Вне обработки ошибок, Есть ли сценарий ios, в котором имеет смысл возвращать список, содержащий нули? Примером может быть операция, которая ищет список объектов на основе предоставленного массива идентификаторов. В этом случае может быть желательно, чтобы результирующий массив соответствовал длине (и порядку) массива идентификаторов, чтобы можно было использовать ноль, чтобы указать, что соответствующий объект не найден.