Comment by dmitriid | Hacker News Reader

Comment by dmitriid | Hacker News Reader

There’s one thing I find weird. There are very few, if any, resources that go beyond the simple “set up an observable, run through at most two transformations and at most two subscriptions”.

That’s where the vast majority of tutorials, blog posts and presentations end. And then you’re stuck with trying to implement a simple login flow, or reading data from a file, and... nothing really works, everything is overengineered and impossible to debug and trace.

In his book the author of RxJava openly admits it took him several months to grok reactive streams. And he was taught by the author of reactive extensions for dotnet.

Programming with reactive stuff is essentially async programming (never easy) where your data is handled, transformed in async blackboxes (hardly any implementation of Rx has a good way to observe, debug and trace data through them), and is delivered to sinks/subscribers in async manner.

And yet basically everything you find on the topic will cheerfully tell you how easy this stuff is, and present you with a toy code that fits on a screen.

I've been using Observables pretty exclusively for almost two years now. What I have now is a cookbook of use cases that I refer back to by looking at what I did in previous projects. That's not to say there's no original thought in new code that I write, just that sometimes the nontrivial cases have escaped my memory. Some examples:

* How do you end the observable's subscription when any of X, Y or Z happen (and at least one of these is a timer)?

* How do you emit N network requests in series, without nesting subscriptions? (ideally you won't need to, but not all APIs are well behaved)

* How do you transform a node-like stream to an observable?

This is just from last week, and some I'm able to do from scratch better than others.

TESTING them is challenging as well. There are non-obvious failures when you use the typical unit testing patterns (a testing framework will report that function was/wasn't called and you're not sure why, because per the test setup that shouldn't be what happened). Almost two years in and I have no idea what the marbles mean, but soon I'll start trying to grok them

But there's no way I see how I can do my job without them. The applications I work on take updates from 1) keyboard 2) mouse 3) direct websocket subscriptions 4) indirect websocket subscriptions 5) xhr calls 6) other messaging patterns that aren't as common.

So I'm at the point where I can easily tell you the differences between switchMap, concatMap, and mergeMap (of which flatMap is an alias), easily pull out filter, map, combineLatest, tap, etc. Sometimes when I'm in the weeds it does help to think that they're just functions, but at no point would I dare tell anyone that this stuff is easy. It's easily the hardest thing I've learned since I started my current job.

I was learning rx.js for new project in angular 2 and learnt two things:

1. Observables are best when used as Behaviours from classical FRP formulation by C. Elliot. It's a value that's changing over time, and you should only compose it (map, combineLatest, switchMap, merge ...) and push subscriptions to the edges - for example asyncPipe in angular. That makes writing "reactive" (as in Excel cells) code a breeze. Reacting to changes as events (like button click) should be handled with care, with first/takeWhile and so on. But simple cases are still nice looking.

2. Observables are bad as framework for coordination problems. Complex flows of events can easy get out of hand, and suddenly you are passing objects with values and some state through streams or nest switchMaps instead of piping them. Often such code could be written with async/await and would be ten times cleaner. So any code which dealt with changes as events and had branches/state because of that, we rewrote with async/await. Examples are POST/PUT/DELETE requests with logic around authentication/authorization/timeouts. You could model that as stream but when you access closure from outer switchMap it's starts being unwieldy.

Along with what you've described, which covers a huge swath of the problems I found with observables is this:

https://twitter.com/git_commit_m/status/1014915134949429248

There is a pretty huge documentation problem with observables.

Reply on news.ycombinator.com