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
But sometimes I end up using switchMap() or concatMap() instead of mergeMap(). I think it doesn't matter which xxxMap() operator gets used after the first() operator and it always makes me wonder if it would be easier to reason about the code if there was an operator which just hides that.
someObservable$.pipe(firstMap(()=>{// ...}))
If you think it's a useful addition, I would be happy to provide a PR for it.
The text was updated successfully, but these errors were encountered:
Hmm. I'm not sure. If someone unfamiliar with firstMap were to encounter it in source, would they assume that if flattens rather than effects a higher-order observable - i.e. that it's not ...pipe(first(), map(value => /* map value to an ObservableInput */)? What if the mapped value was an array (or an iterable)? Reading it, it wouldn't be obvious that the resultant observable would emit the arrays elements rather than the array itself.
Hi Nicholas,
what do you think about adding a
firstMap()
operator? I often use a pattern like this in my code:But sometimes I end up using
switchMap()
orconcatMap()
instead ofmergeMap()
. I think it doesn't matter whichxxxMap()
operator gets used after thefirst()
operator and it always makes me wonder if it would be easier to reason about the code if there was an operator which just hides that.If you think it's a useful addition, I would be happy to provide a PR for it.
The text was updated successfully, but these errors were encountered: