Apollo-link: 为 apollo-link-http 添加超时选项

是的，如果需要，应该可以包装获取并超时请求。

如果人们依赖于非超时版本，我们需要提供一个选择退出这种行为。

我们可以将 abortConttoller 用于取消本身。

想法？ @hwillson

@dshook @JoviDeCroock我认为您真正想要的是超时链接。 大概您想限制调用者可能必须等待响应的时间量，并且如果在那段时间内没有响应返回，则只返回错误，对吗？ 如果是这样，将其放入 http 链接本身不会使其可与其他链接组合。 您的查询也可能正在等待或停留在任何其他链接中，它不一定是重试链接。 它可能在 apollo-link-retry、apollo-link-serialize、apollo-link-queue 等中。为了保证特定的超时，您真正需要的是位于堆栈最顶部的超时链接，以及时间输出花费时间过长的请求（取消它们并返回错误），无论请求在堆栈中的哪个位置挂起。

正如您所指出的，在超时后取消请求并不能保证服务器没有看到它，所以要小心不是幂等的突变。

PS：好像有人已经做了一个超时链接（apollo-link-timeout）。 不幸的是，它不是很灵活，它破坏了链接抽象（例如，进入获取链接以中止请求并返回可以从任何地方调用的 timeoutRef），它似乎没有经过很好的测试，有一些问题默认值（15 秒超时而不是无超时）并且不是很灵活（例如超时不能依赖于查询变量），但它可能会为您解决问题。

我同意这会很棒，但我知道 Fetch API 没有超时机制，所以我不确定 Fetch 是在后台使用还是仅使用常规承诺。

apollo-link-timeout不像@helfer提到的那样灵活。 我认为timeout价值应该是动态的。 我们如何以最佳方式处理超时？ 🤣

_示例查询_

<Query
  query={FETCH_QUERY}
  context={{ timeout: 5000 }}
>...</Query>

只想在这里跟进，目前可接受的解决方案是什么？ 它代表了一个真实世界的场景，似乎是一个公平的超时请求。

您好 Apollo 团队，在 apollo graphql 客户端实现中默认支持超时选项非常有用。 由于这与客户端请求紧密耦合，因此请求超时是公平的。
您是否已经在计划此功能？ 您目前对此要求的立场是什么？

期待您的回音。

谢谢
阿拉文

此功能是否仍在进行中？ 如果它可用，我们真的可以从超时选项中受益。