3 ms·

RX looks good on paper, but boy, is it a nightmare in any non-trivial project. Is this stream hot or cold? Will it fire the request every time I subscribe, or

RX looks good on paper, but boy, is it a nightmare in any non-trivial project. 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?

mercutio2 8y ago
I’m in general agreement that Rx is, in practice, not an improvement over most other approaches. 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...
- aaaaaaaaaab 8y ago
  Not sure about the cancellation token bit. Last time I’ve used Rx my experience was that you could never know whether disposing a subscription would cancel the underlying process or not. Many times I wanted the opposite behaviour to what the original author had implemented. Not to mention cases where I wanted to keep a process alive as long as there’s at least one subscriber, but cancel it when there’s none left... Maybe things have changed since then (2016-2017) with regards to cancellation; but I’m off the Rx train for a while.
xab9 8y ago
I think it's a nightmare for trivial projects too: it's like building a star destroyer for a todo app, because, you know, one day that todo app may end up being the death star. Who knows. Gotta be ready for that. 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.

mercutio2 8y ago

I’m in general agreement that Rx is, in practice, not an improvement over most other approaches. 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...

aaaaaaaaaab 8y ago
Not sure about the cancellation token bit. Last time I’ve used Rx my experience was that you could never know whether disposing a subscription would cancel the underlying process or not. Many times I wanted the opposite behaviour to what the original author had implemented. Not to mention cases where I wanted to keep a process alive as long as there’s at least one subscriber, but cancel it when there’s none left... Maybe things have changed since then (2016-2017) with regards to cancellation; but I’m off the Rx train for a while.

xab9 8y ago

I think it's a nightmare for trivial projects too: it's like building a star destroyer for a todo app, because, you know, one day that todo app may end up being the death star. Who knows. Gotta be ready for that. 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.