> I believe what you are calling a "concurrent" iteration is one of the use cases for Observables, so would be on the RxJS side (the "parent" project). Ah, got

> I believe what you are calling a "concurrent" iteration is one of the use cases for Observables, so would be on the RxJS side (the "parent" project). Ah, got it. I don't think I quite understood the relationship between this project and RxJS. I did know about RxJS's observables, yes. I do sort of hint at the relationship between concurrent iterables and the observables [1], but I tried to make concurrent iterables a bit more specialized to what you'd normally use an iterable for. > Interesting. I'll read further on what you are doing there. Seems possibly similar to Lenses/Prisms in FP, with different rules. I think I've heard of lenses (but not prisms), but don't think I ever actually learned what they are. Would be curious if you find a connection between those and my reducers :) > Good point. So far I've not found a JS approach to optionals I'm entirely happy with. I've had some suggest I should give Effect [0] a deeper look, but given I'm mostly happy with RxJS the bulk of Effect doesn't appeal to me. The dual of an Option being an iterator with 0 or 1 values is something I've seen before and something to keep in mind. Yeah, I liked representing optionals as iterables because you get a lot of functionality for "free" [2] [1] https://lfi.dev/docs/concepts/concurrent-iterable#:~:text=A%20concur%20iterable%20is%20effectively%20a%20cold%20push%2Dbased%20observable%20backed%20by%20some%20asynchronous%20operations https://lfi.dev/docs/concepts/concurrent-iterable#:~:text=A%.... [2] https://lfi.dev/docs/concepts/optional#why-use-iterables-to-represent-optionals https://lfi.dev/docs/concepts/optional#why-use-iterables-to-...