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
At my workplace, I've done a lot with observables, and have used a specific pattern fairly extensively that helps with errors and completion events from observables subscribed to by other observables. I'll start with a problematic example, using the API that our internal observables use (mostly zen-observable like):
// let's have some observables that fetch data from some API,// in this case some usage limits for "basic" and "advanced"// (also, ideally these would be ref-counted, but we'll ignore that)constbasicLimit=newObservable<number>((subscriber)=>{// -snip-})constadvancedLimit=newObservable<number>((subscriber)=>{// -snip-})// now let's make an observable that returns data from bothconstlimits=newObservable<{basic: number,advanced: number}>((subscriber)=>{letbasic: number|null=nullletadvanced: number|null=nullfunctionnext(){if(basic!==null&&advanced!==null){subscriber.next({ basic, advanced })}}constonBasic=basicLimit.subscribe((value)=>{basic=valuenext()})constonAdvanced=advancedLimit.subscribe((value)=>{advanced=valuenext()})return()=>{onBasic.unsubscribe()onAdvanced.unsubscribe()}})
You may have already noticed an issue - if basicLimit or advancedLimit error or complete early, that isn't at all indicated to the observer of limits. We're just using the next callback. You can of course fix this, but it's tedious especially when working with a lot of nested ref-counted observables:
// you have to do this for every single subscriptionconstsubscription=obs.subscribe({next: (x)=>{/* ... */},error: (err)=>subscriber.error(err),complete: ()=>subscriber.complete(),})
My solution was to add a new way of subscribing, called lift:
// desugars to the above code blockconstsubscription=obs.lift(subscriber,(x)=>{/* ... */})
This is just sugar. It subscribes in a way where error and complete are automatically passed to subscriber, but next is handled by the callback in the second argument. You can also pass an observer object where you can override the behavior of either next, error, or complete, but any you don't override are passed to subscriber.
I called it lift because its intended idea is that it "lifts" up inner errors or completions up automatically - there might even be many inner lifts. If you use this religiously in your library, errors from deeply subscribed observables get passed all the way up to consumers without a lot a boilerplate being needed. I personally found it really helpful.
Since it's just sugar, it's understandable if this is out-of-scope or otherwise not desirable for this proposal. I would like to at least make it known that this was helpful for me and others, and that keeping this bit of friction in mind while working on the proposal would be appreciated.
The text was updated successfully, but these errors were encountered:
At my workplace, I've done a lot with observables, and have used a specific pattern fairly extensively that helps with errors and completion events from observables subscribed to by other observables. I'll start with a problematic example, using the API that our internal observables use (mostly zen-observable like):
You may have already noticed an issue - if
basicLimit
oradvancedLimit
error or complete early, that isn't at all indicated to the observer oflimits
. We're just using thenext
callback. You can of course fix this, but it's tedious especially when working with a lot of nested ref-counted observables:My solution was to add a new way of subscribing, called
lift
:This is just sugar. It subscribes in a way where
error
andcomplete
are automatically passed tosubscriber
, butnext
is handled by the callback in the second argument. You can also pass an observer object where you can override the behavior of eithernext
,error
, orcomplete
, but any you don't override are passed tosubscriber
.I called it
lift
because its intended idea is that it "lifts" up inner errors or completions up automatically - there might even be many innerlifts
. If you use this religiously in your library, errors from deeply subscribed observables get passed all the way up to consumers without a lot a boilerplate being needed. I personally found it really helpful.Since it's just sugar, it's understandable if this is out-of-scope or otherwise not desirable for this proposal. I would like to at least make it known that this was helpful for me and others, and that keeping this bit of friction in mind while working on the proposal would be appreciated.
The text was updated successfully, but these errors were encountered: