v0.2.0 about react-rxjs HOT 4 CLOSED

That's a nice discussion. On distinctShareReplay, I also wondered the same thing. Is it really needed if people can use connectObservable or connectFactoryObservable and get the "distinctShareReplay"ed observable that can be used to build other streams?

What's the use case where distinctShareReplay would be useful for a consumer?

If we expose it, I like shareLatest name, but I wouldn't make it apply distinctUntilChanged. From a consumer PoV the useful bit of shareLatest would be on how it shares the source stream - distinctUntilChanged can be added if needed.

from react-rxjs.

I've been thinking a lot about this and I think that I've finally realized what the issue is here. I will try to summarize it:

• distinctShareReplay should not be exposed. Further more, the internal one should not have the distinctUntilChanged behavior baked in it.
• connectObservable and connectFactoryObservable should not take the compareFn option at all.
• The internal react-enhancer can (and should) apply a distinctUntilChanged(Object.is) in order to prevent unnecessary React.setState calls.
• An enhancer that we could name shareLatest could (and I think that should) be exposed. Its behavior would be the equivalent of:

const shareLatest = <T>() => (
  source$: Observable<T>,
): Observable<T> =>
  source$.pipe(
    multicast(() => new ReplaySubject<T>(1)),
    refCount(),
  )

I'm working on that... I can't wait to get that done!

FTR: @voliva it was your comment that helped me see the light! Thanks a lot! Also, how do you feel about this stuff ^^

from react-rxjs.

Go for it, sounds good 🎉. The distinct part makes sense to only apply in the react hook.

from react-rxjs.

I'm closing this because I'm really happy with the latest alpha release. I will create separate issues for the other stuff. Also, I will try to make those issues more organized (and less chaotic).

from react-rxjs.