GraphQL允许定义具有可空项的数组的技术原因是什么？

在GraphQL中，您可以定义一个数组，其中任何/每个成员都可以为null，即

[Vote]

或

[Vote]。这就要求我们总是使用一个内部感叹号（
[Vote！]！
）

我想不出一个有效的
[Vote]用例

declaration accepts: | null | []   | [null] | [{foo: 'BAR'}]
------------------------------------------------------------------------
[Vote!]!             | no   | yes  | no     | yes
[Vote]!              | no   | yes  | yes    | yes
[Vote!]              | yes  | yes  | no     | yes
[Vote]               | yes  | yes  | yes    | yes

什么样的设计会有这样的要求？这是为了优雅的错误处理吗？
最好让列表中的单个项可以为空，因为。特别是关于名单：

如果列表类型包装了非Null类型，并且该列表的一个元素解析为Null，那么整个列表必须解析为Null。如果列表类型也包装为非Null，则字段错误将继续向上传播

因此，我们可以想象这样一种场景，在解析单个
投票
项上的某个字段时发生错误。发生错误的字段不可为null，因此项本身被设置为null。如果父字段的类型是
[Vote]
或
[Vote]
，然后责任就停在那里，返回一个null作为列表的一部分（在
errors
数组中有一个错误来解释出错的原因）。但是，如果我们有
[Vote！]
，则整个列表将变为空。如果我们有
[投票则列表不能为空，错误将继续冒泡，直到它遇到可为空的字段

这样，如果您广泛使用非空值，那么树深处的单个错误可能会导致响应中的整个
数据
值为空。虽然在某些情况下这可能很好，但通常最好至少能够渲染部分结果，而不是什么都不渲染。这也是为什么一般情况下避免非空值是一种不错的做法，除非对象没有特定字段（如
id
字段）就无法使用

在错误处理之外，是否存在返回包含空值的列表的情况？例如，一个基于提供的ID数组查找对象列表的操作。在这种情况下，可能希望结果数组与ID数组的长度（和顺序）匹配，因此可以使用null来表示未找到匹配的对象。
我从未处理过在出现错误时需要返回部分响应的情况。我想我被教导，如果有错误，那么应该大声失败。这样错误就不会被忽略。对于输入顺序指示结果较旧的用例，这听起来（对于基于网络的API）是一个可怕的设计。每个结果都应该有一个信封，用于将请求参数与结果配对。但我确信它确实存在于野外。允许部分响应并不意味着你不做错误处理。如果图形的一部分由于错误而返回null，并且该错误是可恢复的，那么您仍然可以重试该请求，但您至少可以为用户呈现一些内容并减少TTI。更好的是，您可以只请求图形中仍缺失的部分，而不是重试整个原始请求。如果错误无法恢复，最终用户只需不呈现任何内容或一些一般错误消息是否是最佳体验？要将其放在透视图中，请想象一个获取呈现此页面所需的所有数据的查询。你真的想因为解决右边工作列表上的薪资字段出现问题而“大声失败”吗？我只是想提供一些背景知识，说明GraphQL为什么会这样做，不管是好是坏。我并不想暗示这是唯一或必然是最好的错误处理方法，但我意识到这听起来是这样的：）显然，一切都“取决于产品”。但从历史上看，Facebook是产品，Relay是框架。因此，您必须在该上下文中查看“GraphQL为什么以这种方式设计”。