You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had this idea that is actually possible to allow returning AsyncIterators from resolvers without waiting for it to land in graphql-js. The only downside would be that typings in user code could be wrong (Promise<T> | T expected instead of AsyncIterator<T>) 😅. However, that could be easily solved with patch-package.
The idea is to wrap each field resolver (as in #94). The wrapper will then check whether the returned value is a plain value, a Promise, or an AsyncIterator. In the case of plain value and Promise it will just forward it. In case of an AsyncIterator it will (1) get the first value and resolve a Promise with it and (2) register that the live query returns an AsyncIterator for a given query path and then forwards patches to the client once new data is returned from the AsyncIterator.
The text was updated successfully, but these errors were encountered:
I had this idea that is actually possible to allow returning AsyncIterators from resolvers without waiting for it to land in graphql-js. The only downside would be that typings in user code could be wrong (
Promise<T> | T
expected instead ofAsyncIterator<T>
) 😅. However, that could be easily solved with patch-package.The idea is to wrap each field resolver (as in #94). The wrapper will then check whether the returned value is a plain value, a Promise, or an AsyncIterator. In the case of plain value and Promise it will just forward it. In case of an AsyncIterator it will (1) get the first value and resolve a Promise with it and (2) register that the live query returns an AsyncIterator for a given query path and then forwards patches to the client once new data is returned from the AsyncIterator.
The text was updated successfully, but these errors were encountered: