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
This behavior is important for reasoning inductively and for composability. For example, say I have a list of search terms to expand to search results and then I want to concatenate all the results. The natural way to write this is:
You would expect an empty list of search terms to produce an empty list of results, however with current forkJoin behavior you need to handle that with a special case:
I believe that in every use case where the length of the input to forkJoin is unknown at compile time, it's simpler for the consuming code if forkJoin returns empty output on empty input, so the consuming code doesn't need to treat empty input as a special case; it can iterate over the output value the same way regardless. This is an example of the null object pattern, where for example it's better for an operation which produces a list to produce an empty list in case there is no output rather than a null value which must be handled specially.
In the original issue #2816 it was argued that "Forkjoin doesn't consider any other case except all sources emits value, so empty array is also short-curcuit to completion immediately." However when there are no sources, it is logically true that "every source emits a value", and it is not true that "some source doesn't emit a value" (see the behavior of Array.every and Array.some for example), so one would therefore expect forkJoin to emit a value.
This reasoning also applies to forkJoin({}), which should emit an empty object {}.
The text was updated successfully, but these errors were encountered:
I'm reopening #2816 because the response wasn't satisfactory.
RxJS version: 6.5.2
Code to reproduce:
Expected behavior:
Console logs
[]
Actual behavior:
Nothing is logged.
Additional information:
Compare the behavior of
Promise.all
:This behavior is important for reasoning inductively and for composability. For example, say I have a list of search terms to expand to search results and then I want to concatenate all the results. The natural way to write this is:
You would expect an empty list of search terms to produce an empty list of results, however with current
forkJoin
behavior you need to handle that with a special case:I believe that in every use case where the length of the input to
forkJoin
is unknown at compile time, it's simpler for the consuming code ifforkJoin
returns empty output on empty input, so the consuming code doesn't need to treat empty input as a special case; it can iterate over the output value the same way regardless. This is an example of the null object pattern, where for example it's better for an operation which produces a list to produce an empty list in case there is no output rather than anull
value which must be handled specially.In the original issue #2816 it was argued that "Forkjoin doesn't consider any other case except all sources emits value, so empty array is also short-curcuit to completion immediately." However when there are no sources, it is logically true that "every source emits a value", and it is not true that "some source doesn't emit a value" (see the behavior of
Array.every
andArray.some
for example), so one would therefore expect forkJoin to emit a value.This reasoning also applies to
forkJoin({})
, which should emit an empty object{}
.The text was updated successfully, but these errors were encountered: