It's so frustrating to explain rxjs pitfalls to the manager.

To avoid the diamond problems and glitches caused by combineLatest and debounceTime(0), I decided to use single stream with nested reactivity.

Then the manager asked me to use withLatestFrom instead of combineLatest.

Sure withLatestFrom makes sense to the original author, when the original author is able to remember the reactive graph and put proper dependencies to combineLasted/withLatestFrom accordingly, but anyone else who touches the component later needs to retrace the reactive graph to avoid the glitch. Sometimes it's just impossible when many dependencies are derived from combineLatest+debounceTime(0). When no one is trained to code reactively, I don't expect people to know where to put a dependency. After many trials and errors, the only way to avoid the diamond problem is to use nested reactivity where child streams are created within root stream each time root stream emits.

The mentioned manager put all sorts of side effects in observable chains. The manager keeps saying the stream is too large when their subscription functions (sometimes nested) are way worse with litered mutations everywhere. Anything in observable can be traced by go to definition but tracing side effects usually requires global searches.

Recently, he put startWith to the end of a synced stream to fix a bug where button would collapse when there is no content (initial null emission). Rather than fixing the default height, he thinks using startWith(defaultLabel) is a good idea. Of course, he doesn't know that a synced stream should only emit 1 value on new subscription and that extra emitted value will cause rxjs glich down the pipe.

I hate corporate jobs