Closed benlesh closed 6 months ago
cc @domfarolino @domenic
Previously: https://github.com/WICG/observable/issues/52
Your first example kind of scares me as written - the right thing is to cancel the fetch
, and I wouldn't want to add a convenience method which makes the wrong thing much easier than the right thing. So I would definitely want to explore avenues for making abort-on-unsubscribe patterns easier, if we were to add this.
One wild idea for that: the mapper (in this and potentially other callback-taking methods) could take as its third argument a { signal }
, created by and internal to the operator, so that you could do
input.on('input')
.switchMap(async (e, idx, { signal }) => {
const response = await fetch(`/search?q={e.target.value}`, { signal });
/* ... */
})
.subscribe((results) => { /* ... */ })
and have the signal
automatically abort when the observable returned by the callback is unsubscribed. (Similar idea suggested at https://github.com/tc39/proposal-iterator-helpers/issues/162#issuecomment-968929171, though I think it's more relevant to switchMap
than map
etc because unsubscription of the inner thing can happen prior to unsubscription of the outer thing.)
Previously: https://github.com/WICG/observable/issues/52
Oops. 😬
I'll move this over to the other pre-existing thread.
switchMap
was mentioned at TPAC as being an API of interest. It's a method that is especially useful for composing events in the browser because of its inherent cancellation. If API bloat is a concern, I would gladly removetoArray()
,some()
,find()
et al, as those are minimally useful with observables.Use cases are things like:
Use Case: Lookahead Search
In the below scenario, the result of the
fetch
would simply be ignored.It's plausible that we could provide a signal along with the
switchMap
callback, as well. In fact, I'd almost encourage that, as it might make fetch more useful. But I think we'd want to discuss the ergonomics there, and that could be debated and added later. (For example, we might want to have it automatically swallow DOMExceptions namedAbortError
?)Use Case: Changing Connections
Below, every time a URL is changed in an URL input, if it's a valid URL, it will disconnect from the previous web socket and connect to a new one.