I've seen components rewritten using observables to be sometimes a full 1/4 of the original size.

The biggest thing for me is the realization of the "source of truth". With observables, if they are set up correctly, you can see the exact bits of information that some resultant stream are dependent upon. Operations then can have a single action because all of those sources can be muxed together rather than having several calls throughout a component to doSomeAction().

First: This is not an attack on you

I have such an issue with this response because it just seems like “you’re holding it wrong” a la the iPhone “scandal” where apple attempted to blame an engineering flaw on its users

I would imagine most people’s use case (mine certainly is) for RxJS boils down to “call a JSON API and receive a response”. That shouldn’t be a hard problem

Imagine if someone complained about the complexity of Git and the answer was to “write your own DVCS”

The entire point of abstractions is that I don’t need to understand what’s going on underneath them

1) You skipped points one and two in my comment: a) Learn the foundations of RxJS. b) Understand how to extend RxJS by creating operators. Which lead to c) read RxJS’s code to understand how it implements operators to better learn to implement your own.

2) RxJS is not Git. It’s a library designed to be extended by users. To use RxJS you need to write code with it. Git is not exclusively a library and doesn’t require you to write you own extensions to use it day to day.

As a casual Git user you wouldn’t get much out of implementing a DVCS but you would benefit from learning to host your own repo instead of relying on GitHub.

If someone was struggling to use Git I’d tell them to learn the foundations, practice them, and then to host their own repos to continue learning.

The same basic track I recommended for RxJS.

A big moment for RxJS users is when they realize that they need an operator or observable that doesn’t exist. It’s really fun to write your own.

I think the most bad rep for RxJS comes from using it when it is not needed.

Parent comment said:

> But the problems they solve are also unintuitive.

Do you consider calling a JSON API unintuitive or complex? If not, then you may be using the wrong tool. If you need nothing else, you are perfectly fine using a promise.

If you need to await extra requests, transform them, and react to other events then you need RxJS. For a simple call, you do not.

> I would imagine most people’s use case (mine certainly is) for RxJS boils down to “call a JSON API and receive a response”. That shouldn’t be a hard problem

Do you consider the following code hard to understand or are you are making requests in a more complex way?

``` this.network.get('<url>').subscribe(response => <do whatever you want here>) ```

Even if we agree to disagree that the above code snippet is hard to understand, you can just convert it to a promise:

``` const response = await lastValueFrom(this.network.get('<url>')) ```

No, that call isn’t difficult. What is more difficult are examples given on things like Angular University, where there are pipe, subscribe, catchError, among others, in a single call chain. It’s not obvious to me at all what the order of execution is in this call chain for instance:

    http$
        .pipe(
            map(res =>     res['payload']),
            catchError(err =>     {
                console.log('caught mapping error and rethrowing', err);
                return throwError(err);
            }),
            finalize(() =>     console.log("first finalize() block executed")),
            catchError(err =>     {
                console.log('caught rethrown error, providing fallback value');
                return of([]);
            }),
             finalize(() => console.log("second finalize() block executed"))
    )
        .subscribe(
            res => console.log('HTTP response', res),
            err =>     console.log('HTTP Error', err),
            () =>     console.log('HTTP request completed.')
    );

Once you see the output it begins to finally make sense but intuitive it is not

If you look at a snippet of code in a language you don’t understand you wouldn’t call it intuitive. Once you learn the language you might see that what what was unintuitive before is intuitive and idiomatic now.

Once you learn how RxJS works examples like the one anbove anre intuitive.

Angular 2’s most egregious crime is that their tutorials try to make it (and RxJS) seem “simple”. They aren’t. They’re powerful.

Very much agree, and even for the more complicated use cases Saga's are much cleaner and I would argue easier to understand. Article below goes through a few of the differences.

https://shift.infinite.red/redux-observable-epics-vs-redux-s...

I worked for 4 years intensively with RXJS. I love the concept, but it quickly becomes a mess in readability when trying to merge different data sources.

Can you link/show an example?

I am doing that all the time and all it takes, is withLatestFrom or combineLatest