`takeUntil` vs `extendableEvent.waitUntil`

[bakkot]

takeUntil taking an Observable is kind of handy, and matches RxJS, but it's inconsistent with the web platform's existing waitUntil method, which takes a Promise.

I would hope they could be made consistent, either by having takeUntil only accept a Promise (and using the first method to get a Promise for the next value), or by having both methods accept either a Promise or an Observable. (RxJS's takeUntil can actually take either, since it will implicitly convert a Promise into an Observable when passed as an argument here.)

Personally I like the first of these options better - I'm not a big fan of overloads - but it would be an inconsistency with RxJS.

[domenic]

I feel like these are totally separate.

extendableEvent.waitUntil() is about preventing the default processing of an event (e.g., a fetch handler or a PWA installation dialog) until some future time. It's pretty event-specific. The key word there is wait, and it's "temporal".

takeUntil() is about taking some values from the sequence, until some condition is met. The keyword there is take, and it's "spatial" (i.e., it's about the sequence in the observable, not delaying the post-error/complete processing steps).

Both share the word "until", but I'm not sure that's a big deal. If there's a risk of people getting confused here, maybe a name like takeBefore() would be better. But I think there is some good precedent for takeUntil...

[bakkot]

takeUntil() is about taking some values from the sequence, until some condition is met. The keyword there is take, and it's "spatial" (i.e., it's about the sequence in the observable, not delaying the post-error/complete processing steps).

Is it? That sounds like you're describing takeWhile, which really is "until some condition [on the values in the observable] is met".

takeUntil (if I have understood it correctly) is "take values until some future event occurs", by comparison to waitUntil, which is "wait until some future event occurs". That's pretty much exactly analogous, isn't it?

[domenic]

I meant "condition [as embodied by some other observable's next value]".

That's pretty much exactly analogous, isn't it?

Although you can sort of say that both have to do with future events (the "until") part, what I was trying to point out is that the wait part and the take part are extremely different.

• Taking values from an observable, to create a new observable; vs.
• Waiting to shut down the service worker until some promise is settled

(Note: above I stated it's about delaying default processing. But I just checked and that's wrong. It's actually about service worker lifetime.)

In particular, although ExtendableEvent specified somewhat generically, in practice it's basically the "keep my service worker alive" API. Note that it's only exposed to service worker contexts. Perhaps if we had a time machine we'd rename waitUntil() to extendLifetimeUntil()...

[bakkot]

Yeah, I agree that the wait and take parts are quite different. But the until parts does feel pretty similar: "this service worker should live until some other thing comes to pass" and "this Observable should keep firing until some other thing comes to pass" are different things, but there's no clear reason why the "this thing comes to pass" part would be indicated by a Promise fulfilling in one case and an Observable firing in the other case.

[benlesh]

FWIW, in RxJS, takeUntil will accept anything that Observable.from would accept. So a promise would totally work, and that's a fairly common usage.