Is this stream hot or cold? Will it fire the request every time I subscribe, or at most once? On which thread is this stream delivered on? UI thread? Let’s be safe and dispatch it to the UI thread! Oh, now my UI flickers because this other stream is producing this event one cycle too early... Let’s add one millisec delay here and hope it fixes the issue (yuck.). How do I cancel this stuff?
Another thing: debugging RX. God, it hurts. Like Alice in wonderland.
I worked with an rx guru on my last project and while the code was beautiful, huge and complex, showing a load indicator or handling simple ajax errors, doing persistent navigation states (and hoping that the back button would not break the application) were just omitted altogether. It was an engineering marvel, and a usability trainwreck with around a six megabyte initial payload and no lazy loading at all.
But:
> How do I cancel this stuff
Everyone I’ve ever heard describe Reactive pipelines describes built-in, standardized cancel behavior as the raison d'être for Rx!
It’s super common to encounter a one off someone thought would never get called more than once in a while, which actually piles up a huge serial queue (or worse, creates dozens of threads while concurrently contending for a resource that’s serialized in a less than perfectly transparent way).
So in those cases, knowing all your interfaces explicitly include a cancellation token is pretty appealing.
Of course, in practice, lot’s of people don’t bother to wire together the cancellation bits, so you’re left thinking you can cancel things but it doesn’t actually do anything. So maybe that’s what you meant...
Maybe things have changed since then (2016-2017) with regards to cancellation; but I’m off the Rx train for a while.