enhance(ResolveFieldValue): add async collection language #1066
Conversation
✅ Deploy Preview for graphql-spec-draft ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
@graphql/tsc -- I think this could count as an editorial change? It is currently implemented within graphql-js on main as part of the incremental delivery alpha/beta, has not been released... |
and some baseline collection language for comparison extracted from graphql#742 Authored-by: Rob Richard <rob@1stdibs.com>
Done, thanks! |
| flow. In addition, an implementation for collections may leverage asynchronous | ||
| iterators or asynchronous generators provided by many programming languages. |
There was a problem hiding this comment.
This would introduce the term "generator" and "iterator" to the spec, which isn't currently used. Let's keep the language simpler:
| flow. In addition, an implementation for collections may leverage asynchronous | |
| iterators or asynchronous generators provided by many programming languages. | |
| flow. In addition, for fields that have a return type that is a List type, each | |
| value in a collection of values returned by {resolver} may itself be | |
| asynchronous. |
There was a problem hiding this comment.
What about something very similar:
| flow. In addition, an implementation for collections may leverage asynchronous | |
| iterators or asynchronous generators provided by many programming languages. | |
| flow. In addition, for fields that have a return type that is a List type, each | |
| value in a collection of values returned by {resolver} may be | |
| retrieved asynchronously. |
This just avoids saying that the value itself is asynchronous, which I think you might mean to just be a more concise version of the above?
@robrichard may have input, this was extracted from #742
and some baseline collection language for comparison
extracted from #742