by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 10:21
    changhoi opened #5735
  • Sep 17 15:37
    fendorio edited #5734
  • Sep 17 12:50
    fendorio opened #5734
  • Sep 17 07:16
    Vincent-Alibert commented #5690
  • Sep 17 07:15
    Vincent-Alibert commented #5690
  • Sep 17 07:15
    Vincent-Alibert commented #5690
  • Sep 17 06:07
    benlesh edited #5729
  • Sep 17 06:07
    benlesh ready_for_review #5729
  • Sep 17 06:06
    benlesh edited #5729
  • Sep 17 05:54
    benlesh commented #5729
  • Sep 17 05:53
    benlesh synchronize #5729
  • Sep 17 05:39
    benlesh synchronize #5729
  • Sep 17 05:10
    benlesh synchronize #5729
  • Sep 17 02:26
    benlesh synchronize #5729
  • Sep 17 00:28
    benlesh synchronize #5729
  • Sep 16 23:22
    benlesh synchronize #5729
  • Sep 16 19:44
    alexsherekin commented #5732
  • Sep 16 18:18
    benlesh synchronize #5729
  • Sep 16 12:37
    josepot commented #5733
  • Sep 16 09:17
    josepot commented #5733
connor-odoherty
@connor-odoherty
Is there a "best practice"?
Chaos
@molysama
@connor-odoherty 3/5000
No difference
@connor-odoherty return from(...).pipe( ..., catchError(error => {}), use catchError pls
Dorus
@Dorus
@connor-odoherty What's observableFrom? Try from, it should unpack the promise.
@molysama that catch is on the promise right? So it's valid method. The Rx variant would be catchError but since we already have a promise, might as well fully use that.
oh wait, in the last example he used catch on the observable, that's wrong yes.
But still, it should work either way. I thik possibly the issue above is the promise did not have a clear type?
Dorus
@Dorus

@connor-odoherty To answer the questions.

  1. You can use then and catch like normal on promises (not on observable)
  2. Promises are always hot. Ofc if you do () => new Promises() it's different, so mergeMap(()=> functionThatMakesPromises()) would run a new promise each time.
  3. yes mergeMap and other operators are the normal way to chain observables, in fact, all opperatrors convert observable from one to another, that's the difintion of an operator in RxJs.
    You can even return a promise to mergeMap and it will unpack it, but when you work with RxJs it would be preferable to use Observable everywhere and not use promises. So wrapping promises in functions that use defer or from is recommanded.

On the topic of defer, that's another operator to make poorly behaving observable cold again, or to make promises cold. defer(() => functionThatMakesPromises())

connor-odoherty
@connor-odoherty

Thank you both! Meant to put catchError instead of catch on that last example, but this really clears a ton up, thanks for the clarification. Theres a bunch of RxJS code I'm trying to clean up and upgrade, so it is much appreciated. Just have one more question regarding mergeMap...

(and in case you encounter this in the future, observableFrom and observableOf are aliases for from and of that the rxjs-tslint 5-to-6 migration introduces)

Dorus
@Dorus
@connor-odoherty I missed the question you had. Did you ask it?
Henri Maurer
@hmaurer
Hello! I've a question on Rx :) Say you have a stream of events (call it events$), and you want to trigger some effect on some events, and stop those effects on some other events. e.g. the event START might start an effect which sends PING events every 1s, and the event STOP would stop this. I was thinking that something like events$.pipe(filter(e => e === "START"), switchMap(e => events$.pipe(takeUntil(... might do it, but (a) I am not sure how to complete this snippet, and (b) using events$ in the switchMap would create a second subscription to the observable and I'm not sure that will lead to the desired behaviour in all cases
Jorrit
@jorrit-wehelp
@hmaurer a) takeUntil(stopEvents$), where stopEvents$ is filtererd events$
b) depends on the inner workings of events$, should probably be some share/multicast so you can subscribe multiple times
@hmaurer but usually you also want to 'restart' , often use a pattern like events$.pipe(switchMap(e => e === "START" ? ping$ : never()) (but just psuedo code, e.g. depends if there are more states besides start/stop)
Henri Maurer
@hmaurer
@jorrit-wehelp it seems tricky though, because I only want stopEvents emitted after the START event ?
and I want to make sure that no weird situations happen, e.g. PING events being emitted after the STOP event because there's a lag (for whatever reason) between the two subscriptions to events$?
but perhaps the multicasting you suggest fixes that?
Jorrit
@jorrit-wehelp
@hmaurer true that it can be tricky, avoiding the duplicate subscriptions usually makes it easier to reason about. But yeah, multicast and your takeUnit would usually work, if the subscriptions are called synchronously. But I prefer my single switchMap example
if you replace never with empty, it would only do 1 start/stop
should also have used NEVER const :)
Henri Maurer
@hmaurer
@jorrit-wehelp is there a guarantee that with multicast all subscriptions will be called synchronously?
and re your switchMap example, that doesn't seem to include the "STOP" event I mentioned, right?
Jorrit
@jorrit-wehelp
@hmaurer no, depends on the inner workings/implementation of events$ (it's usually the case, but you can do stuff with observeOn/subscribeOn to change that)
Henri Maurer
@hmaurer
Perhaps I didn't probably explain that. My intent is that it cancels the inner observable on every START event (switchMap does that), but also on a STOP event
ah!
Jorrit
@jorrit-wehelp
@hmaurer yeah, there I assume only two states, so I don't test for stop
anything else just 'stops' by unsubscribing and switching to NEVER
Henri Maurer
@hmaurer
What I am trying to implement is basically effects for a state machine. I want to be able to say "if the machine gets event A in state 1, start this effect. Then keep running it til it receives event B in state 1"
(effects being observables)
but I want to be precise as to what the STOP event is
Jorrit
@jorrit-wehelp
yep, switchMap is the way to go with that
Henri Maurer
@hmaurer
I'll check out observeOn; thanks!
I still don't get how you can do it with switchMap alone though; perhaps I am being slow
Jorrit
@jorrit-wehelp
I'd probably extract that logic, e.g. let toggle$ = events$.pipe(filter(e => ["START", "STOP"].includes(e)), map(e => e === "START")); then just deail with a boolean Observable
Henri Maurer
@hmaurer
ooh I see what you mean
thank you! :)
and what's your NEVER const?
Jorrit
@jorrit-wehelp
It's an observable the never emits a value
I this cause I use it as a dummy/placeholder in the 'STOP' state
Henri Maurer
@hmaurer
ah, thanks!
Joel Day
@joelday
I'm not sure how to do this: I want to map an observable so that rather than what switchMap does, where it just ignores the current observable that hasn't completed yet, it skips elements until the current observable completes.
Derek
@derekkite
@joelday exhsustMap
Joel Day
@joelday
@derekkite What can I do if I want to still get a trailing element (the most recently 'skipped') once the current one completes?
Joel Day
@joelday
basically debouncing
Joel Day
@joelday
nm, found an implementation. thanks!
Pawel Badenski
@pbadenski
hope someone can help.. fighting a nasty subscriber leak...
in the gist it's mentioning unsubscribing in a few places.. but we don't see that in our system - ie subscribers keep active for ever... and after I added finalize operator I never see it getting called
pretty lost here...