Splits synchronous from asynchronous operator chains, based on concurrency.
It is a helper for custom operators with implementation dependent on concurrency.
import {concurrencyFork} from'iter-ops';
functionmyOperator<T>() { returnsource=>concurrencyFork({ onSync(i: Iterable<T>) { // "i" and "source" are the same object here, with different type cast
// return a synchronous operator chain }, onAsync(i: AsyncIterable<T>) { // "i" and "source" are the same object here, with different type cast
// return an asynchronous operator chain } })(source); }
Returning from the callback any of the following is the same as not having the handler at all,
which will just forward to the source iterable (so it will have no effect):
return i
return source
return null
return undefined (or do nothing)
This operator is not strictly necessary, since a custom operator can simply check the type directly:
However, use of operator concurrencyFork offers the following advantages:
It handles errors that a custom operator may throw during pipeline construction,
and turns them into iteration-time errors, so operator catchError can handle them.
It will safely redirect to the source, should your custom operator not provide a handler,
or when the handler doesn't return anything.
It offers a more strict types control, plus generally cleaner coding style.
Splits synchronous from asynchronous operator chains, based on concurrency.
It is a helper for custom operators with implementation dependent on concurrency.
Returning from the callback any of the following is the same as not having the handler at all, which will just forward to the source iterable (so it will have no effect):
return i
return source
return null
return undefined
(or do nothing)This operator is not strictly necessary, since a custom operator can simply check the type directly:
However, use of operator
concurrencyFork
offers the following advantages: