-
Notifications
You must be signed in to change notification settings - Fork 66
Description
Motivation
I really like flatMap.
I also really like parMapN on tuples.
I therefore suspect I'd really love a parFlatMapN
currently:
val helloF: F[String] = (someF, someOtherF).parMapN((a,b) => "hello")
val worldFF: F[F[String]] = (someF, someOtherF).parMapN((a,b) => "world".pure[F])
val worldF: F[String] = stringFF.flattenwhat I'd love to have:
val helloF: F[String] = (someF, someOtherF).parMapN((a,b) =>"hello")
val worldF: F[String] = (someF, someOtherF).parFlatMapN((a,b) => "world".pure[F])
Is there another way to accomplish this than parFlatMapN
Yep, but I think it'd be quite nifty to have it.
The argument against is I suspect that you can just do .parMapN(..).flatten - it's not that much more code to look at - but wouldn't the same argument apply to most flatMap operations (you could just do .map(...).flatten)?
It came up in a $DAYJOB example that looked not-really-but-kind-of-sort-of like this (using cats-effects IO here for the sake of the example)
def ioEnrichOrAbsent(thing: Thing): IO[Option[Enriched]] = ???
val enriched: IO[List[Enriched]] = (ioAPICall, ioSomeOtherAPICall).parMapN {
(a,b) => {
val listOfThings: List[Thing] = getListToTraverse(a,b)
listOfThings
.parTraverse(ioEnrichOrAbsent)
.map(_.flatten)
}
}.flatten... which, yes, in this simplified could be refactored this to be more legible in a myriad ways. But, I still think parFlatMapN would have made it more obvious than a flatten (especially because I'm already using .flatten for the List[Option[A]]` inside the parMapN, so there's a bit of mental gymnastics people have to do to realize which thing is being flattened and why)