Observable pipe arguments that are "falsy" are skipped

[benlesh]

So often I find myself doing this pattern when I want to conditionally apply an operator:

source$.pipe(
   map(fn),
   someBoolean ? concatMap(fn) : identity,
   someOtherBoolean ? switchMap(fn) : identity
)

Or I end up rolling a helper so I can do this:

source$.pipe(
  map(fn),
  ...helper(
     someBoolean && concatMap(fn),
     someOtherBoolean &&  switchMap(fn)
  )
)

It would be great if this: source$.pipe(operator1, null, operator2) was the same as source$.pipe(operator1, operator2).

So I would propose a new feature (which would be non-breaking) where any "falsy" value that is passed to Observable.prototype.pipe is ignored/skipped. Which would make the above:

source$.pipe(
     map(fn),
     someBoolean && concatMap(fn),
     someOtherBoolean &&  switchMap(fn)
)

[Bjeaurn]

Seems like a great idea to me. A false/falsy value now in a pipe is not allowed due to the required type signature (when using TypeScript). Do you see this signature change might be considered a breaking change in the API?

[benlesh]

It shouldn't be a breaking signature change... however, TypeScript might exclude us from doing this entirely, because typing it would be pretty difficult without introducing a TON of overloads.

[benlesh]

One thing I just thought of though... Typing this would be nearly impossible. 😿 We already have 9-10 overloads for pipe just to handle what it handles. This would require nearly n^n overloads to work with the same number of arguments, I think.

cc @cartant.

[benlesh]

I made that lazy above, but the semantics around something like that would have to be very well defined. Like... if it switched from true to false we'd end up needing to switch between the two branches, which would tear things down and set them up again. Maybe that's a little too much functionality. We're practically in an "observable of operators" territory with that one.

Requires a lot of thought to be sure.

[MattSPalmer]

Is there an advantage to lazy? Disadvantage seems to me to be that it's very hard to reason about things when the operator resolves based on some (presumably) external changing value.

Whereas if you forgo lazy, you just get:

const when = <T, R>(
  condition: boolean,
  opWhenTrue: OperatorFunction<T, R>,
  opWhenFalse: OperatorFunction<T, R> = identity,
): OperatorFunction<T, R> => (
  condition ? opWhenTrue : opWhenFalse
);

Am I missing something (typing maybe?) that means this wouldn't work?

[benlesh]

Advantage to lazy is it's more flexible. The disadvantage, like you said, is it becomes harder to reason about.

Given any situation: () => T is always more flexible than just T. Because you can close over a variable with () => T to get the same behavior as just T.

[MattSPalmer]

Definitely, I'm with you there. It does seem like the bufferWhen case, and we haven't defined buffer yet.

The thing I'd be most wary of with lazy-by-default is adding another way for an observable's behavior to depend on a value whose changes are outside a reactive context.

But if it accepts boolean | () => boolean I guess that'd work for everyone.

[Bjeaurn]

I actually like that idea, it might even be more readable... although we couldn't use if obviously, and iif is unfortunately used in RxJS already. Maybe like when or something?

source$.pipe(
     map(fn),
     when(() => someBoolean, concatMap(fn)),
     when(() => someOtherBoolean, switchMap(fn))
)

I think this is a very elegant solution!

[Shastel]

I believe that it should be added to the concat as well.

[benlesh]

Some "falsy" values are valid observable inputs. '' for example.

[Shastel]

Ah, never thought about it

[benlesh]

Core team meeting: This might be better as an educational thing about how to use ternaries to accomplish this. Maybe we even consider an operator that just returns identity to help readability? Still up for debate. The typings complexity around the original proposal is way too high to implement, and the proposed when operator above, didn't really make things more readable.