
RxFiddle: Visualize your Observables - pbadenski
https://rxfiddle.net/#type=editor&code=Y29uc3QgcGVvcGxlID0gWwogIHtuYW1lOiAnU3VlJywgYWdlOjI1fSwKICB7bmFtZTogJ0pvZScsIGFnZTogMzB9LAogIHtuYW1lOiAnRnJhbmsnLCBhZ2U6IDI1fSwKICB7bmFtZTogJ1NhcmFoJywgYWdlOiAzNX0KXTsKY29uc3QgZXhhbXBsZSA9IFJ4Lk9ic2VydmFibGUuZnJvbShwZW9wbGUpCiAgLnppcChSeC5PYnNlcnZhYmxlLmludGVydmFsKDEwMDApKQogIC5tYXAoKFtwZXJzb25dKSA9PiBwZXJzb24pCiAgLmdyb3VwQnkocGVyc29uID0+IHBlcnNvbi5hZ2UpCiAgLmZsYXRNYXAoZ3JvdXAgPT4gZ3JvdXAucmVkdWNlKChhY2MsIGN1cnIpID0+IFsuLi5hY2MsIGN1cnJdLCBbXSkpCmNvbnN0IHN1YnNjcmliZSA9IGV4YW1wbGUuc3Vic2NyaWJlKHZhbCA9PiBjb25zb2xlLmxvZyh2YWwpKTs=
======
krat0sprakhar
I've found RxViz: [http://rxviz.com/](http://rxviz.com/) to be super useful as
well!

------
jondwillis
Very cool. I’ll have to try this out the next time I have trouble with a
RxSwift observable chain.

One of the nicer sides of using Rx is that converting from one implementation
to the next is usually fairly trivial.

~~~
jbchoo
Yes indeed cool. Find this useful as an Angular dev.

------
iamleppert
Honestly, I don't get it. What's the benefit here to having this library as
opposed to just calling those functions directly when some data in object
changes?

I guess you could argue if you had tons of data, but I wouldn't be using a
frontend application to implement a distributed queue processing and messaging
system...

~~~
slackingoff2017
RX is a hilarious pattern IMO. 90% of the usage I've seen would be simpler and
less code just doing things the old fashioned way.

The vast majority of observer pattern use cases are solved a lot more clearly
by using async

~~~
romanovcode
Yeah but the pattern emerged before `async/await` was javascript standard so
people kind of sticked to it.

I know some not bad js developers who use RX a lot and have no idea about
`async/await` existence, I even had to explain to couple of them how
`async/await` works and what is "imperative code". No joke.

~~~
WorldMaker
Why not both? It doesn't have to be either/or: async/await is a great monad
for cases where you need a simple imperative flow. Rx and the Observable
pattern are great for cases where you have more complex data flows with
complex needs like backpressure support (throttling and buffering), and
complex time management.

Each has very different strengths, and it's very easy to work with both
together.

    
    
        const someStream = Rx.fromPromise(myAsyncAwaitFunction())
    
    
        const arrayINeed = await myRxObservable.toArray().toPromise()

~~~
slackingoff2017
let val = await Thing();

Vs

Observable.of(thing).subsribe((res)=>{call back}

For all(most) cases where you only need to hear back once

~~~
WorldMaker
If you only need to "hear back once", then yes, Observables are probably
overkill.

But again, it's a false dichotomy, and your second example isn't much
different from what await essentially rewrites to:

    
    
       Thing().then(val => /* call back */)
    

The benefit to async/await is that the runtime does the rewriting to Promise
callbacks for you. But you can use both and get that advantage for both. Rx
has supported converting to/from Promises since the beginning. Working with
both is easy.

    
    
        let val = await observableOfJustOneThingINeed
          .take(1) // I just need one, I don't care if there are more
          .toPromise()
    

You don't have to manually subscribe, you can use a Promise and await it.

~~~
slackingoff2017
What RX gives you is a smooth flow to the last callback. Async is admittedly
less flexible but the only way I know of to trigger asynchronous flow without
a callback.

I worked in the C# world for a while and I'm still in envy of how clear and
powerful good async support is.

~~~
WorldMaker
Under the hood, async/await is using callbacks into a finite state machine. JS
Promise and C# Task<T> (which are very similar in design, for obvious reasons)
are both still driving the operations in an async/await function, the JS
runtime, C# compiler (or TS compiler), is doing the heavy lifting of
converting imperative _looking_ code into a finite state machine for
Promise/Task callbacks.

You can't avoid callbacks in an asynchronous flow. async/await is just a
conversion between imperative _looking_ code and a callback structure. It's a
great win for developers that we've built such conversion tools (thanks to
work on monads in languages like Haskell and OCaml).

Rx is for higher-order asynchronous streams where you have multiple events
over time. It doesn't have the beauty of async/await because it's a much more
complicated abstraction than the basic monad of Promise/Task. If you have a
stream of events over time you can use Rx and if you have just one Promise at
a time you can use Promise/Task and thus async/await. (The difference between
I want to know every click of this button and I want to know just the next
click of this button.) Most applications are a little bit of column A and a
little bit of column B, and you don't have to pick one or the other, you can
use both side-by-side.

~~~
slackingoff2017
Async avoids callbacks by restoring your calling context under the hood just
like the compiler does for normal function calls and callbacks. It just does
it in a way thats clearer IMO

