3 ms·
Ah, the typical presentation of what it is and not why it's useful. It's just that kind of library that solves a lot of problems, which people don't even know
by eurekin 11y ago
Ah, the typical presentation of what it is and not why it's useful.
It's just that kind of library that solves a lot of problems, which people don't even know of (or do not want to). I have very little experience with Rx, but still I found some really useful applications for it:
1. Jumping between threads back and forth. This is a typical requirement of a UI Toolkit (Java Swing, Android). I don't remember the exact details, but some special combinators (subscribeOnEdt) were provided out of the box by the library (was using rxScala then). You just connected button to some action, which result was displayed in a text field. With rxScala for Swing it was an extra function call. In plain JDK it's an extreme pain (SwingWorker, SwingUtilities.invokeLater and custom Runnables or threads etc.)
2. Edge case handling in abstractions. Let's say you want to implement a real time moving average of exactly 3 points, but discarding 10 first results. In Rx it is something of a "Hello World" level of complexity. The same thing, in plain Java, which also handles the edge cases correctly is almost always implemented buggy.
3. Event bookkeeping. If you happen to use push model a lot, a funny thing occurs. In case of UI applications some people call it a "glitch". In electronic engineering this is a race condition (https://en.wikipedia.org/wiki/Race_condition https://en.wikipedia.org/wiki/Race_condition). It's a very fundamental problem, which is solved in rx implementation. The merge operator takes care, that the events fired are traversing the dependency graph in a topological order. That way, it is way harder to create that bug (not impossible though).
4. Error handling by default. This is also very very useful. A typical programmer in Java implements handling for all happy cases, few error conditions and most often than not, misses a lot of other error cases. "Who would notice? Besides, exception handling in Java is really ugly." So yeah, they don't write it. With RX the error condition handling is always present, by the means of termination message. Every combinator has a clearly defined semantics for handling those onComplete events. It's just a matter of reifing exceptions and defining stream for error events. You could do it in Java of course, but the amount of boilerplate which is killed by handling this in rx is very impressive.