Support Async Iterable Protocol #20
Labels
Comments
|
Please include some body text in the issue. For example, what it would look like to support this? |
|
I meant it would be cool to have support for Async Iterables in place of input argument. |
|
Yeah, we could do this, but not worth doing it until we can use it natively internally, which means targeting Node.js 10, which we cannot do until next year. |
|
This can now be done. PR welcome :) |
huntharo
added a commit
to pwrdrvr/p-map
that referenced
this issue
Aug 25, 2021
- Expand capabilities to handle both async and sync iterables - There is a problem in the original functionality around the `stop-on-error` test that needs to be resolved - The test has a bug in that neither p-map nor the test mapper function, which is provided for that specific test and is not the common version, await the calling of the delay() function for item 2 - This means that item 2 will only ever return a Promise, never a value - When this is fixed to await the function call, it causes the returned results to change from `[1, 3]` to `[1, 3, 2]` - Fixing this test makes it clear that the `concurrency setup` loop does not wait for mappers, so the only way to make this test fail would be to have enough items that eventually the initial iteration could not reach the last items in the test array before the 100 ms delay on the exception expires - With `concurrency = 1` this test behaves as expected since there are not unlimited unawaited promises created - Let me know your thoughts on how to resolve this as it becomes more apparent with the behavior changes needed for asyncIterable (where the concurrency setup iteration of asyncIterable has to be awaited to prevent inifinte runners from being created) - The test, in the state it's in in this PR, does not actually demonstrate that stop on error works as intended
2 tasks
huntharo
added a commit
to pwrdrvr/p-map
that referenced
this issue
Sep 12, 2021
- Expand capabilities to handle both async and sync iterables - There is a problem in the original functionality around the `stop-on-error` test that needs to be resolved - The test has a bug in that neither p-map nor the test mapper function, which is provided for that specific test and is not the common version, await the calling of the delay() function for item 2 - This means that item 2 will only ever return a Promise, never a value - When this is fixed to await the function call, it causes the returned results to change from `[1, 3]` to `[1, 3, 2]` - Fixing this test makes it clear that the `concurrency setup` loop does not wait for mappers, so the only way to make this test fail would be to have enough items that eventually the initial iteration could not reach the last items in the test array before the 100 ms delay on the exception expires - With `concurrency = 1` this test behaves as expected since there are not unlimited unawaited promises created - Let me know your thoughts on how to resolve this as it becomes more apparent with the behavior changes needed for asyncIterable (where the concurrency setup iteration of asyncIterable has to be awaited to prevent inifinte runners from being created) - The test, in the state it's in in this PR, does not actually demonstrate that stop on error works as intended
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: