Unleashing the Power of RxJS: A Deep Dive into Reactive Programming
Discover how RxJS transforms asynchronous programming with its powerful Observables, enabling developers to manage data streams effortlessly. This article explores the fundamentals of RxJS, its operat...
https://news.lavx.hu/article/unleashing-the-power-of-rxjs-a-deep-dive-into-reactive-programming
IT IS A FUCKING GEM....
interval(50)
.pipe(
filter(() => storageService.isReady()),
retry(100)
)
.pipe(take(1))
.subscribe(() => {
console.log("storage ready");
})
I know how powerful #rxjs can be, but sometimes it's REALLY hurting my brain....
I've been pondering about creating EventSourcing, CQRS & DDD scaffolding from scratch in TypeScript.
There doesn't seem to be an OpenSource basic scaffolding for this using RxJS? ( I mean the basic bang like NgRx ).
DDD -> NgRx
- Command -> Action ( in imperative )
- Command Handler -> Effect
- Domain Event -> Action ( in past tense )
- Aggregate state -> a Store entry
- Aggregate state's apply -> Reducer
Did I get this right?
Having worked with #Angular in-depth for 2 years now, I can articulate what I don’t like about the #framework.
1. #RxJS is a terrible primitive to build most #CRUD software upon. #Promises are better for most things, and event listeners are fine.
2. Its #DI system encourages long-lived, easily-accessible Singletons that are serious “foot guns.”
3. Data management is painful. Resolvers are a worse DX than either #EmberJS’s Ember Data or #React’s TanStack Query.
Master Asynchronous JavaScript with RxJS.
https://buff.ly/41lIkVY
#javascript #rxjs #async #webdev #webdevelopment
Who's excited about observables in the browser like I am?
#reactive #observable #rxjs but not rxjs
New article!
I rewrote my blog build scripts to eliminate Gulp, and used RxJS for the file streams. I wrote down what I learned:
Since it's related, here's the `removeEventListener` API I wish we had:
```javascript
const removeListener = window.addEventListener('something', () => { /* ... */ });
await someTime();
removeListener();
```
Benefits:
1. You only provide the handler once, so it works great with lambdas. You don't need to keep a reference to the handler just to remove it later.
2. You don't need to provide the event twice. It's additional information to hard-code and/or dynamically track.
3. You can't accidentally `removeEventListener` on a function which was not bound in the first place (which is a no-op that often indicates a bug such as `removeEventListener('something', foo.bind(this)`).
This design is basically a copy of the way #RxJS handles subscriptions, but I find this much more ergonomic and intuitive.
I built this POC to demonstrate how I'd use CustomEvents to implement Signals. Please criticize my approach and tell me why I need a native browser API for this.
Ever since #knockoutJS popularized data-binding, there's been numerous flavors of the #Observer pattern; Object.observe(), #React state, #RxJS, now #Signals. Every time I think, it's just #CustomEvents with extra steps.
#Events are at the core of the #JavaScript runtime; why is everyone always trying to avoid using them!?
In 2013 we wrote async javascript & the only patterns we had were races and callbacks & we liked it. Now we got 100*+ abstractions over races and callbacks.
* most of those are #rxjs
Check out my latest video on error handling with Observables:
Catch and RethrowCatch and ContinueRetry on ErrorRetryWhenErrors and Action Streams
#rxjs created an industry, a massive enterprise in wondering if observables need to be unsubscribed. I think the anti-unsubscription crowd is right in the sense of
- We don't know what is happening in unsubscribe(), maybe nothing
- The computer will be shut down, we will all die, and the universe will be cold and black and so should we really care about collecting the garbage early
- Out-of-memory will force garbage collection organically as the user reboots.
Interesting conversation on the @TC39 AsyncIterator helpers spec about the behavior of flatMap and it’s resolution strategy. There’s a reason IxJS and RxJS have concatMap and flatMap to limit the concurrency. It’ll be interesting how this plays out https://github.com/tc39/proposal-async-iterator-helpers/issues/2
Glad to see that more of IxJS and Iterable methods becoming ES standards such as Iterable.range making it to Stage 2 from this past @TC39 meeting https://github.com/tc39/proposal-iterator.range
The less we have to use IxJS, and the more that is built into the platform, the better!
It's kind of sad to see articles like this not quite getting the essence of RxJS and Observables. They are a primitive that could be used to build other things like Signals. Knockout.js was built on this idea of Observables as well, hence the name ko.observable
Plenty of ways to handle the mass unsubscribe either through combinators such as takeUntil or managing it yourself with subscriptions/disposables
Are you an Angular developer that also does C#?
Join me at the VSLive conference in Nashville in May!
I'm talking about #rxjs and new-ish features in C#.
Use this link to register: http://bit.ly/3kSNaaf
One thing I regretted when I created RxJS that I didn't create a more simple lightweight primitive that could be used for binding scenarios such as what we saw in Knockout.js and now in Signals. It could have just been a BehaviorSubject with composition operators that returned BehaviorSubjects instead of just Observables.
I am intrigued though where the reactive future does take us
@Perl @gandalf’s RxPerl will cure what ails you, if what ails you is dealing with streams of data via asynchronous callback functions. https://metacpan.org/pod/RxPerl
You can drop it into your existing event-driven #Perl code with ease, as it works with @leonerd’s IO::Async, @mojolicious’s Mojo::IOLoop, and AnyEvent interface libraries. It’s an implementation of #ReactiveX designed to behave like #JavaScript’s #RxJS. https://noc.social/@gandalf/109839670728579860
