9 ms·
Am I the only who finds RxJS to be really unintuitive? I never had any issues in the past with futures/promises libraries, but for some reason I can never reme
by mupuff1234 3y ago
Am I the only who finds RxJS to be really unintuitive?
I never had any issues in the past with futures/promises libraries, but for some reason I can never remember how to use RxJS.
- throw1234651234 3y agoI feel like most of the RxJS functionality doesn't have a real use case. At the end of the day, you are doing an async call, something axios handles just fine. I did a bunch of presentations on RxJS, so I understand it fairly well, but I have never used it past basic API calls "irl".
- codethief 3y ago> I feel like most of the RxJS functionality doesn't have a real use case. I disagree. I have implemented several use cases using RxJS which would have otherwise been significantly more difficult to solve. (Think timing parallel sequences of animations und other UX effects etc.)
- andix 3y agoRx can be awesome for some complex problems. But I’m angular it’s everywhere and often makes things much more complex than they have to be.
- whycombagator 3y agoSeeing as it’s often. Do you have a single example?
- throw1234651234 3y agoI am the guy who doesn't use it, but people used to recommend using it for "event-driven architecture on the front end" - clicking a button is an event, typing text is an event, hovering over something is an event, and there could be multiple subscribers. The example use-cases people give are really contrived. The functional crowd also pushed it. Again, to me it's another trend like Web Components that never really took of in the mainstream. Yes, people use Web Components and RxJS' full power, but it's not something to learn when you are looking for practical, widely applicable skills. If anyone still cares about this, here is a helpful site that you can understand without knowing anything about RxJS: https://rxmarbles.com/ https://rxmarbles.com/
- steve_adams_86 3y agoI’ve rarely seen it used beyond very, very basic things in Angular projects (and I’ve always wished I saw more of it, actually). Maybe we just work on totally different kinds of projects.
- tcfhgj 3y agoI am using ngrx, and you get using rxjs a lot in effects.
- 88913527 3y agoThe biggest benefit, which I haven't found much of a practical need for, is you can continue to emit 1...n times, whereas a Promise only resolves once. Since it's an indeterminate number of times, you need to subscribe and unsubscribe to prevent memory leaks, so it just adds more overhead. Use a Promise if you only need to resolve once.
- traviswt 3y agoGenerators, yield, Iterator?
- JenrHywy 3y agoIf you get on board with it fully in Angular, rxjs + async pipes can make things pretty clean.
- andix 3y agoYes, RxJS is extremely hard to use. I developed on a lot of different technologies, but RxJS is one of the things I never seem to get a hang of. It’s not just the syntax (so (many (brackets)) and => lambdas), but it’s also really hard to create a mental model for what’s happening. I know that react hooks are not a replacement for Rx, but really often you can program similar functionality with hooks and it’s just 10 times easier to read.
- mediumdeviation 3y agoRxJS, more specifically its primitive Observables, fills a different space from Promises. For simple cases where only one value is emitted Promise probably works better and is more intuitive, but there are certain things that Promises cannot model - specifically when there is a stream of events over time. RxJS is more complicated because it needs to model more complex things. I do think Angular made a big mistake overusing it in places where Promises would have worked perfectly fine, but when you do need it it does work pretty well.
- pcthrowaway 3y ago> I do think Angular made a big mistake overusing it in places where Promises would have worked perfectly fine, but when you do need it it does work pretty well. Was it really a mistake or were they just using it before native promises were widely supported?
- mattigames 3y agoRxJS really needs a better debugging experience, I would love some visual representation (like a graph?) of all the events and how they relate to each other (who is waiting what, what has been waited, what was canceled by whom, etc). I tried a few plugins and browser extensions that supposedly do that but they all crashed, in their defence it was probably because it was a huge monolithic app.
- andix 3y agoFixing something too complex by adding additional complexity? :)
- mattigames 3y agoA tool to help me get a mental model of it's doings would reduce complexity where it matters the most: inside the developer's brain, ha.
- baq 3y agoSometimes you have to do more to do less…
- archarios 3y agoI haven't used rxjs specifically a whole lot but I am a fan of the general declarative pipeline style that it promotes. A different JS library that I've used extensively that promotes a similar style but for more general purposes is Ramda. It is a very different approach to programming than is common so I understand not finding it easy to grasp. In my experience, the benefit is generally that there is less clutter in your code and the dataflow that is happening is a lot more explicit which helps me build a mental model of what is happening a lot more quickly. ChatGPT is actually pretty good at exploring these different styles btw. It is pretty good at taking one code example and implementing it in different ways when prompted.
- riku_iki 3y agoyou still can use promises if you want?
- xupybd 3y agoI'm not sure if you have spent much time in a functional language but I found this helped me understand what is going on with a Promise and an Observable. They're all Monads. Just like List and Map or the optional Monad. When I first started learning that sort of thing it made no sense at all. But now it's just a design pattern that allows you to organize things. Having that understanding helps abstract away some of the mechanisms in the observable. It helped me at least. YMMV
- nine_k 3y agoIndeed! The concept of Monad is simple and very useful; once you learn it, you start seeing it everywhere. JS Promises are not completely monadic though, because a Promise that resolves into a Promise is always effectively auto-flattened into a single Promise. But most of the time other monadic properties of Promises can be used despite this.
- xupybd 3y agoGood to know. I didn't realize that promises were not monads.
- miiiiiike 3y agoUnintuitive? Yes. 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.
- JohnCurran 3y agoFirst: 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
- jackdh 3y agoVery 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-sagas-8e53610c0eda https://shift.infinite.red/redux-observable-epics-vs-redux-s...
- NoNameProvided 3y agoI 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>')) ```
- bonestamp2 3y agoYes, and that's part of why they're adding signals.
- Frotag 3y agoMy goto example for RxJS are event handlers. Heres an example that implements drag-and-drop (for which the vanillajs / d3js versions aren't nearly as pretty) It basically translates to 1. Wait for a mousedown event 2. Start listening for mousemove events 2a. On each mousemove event, do something 2b. When a mouseup event occurs, stop listening for mousemoves and return to 1. import { fromEvent } from 'rxjs'; import { exhaustMap, takeUntil, tap } from 'rxjs/operators'; const el = document.querySelector('body'); const mousedown$ = fromEvent<MouseEvent>(el, 'mousedown'); const mousemove$ = fromEvent<MouseEvent>(document, 'mousemove'); const mouseup$ = fromEvent<MouseEvent>(document, 'mouseup'); mousedown$.pipe( exhaustMap(mousedownEvent => mousemove$.pipe(takeUntil(mouseup$))), tap(mousemoveEvent => { console.log('mousemove') }) ).subscribe(); https://stackblitz.com/edit/drag-and-drop-rx-rvdkzv?file=index.ts https://stackblitz.com/edit/drag-and-drop-rx-rvdkzv?file=ind... --- More specifically I've found RxJS makes simple one-off calls (eg API fetches) ceremoniously painful (do I need to unsubscribe? do I get the value sync-ly or async?), but anything that involves multiple values (eg websockets, polling, event handlers) gets much cleaner. My biggest complaint with RxJS is probably the dev experience though. It makes call stacks / the debugger useless so you have to get comfortable with console.log's everywhere. Which is one of the reasons I avoid chaining observables and filter()s in general.
- tcfhgj 3y agoHmm I agree with call stacks, but the debugger is doing fine
- iansinnott 3y agoRxJS _used to be_ more intuitive, IMO. Around version 5 or so the API changed to use `.pipe` instead of simply chaining operators. Also, some functions were renamed to be (unintentionally, one assumes) more opaque. Such as `flatMapLatest` -> `switchMap`. Anyhow, there's definitely a learning curve but what it provides is very powerful. It's unfortunate, IMO, that the API has become less approachable over the years.
- steve_adams_86 3y agoAlthough I see how chaining might feel more intuitive, pipeable operators allow for a lot more intuitive and readable composition, making it so you can create reusable and easily tested operators, or even sets of them. It’s great for what it’s designed for, but you’re not wrong either. Composition can be hard to manage and navigate where a chainable API can be easy to follow and interpret by simply reading the flow. I think RxJS is actually amazing and I like the path they chose, but I see why it isn’t more widely adopted too. It isn’t nearly as intuitive as it maybe could be.
- iansinnott 3y agoThere's definitely much to be said in favor of simple function composition. However, I found the API choices odd because in RxJS the `.pipe` operator is, itself, chained rather than being standalone. Using a standalone `pipe`, such as via Ramda or something home-grown worked just fine, so I found it very strange that they mixed the functional composition style with the object-chainable style. > I see why it isn’t more widely adopted too I agree that RxJS is amazing, which is why less adoption is unfortunate. So many projects would benefit from RxJS or something like it.
- Tade0 3y agoSame. I've found that this is one of those things that half of the developers never learn to use properly and is therefore a net negative. In Angular specifically it offers a spectrum of footguns, my favourite by far being passing an observable as an input. Will the component re-render when the observable emits? Who knows? It depends on more than one factor. Interesting things also happen when it's a cold observable, it errors out or just completes. Overall it's quite the circus and I've been in teams where most of the developers had only a surface understanding of what was going on. That in and of itself is actually not a showstopper until someone decides to create their own component library.
- commitpizza 3y agoThe problem with RxJS is that it feels like Node did in the beginning. It's hard as eff to figure out where the system goes, what happens when, in what order etc.
- knallfrosch 3y agoWhat's concerning is that when people use Observables, 90% of the time you need to break out of them again. Subscribe, (value) => currentValue = value, do some calculation, onDestroy unsubscribe.. I don't know whether people really solve complex problems or whether they just appear complex when you use RxJS.
- Klaster_1 3y agoHave you tried `async` pipe and `takeUntilDestroyed`? I only ever `subscribe` if I need to trigger side effects, like setting a form validator based or a value (probably can be replaced by async validators) or modify DOM outside of the app root.
- knallfrosch 3y agoYes, but the problem with the async pipe is that you're pulling logic into the template.