Why the heck is this rxjs so hard to understand.

Async chans event parties are not for everyone.

;)

Hang in there, it takes time.

Learn marble syntax and then try composing the marbles. It'll get a lot clearer.

Because it’s an entire new concept for you. Classical backgrounds are often C or Lisp, so neither of those learned at basic level come close to rx

@uyouthe
Lisp, at least in later dialects tracks pretty handily with the RFP concepts. Macros are a really easily way to define compositional operators.

But very few really delve into macro composition, so there is that 😆

https://wiki.c2.com/?LispMacro

@SortOfTested I’m talking about basics. You learn what macro is, you dive in, you build your career and then, when you have enough experience to understand them, you rediscover macros.

Just think it is a promise that can be resolved multiple times from the same operation.

.then(FN) is .map(FN) where FN returns just a value
.then(pfn) is .flatMap(pfn) where pfn returns a promise/observable

That is as far as I can stretch the simil

.merge "resolves" values from 2 observables into one in the order they appear in the sources observables

.zip is like calling Promise.all each time both sources have new values ( works like array zip, the events are emitted at the pace of the slower observable)

From is like resolve

Subscribe is meant for side effects

.filter discards resolved values just like in an array

And so on

You can get a nice intuition when you learn to use the operators separately.

Currently trying to understand marble diagrams as @SortOfTested has suggested.

@galileopy
Few notes:

- the dot operators were removed from rxjs a bit ago for modularity reasons
- flatMap in rxjs is expressed as mergeMap, switchMap, concatMap, etc depending on behavior
- from is mean to be used with generators/things that produce events
- of(val)/of(...series) is for creating Observables from known values
- zip is pairwise in rxjs, not operators
- merge/mergeAll/combineAll/forkJoin are top level in rxjs
- rxjs' filter is lazy, array's monad functions are eager
- Observables resolve once and only once per next without replay/publish behavior

@SortOfTested Thanks! For some reason I still think in terms of Bacon.js, I gave a shitty explanation. But the gist is the same for me. The hardest part to understand is not how to use the operators, but what does an observable represent.

Is a data structure that allows you to encapsulate sequential events with operators describe how to transform the inner value and functions to set rules on how 2 or more observables interact.

Once you get that, the operators are easy to learn. IMHO.

@galileopy
Yep, just making sure when he went googling he found the dictionary he needed 😊

The only distinction I tend to make is that an observable is a function that allows you to attach a producer to a subscriber. It's a useful distinction because you can you point out that observable never carries any state, which in turn makes explaining hot and cold easier because it allows you to define it as an aspect of the producer.

When I hire people on, part of the 2 weeks on boarding is a crash course in FP as we use RX heavily, as well as Scala and F#. If anyone is actually interested during the training we cover the monad laws using observable.

@SortOfTested I'd be interested in that course 👀, do you have any public courses?

@galileopy
Nope, it's internal only. The secret to having secret sauce is to keep it secret. 😉

@SortOfTested recruit me then 😉