RxJS share vs shareReplay differences

Question

There seems to be an odd discrepancy with how share and shareReplay (with refcount:true) unsubscribe.

Consider the following (can paste into rxviz.com):

const { interval } = Rx;
const { take,  shareReplay, share, timeoutWith, startWith , finalize} = RxOperators;

const shareReplay$ = interval(2000).pipe(
  finalize(() => console.log('[finalize] Called shareReplay$')), 
  take(1), 
  shareReplay({refcount:true, bufferSize: 0}));

shareReplay$.pipe(
  timeoutWith(1000, shareReplay$.pipe(startWith('X'))), 
)



const share$ = interval(2000).pipe(
  finalize(() => console.log('[finalize] Called on share$')),
  take(1), 
  share());

share$.pipe(
  timeoutWith(1000, share$.pipe(startWith('X'))), 
)

The output from streamReplay$ will be -X-0- while the output from shareStream$ will be -X--0. It appears as though share unsubscribes from the source before timeoutWith can re-subscribe, while shareReplay manages to keep the shared subscription around for long enough for it to be re-used.

I want to use this to add a local timeout on an RPC (while keeping the call open), and any re-subscribe would be disastrous, so want to avoid the risk one of these behaviors is a mistake and gets changed in the future.

I could use race(), and merge the rpc call with a delayed startsWith (so they both subscribe at the same time) but it would be more code and operators.

EDIT: One possible solution is to merge two subscriptions one to a shared request and one to a delayed stream that takes until the shared stream emits:

merge(share$, of('still working...').pipe( delay(1000), takeUntil(share$)));

This way the shated stream is subscribed to at the same time, so there is no "grey area" when one operator unsubscribes as a child subscribes. (Will turn this into an answer unless someone comes up with a better suggestion) or can explain the intentions/differences between share and shareReplay

Answer 1

Timing Guarantees

Javascript's runtime doesn't come with baked in timing guarantees of any sort. In a single threaded environment, that makes sense (and you can start to do a bit better with web workers and such). If something compute-heavy happens, everything covered in that timing window just waits. Mostly it happens in the expected order though.

Regardless,

const hello = (name: string) => () => console.log(`Hello ${name}`);

setTimeout(hello("first"), 2000);
setTimeout(hello("second"), 2000);

In Node, V8, or SpiderMonkey you do preserve the order here. But what about this?

const hello = (name: string) => () => console.log(`Hello ${name}`);

setTimeout(hello("first"), 1);
setTimeout(hello("second"), 0);

Here you would assume second always comes first because it's supposed to happen a millisecond earlier. If you run this using SpiderMonkey, the order depends on how busy the event loop is. They bucket shorter timeouts since a 0ms timeout takes about 8ms on average anyway.

Always make asynchronous dependencies explicit

In JavaScript, it's best practice to never ever make any timing dependencies implicit.

In the code below, we can reasonably know that that data will not be undefined when we call data.value. This implicitly relies on asynchronous interleaving:

let data;
setTimeout(() => {data = {value: 5};}, 1000);
setTimeout(() => console.log(data.value), 2000);

We really should make this dependency explicit. Either by checking if data is undefined or by restructuring our calls

setTimeout(() => {
  const data = {value: 5};

  setTimeout(() => console.log(data.value), 1000);
}, 1000);

Share vs ShareReplay

want to avoid the risk one of these behaviors is a mistake and gets changed in the future.

The real risk here isn't even in how the library implements the difference. It's a language-level risk as well. You're depending on asynchronous interleaving either way. You run the risk of having a bug that only appears once in a blue moon and can't be easily re-created/tested etc.

---

The share operator has a ShareConfig (source)

export interface ShareConfig<T> {
  connector?: () => SubjectLike<T>;
  resetOnError?: boolean | ((error: any) => Observable<any>);
  resetOnComplete?: boolean | (() => Observable<any>);
  resetOnRefCountZero?: boolean | (() => Observable<any>);
}

If you use vanilla shareReplay(1) or replay({resetOnRefCountZero: false}) then you aren't relying on how events are ordered in the JS Event Loop.