-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make iterators AsyncIterable, Closes #89 #102
Make iterators AsyncIterable, Closes #89 #102
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (barring the minor optimisation above)
Note that this logic achieves the same effect over in LDflex https://github.com/LDflex/LDflex-Comunica/blob/f01ece6fa8cee720061efd5ddd23ed82921555e4/src/ComunicaEngine.ts#L161-L215.
I will leave @RubenVerborgh to merge as I do not have rights to make a subsequent npm release.
@RubenVerborgh Could you have a look at this one? Will certainly make many comunica users very happy :-) |
@rubensworks So I first did f60cecc to minimize listener re-attachment within a single |
0948d9c
to
43cedf1
Compare
I also had a So I guess we'll have to choose between either errors to always be explicitly forwarded (but them sometimes getting lost on partial consumption), or errors never getting lost, but them sometimes being unhandled errors. After writing this, I just realized that we could also implement our own unhandled exception approach. If we notice (somehow) that the AsyncIterable is not consumed anymore, but we have a pending error, that we throw an unhandled exception. This might give us the best of both worlds. |
I like the approach, except I'm not sure how to implement it with the ECMAScript |
We may be able to do something by registering the created |
Ooof yes. Or perhaps for now at a comment that we recommend adding an error listener to the iterator if you don't plan on fully consuming it (since you can't detach a Or we could keep a list per iterator of the ESAsyncIterator instances created (or even allow only one), and then destroy on the iterator also destroys all of them. Actually, destroy on the iterator might just work because it would also delete listeners. |
@RubenVerborgh At last, I found some time to look into finalizing the unit tests and documenting the error events edge-case. |
That is quite amazing, thanks. So we good to go? Anything I should still do? (I see a review is pending, just checking if you need specific things.) |
@RubenVerborgh Should be feature-complete AFAICS, so it should be ready to be merged if you agree :-) |
@@ -611,7 +616,7 @@ export class AsyncIterator<T> extends EventEmitter implements AsyncIterable<T> { | |||
currentResolve = currentReject = pendingError = null; | |||
removeListeners(); | |||
} | |||
else if (pendingError !== null) { | |||
else if (pendingError === null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦 obvs I put that in on purpose to check your tests
I was so pleased that my code turned out to be the one in the end, only the see the dreadful |
Merged! :-) @RubenVerborgh, before you release, it might make sense to include #105 as well. |
@rubensworks @RubenVerborgh brilliant!!! |
@RubenVerborgh Could you publish a new release? I'd like to include it in the next major release of Comunica, which I intend to release soon. |
@rubensworks Published v3.9.0! Thanks for your patience and continued support. |
While this will likely come at the cost of lower performance compared to plain data-events, we should add this for use cases where code readability is preferred over performance.