If by unintuitive you mean “Can I look at it without training and know what’s going on.” But the problems they solve are also unintuitive. Only, those issues can be buried under a tangle of nested callbacks that look correct, intuitively.
Once you take the time to really (and I mean really) understand RxJS it’s incredible. Write your own Observables. Write your own operators. Learn what the built in operators are really doing (subscriptions, etc) reimplement them yourself.
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().
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
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.
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>')) ```
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 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.
https://shift.infinite.red/redux-observable-epics-vs-redux-s...
I am doing that all the time and all it takes, is withLatestFrom or combineLatest