Why you actually need RxJS (even if you don't realise it)

RxJS provides a way to explicitly handle asynchronous reactivity in your applications. This video explains what that means exactly, the difference to synchronous reactivity, and why the out of the box reactivity solutions Svelte and SolidJS might not be enough.
Source code: github.com/joshuamorony/svelt...
What does declarative mean?: • The easier way to code...
P.S. The clip of the daedric prince in the video is from the fan made Skyblivion mod - check it out if you're an Elder Scrolls nerd!
Get weekly content and tips exclusive to my newsletter: mobirony.ck.page/4a331b9076
Learn Angular with Ionic: ionicstart.com
0:00 Introduction
0:30 RxJS vs Svelte vs SolidJS
1:18 Drama repellent
1:56 The problem
3:17 The killer feature of RxJS
4:50 RxJS example
5:59 Conclusion
#rxjs #reactivity #svelte
- More tutorials: eliteionic.com
- Follow me on Twitter: / joshuamorony

[@JoshuaMorony]

Join my mailing list for more exclusive content and access to the archive of my private tips of the week: mobirony.ck.page/4a331b9076

[@BlockCylinder]

It's not overcomplicated, but it's very hard to understand the behavior and real use cases for all of the operators. This video provides a real, relatable example. Now we just need about 113 more of these...

[@valcron-1000]

This is a great example. Going further, your search box should probably introduce some kind of debounce to not spam the API. Getting a search box to work correctly without something like RxJS is just pure pain.

[@luxiansheng2268]

There is a debounce in lodash. Also, the demo just demoed a function to cancel the execution of the old request's callback, it's easy to implement also. But anyway, using switchMap is also a good solution in this case.

[@pfili9306]

I really like how Svelte lets you just drop-in replace native stores with RxJS observables without really changing anything in the template. It really shows how well thought this framework is.

[@xucongzhan9151]

Not to bash Svelte but the "subscription-based reactivity" or the "observer pattern" has been around for decades and it's no coincidence that both RxJS and Svelte resort to this idea. They had similar APIs but there were some rough edges, which were then ironed out after some extensive discussion between maintainers and users of both projects. It's just beautiful to see such OSS collaboration and I really appreciate it.

[@bertlemoi431]

what i have found is that RxJs tutorials never explain what goes on in the background and only tell you what you do. which is why i appreciate this channel because you also provide the background info to what is going on. and if you only know what to do and not how, i'm not surprised that everyone complains about it. and since they cannot comprehend what is going on - let alone: what they try to do - they cannot help themselves - which is really frutstrating. so... great content, and keep it coming! cheers!

[@mfpears]

I don't know what it is, but I never get tired of writing articles or watching videos about this. Maybe it's how often I've seen people push against or ignore RxJS. Normally this kind of constant uphill battle is a sign that it's futile or misguided, but in this case the benefits of reactive programming are so clear in my mind. Maybe someone will eventually find the perfect combination of words that convinces everyone and we can move on to talking about AI :) React hooks can also handle asynchronous behavior declaratively (like with TanStack Query), and so can custom SolidJS signals, but nothing is as comprehensive or optimized for event streams as RxJS. So it's good you said "or something else that does the same things as RxJS" at the end :) Sometime I forget to say that.

[@JoshuaMorony]

I feel similarly, it does make me feel like a bit of a lunatic sometimes like one day I'm going to publish one of these videos and a commenter will come along and I'll finally be like "Oooohhhh, now I see why there really is no need for RxJS" - hasn't happened yet and I don't expect it to, so I guess we'll just keep trying to convince people how cool RxJS is. To anyone else reading this comment, click on Mike's username and go subscribe - he has tons of content on this stuff

[@mfpears]

@@JoshuaMorony thanks for the plug. Just a warning though - I'm not super focused on producing exclusively high quality content like this channel. I knew my last video wouldn't get many views, but I still recorded and published it, because I like doing those kinds of videos. But I'll sometimes put a lot of effort into it. The next high-effort one is going to be called "10 misconceptions about reactivity". I'm kind of waiting to put a ton of time into it, because I keep seeing stuff on Twitter that needs to be added to the list :)

[@realVvD]

Thx, I lolled on the daedric prince joke. I did not expect it here :)

[@matthewblasco4720]

The simplicity of the example is chef's kiss. You could make a tutorial on rxjas and id be thrilled 😍😍 you are that such good teacher. Thank you

[@drewunstoppable]

Keep it up Josh you’re doing God’s work, it’s a privilege to have such great analysis on the libraries and concepts that we as coders use everyday!

[@JecksonGarcia]

Thanks for sharing your videos, they really have very useful information! I would like a video to see a video about content projection and when we should use ng-content, ng-template etc, and problems of each such as ng-content always initializing the content even if it is inside an ngIf or binding to container life cycles!

[@stashladki2594]

I cannot express how much I agree with everything you've said in this video. I'm still amazed that almost none apps that I've seen in other frameworks use RxJS instead of trying to adopt built-in reactivity to manage tasks which were not meant to dealt with that way. I guess we have just been blessed when we were introduced to it by Angular team such a long time ago and people outside just don't know that it exists or think it's just some bizarre "angular thingy" and just don't bother looking into it. Hopefully that changes soon.

[@SuperQuwertz]

More RxJs and Svelte please! Also a tutorial series please! ( Maybe its all already there, I just wrote this quickly )

[@Lewboskii]

So true, today I wanted to do some simple task with Svelte and immediately I missed RxJS

[@luxiansheng2268]

It's a great example that I ever thought also. Because Rxjs provide the ability to cancel not only the requests but also the execution of the request's callback. However, regarding most cases I have seen, the later requests will return later which means the later callback will be called later. So, the UI will be correct finally. Indeed, there might be a while that the UI is displaying the incorrect result if the server is slow. But when developers are using with lodash.debounce, the problem will become smaller when not using rxjs. So, in my opinion, the problem that RxJs solved in this demo is kind of a small problem. Compared with the code style changes brought by RxJs and the learning curve, it's hard to convince other people into using it. Maybe that's also the reason why it's not that popular. Anyway, it's a great example.

[@RaonakDM]

Yeah, I agree, this example can be solved much simpler by just debouncing the request.

[@harpymaslow]

Very cool Josh. I'm a big fan of RxJS and I'd say I'm pretty good at it. There's only one thing that I don't like about it it's the combineLatest and the way it emits values. Do you have a work around ?

[@ChauTran]

what would be your expected output?

[@harpymaslow]

@@ChauTran Issue is not the output but the number of time it emits values. If the combineLatest has 3 Obserfvables and 2 of them are related it will emit twice if that common source emits a new value

[@bryangomez5951]

Josh, how do you handle observables with reactive forms? I usually have my data in a service and consume them with subscribe on nginit to fill my forms. This only when is a form when I need to update a register. I subscribe to observables when using CUD (not R, becaus with this I use the async pipe) operations too.

[@adambickford8720]

I did this by having a 'submitting$' observable that i 'combineLatest()' with the data needed by the template. These are all coalesced into a single 'view model' object ({data: foo, submitting: boolean}) so there is only ONE subscription in the entire template and NONE in the component class. You can put that 'view model' in an `ngIf` with an alias at which point its like dealing with static values in the rest of the template. No more subs, just obvious logic like like When the user clicks submit, it just calls a `submitting$.next(true)` and all the http request, busy spinners, response handling, etc all 'react' to that one signal. (iirc i stole the idea from this channel)

[@martinemanuel8239]

Super interesting!

[@sebastiankubica7657]

keep making videos pls! :D

[@josephshandyharvian3423]

Nice one Josh, how about using debounce ?

[@pauleth]

I used debounce in a similar situation

[@harpymaslow]

You could but in that case you sacrifice reactivity (I mean time of the request) and the lowest your debounce time the greatest are your chances to have the same race condition issue

[@adambickford8720]

Debounce doesn't actually fix it. Imagine a 3s debounce but in this case the server takes 10s to respond. At the 4s mark the user adds a character, so at the debounced 7s mark a new request is fired in parallel. This request returns in 1s so at 8s the 2nd request finished, but that janky 1st request comes back 2 seconds at the 10s mark and overwrites it. Your terms and results are now out-of-sync. This is actually WAY worse as it will be intermittent. It'll plague users when the system is under load but you'll never reproduce it in a non-prod environment because its still a race condition.

[@JoshuaMorony]

Yes absolutely, I've tried to keep this example simple but I would also generally use debounceTime in combination with (not instead of) switchMap here - I generally combine: debounceTime(), distinctUntilChanged(), and switchMap - so it waits a small amount of time so we aren't trying to hit the API every few milliseconds, it only does the search if the value has changed, and then also eliminates that race condition problem

[@pauleth]

@@JoshuaMorony can you post a code snippet in which order these operators must be used to avoid unexpected consequences?

[@kivylius]

i know is an example, but this can easy be solved with AbortController. i think this example is good, but we need something where its really useful and any other way is inferior.

[@Alex-bc3xe]

What is indeed complicated is to try to implement something like RxJS by your own and make it work. Nowadays we have much more easier time with all those libraries which helps us a lot, but people need to be more disciplined and not complain for everything.

[@bobkelso5681]

You should make a video about rxdb which is a database that works on the principles of rxjs.

[@guilhermenunes3130]

I believe in SolidJS if you use the createRouteAction or createResource primitive it cancels the last request if the input is changed, so I guess you wouldn't have this problem ?

[@GeraldScholz]

I guess a denounce function also would have work in this example

[@JoshuaMorony]

A debounce is also useful here to prevent thrashing the API, but it will only hide the race condition problem not solve it - so something like the switchMap is still needed. If your debounce time is higher than your worst case scenario server response time the issue will be hidden properly, but say you set your debounce to 100ms and you get a response from the server in 130ms then you can still get results out of order.

[@hankkrutulis]

“Fitler employees” Oh thank god, I’m not the only one who is constantly mistyping filter this way😂😂

[@chasjadmahmood4875]

TBH when ever someone tries to explain why we should use rxjs they use this search list example. It is good but we need a more important use cases that improve large portion of app.

[@VictorMachadoDeFranca]

AbortSignals solve that issue. Although you would have to implement functionality or find a npm package that does it.

[@cocoscacao6102]

I'm still curious which situation NgRx and the bunch can solve that services cannot....

[@JoshuaMorony]

You don't need NgRx for anything, it's just a set of opinions/principles/tools for managing state but you can always do those same things or something else yourself. It's kind of like asking what Angular can do that JavaScript can not - Angular comes with a strong set of opinions and pre-built tools, but you can also just use JavaScript rather than Angular's specific rules around it if you want.

[@cocoscacao6102]

@@JoshuaMorony That's not really an answer. Imagine building an average modern web app with just JS. Is it possible? Yes, but only theoretically, because it would take you a lifetime to do it.

[@adambickford8720]

You mean all those operators are solving actual problems? And with my "simple" framework i'm stuck with reinventing them, where the end result will be far more complicated and less documented and tested than rxjs? Maybe i should use rxjs for the ORM i'm writing? (that's sarcasm, internet)

[@lukaszpiotrluczak]

Why you are writing ORM 8f you plan to use existing database? You should write new database and then orm for it!

[@JoshuaMorony]

Sarcasm noted lol but it's a good point and I think the same - the RxJS team are a bunch of smart people, and these 100+ operators don't exist just for fun and torturing people

[@JBuchmann]

I always forget that we can use rxjs outside of Angular...

[@otaxhu8021]

how the heck can you have race conditions in a single-threaded language??

[@JoshuaMorony]

Yes (if we ignore web workers) JS code executes on a single main thread, but asynchronous tasks are queued to be executed later whilst the main thread continues to execute code synchronously. If you're interested you can read about the JS event loop: developer.mozilla.org/en-US/docs/Web/JavaScript/Event_loop

[@cristiansfetcu2099]

funny how you skipped all the ReactJS useEffect & other stuff

[@JoshuaMorony]

Why is it funny? useEffect is imperative so doesn't really fit into what I'm talking about here - I think TanStack Query is what is typically used for reactive/declarative programming in React, but I'm not really familiar with it.

[@mLevyks]

still seems overly complex, you could just debounce that valuec

[@adambickford8720]

I don't think you understand the problem, debouncing will not help you at all. You'd need to round trip the actual search value to correlate it in the UI which is exactly the kind of bookkeeping we're trying to avoid!

[@darkelites1]

@@adambickford8720 Naah debounce is gonna help. He still have the problem of firing multiple request towards the api, but then discarding them when they return. IMO the right solution would be to have a small deboune on the input, to make sure the user is done searching. And then when he is done, it fires and fetches the data.

[@adambickford8720]

@@darkelites1 Only if you set the debounce as high as your worst-case latency. At that point you don't have a responsive auto complete, you have a janky submit the user can't control. That's a terrible user experience. The way shown is the most responsive for the user. RxJs allows you to easily 'tune' how aggressive you want that to be depending on the resource.

[@ChauTran]

@@adambickford8720 Both operators make some sense. But in my opinion, the proper solution is to combine both debounceTime and switchMap for this case. Now, there are cases where a project might have a custom Search component and the Search component has internal logic for debouncing then we probably only need switchMap where we do the fetch.

[@darkelites1]

@@adambickford8720 I dont believe so. I would much rather have a 200ms debugger on the input, and then only fetch 1 time for my api, then fire 4 request that gets dismissed when they return.

[@OnePieceWonPeace]

Again, in my years long search for why I should use RxJS, I've come up empty handed. So why isn't he just using a plain old debounce function to send a request? This is the problem when I ask people "what does RxJS do that I can't do without it" and people say: "well, because you can map it's values, you can filter them, you can switch on them...". And I say "you mean like what I can do with a normal array?". So, again, this guy in the video could just use a normal debounce function to achieve what he's doing, right? In fact, it still sounds like he'd be spamming his API with what he has because the request is not actually canceled, so he needs a debounce function still, right? Why not use just a debounce function and not worry about the RxJS part? I'm really asking. I can understand RxJS being necessary or at least highly convenient for, say, Game Development or HFT apps as he mentioned. I don't understand what the benefits are. I've also never felt like I needed it and have gotten along absolutely fine with concise code without it. Why am I adding Reactivity to Angular? Isn't it already reactive between the View & Controller (if you will)? So I can see maybe using RxJS for a raw JavaScript app perhaps. But I still tend to favor PubSub, The Mediator Pattern, or The Observer Pattern in those cases. PLEASE, I am asking anyone to help me understand why I NEED RxJS or why it is more CONVENIENT to use it in, say, a regular Angular app. Even use Gaming or HFT as an example to help me understand. Or use a raw JS app as an example. I'm genuinely seeking an explanation 🙏

[@JoshuaMorony]

The problem with using just a debounce is that you have to be sure the delay on the debounce is going to be longer than the maximum response time from your server - set it too low and you will still get out of order responses, set it too high and you are artificially slowing down your application. You could set a debounce of 100ms and that might be safe most the time, but it might not be enough sometimes - so it's just this balancing app between slowness and bugginess. Even if you had a really long debounce time of like 2s, it's still not unlikely to have outlier responses from the server which are going to be slower than this. With the switchMap this is not a concern and there is no tradeoff required - it doesn't *have* to be RxJS that handles this, but something needs to handle this asynchronous reactivity situation. Typically I use Angular which will actually cancel the requests because the switchMap will cause the previous stream to unsub and be cancelled - so in this particular case (since it is Svelte and not using Angular's HTTP) the getEmployeesBySearchTerm stream would need to handle cancelling the request on unsub.

[@OnePieceWonPeace]

@@JoshuaMorony thank you a lot for the additional info. It seems your approach is more concerned with firing off requests and [potentially] cancelling them (with switchMap) rather than only sending a single request based upon that balance you mentioned. Is that fair to say? Also, is it fair to say that some requests might actually open a connection on the server before being cancelled on the client and cause the server to perform some degree of unnecessary work? I would be curious to know about that as well.

[@JoshuaMorony]

​@@OnePieceWonPeace that isn't specific to the approach here, it is a requirement of the feature being implemented - a typeahead style search/filter starts searching/filtering as soon as the user types so by the nature of that feature you need to send multiple requests. But, even if this were a "normal" search where a user types a phrase and submits the completed phrase in one request - unless you specifically disable the ability to send a new request before the old one completes, you could still run into this same situation (it would just be more unlikely) RxJS becomes very useful for any situation with async reactivity like this - where we are reacting to something, and there is some delay between the thing we are reacting to beginning and ending (e.g. request launched -> some amount of time -> request finished)

[@OnePieceWonPeace]

@@JoshuaMorony copy. Yeah, I understand where you're coming from about the typeahead behavior. I guess my frame of reference is closer to "debounce the submission/request until it looks like the user is done typing" as opposed to "fire it off on every keypress and cancel any already open requests if it appears the user is not done typing yet". Either way, like you said, it demands some balance between bugginess and reliability. Not sure how well we can discover the tradeoffs in this particular medium. Another solution could be: cache the query string on request and provide it back to the UI for display so that it's apparent what data is reflected by the query text (still using a standard debounce function). That way, if the user types in an extra character right after the request is made, it comes back and the the UI replaces the input value with the cached query string that matches the request. That would be pretty simple and easy to do as well but, more importantly, it guarantees the user never has any confusion about the data vs the query. This would also align with several UX Design Principles as well -- status indication, error correction, consistency, etc.

[@JoshuaMorony]

​@@OnePieceWonPeace yes and to be clear I would also recommend using the debounceTime operator from RxJS as well for the typeahead because you still don't want to hammer requests unnecessarily (i.e. at the speed of typing) - but still as you pointed out we still need to deal with responses that exceed the debounceTime (or accept that responses might be returned out of order). And there are definitely solutions outside of RxJS to deal with these things, even without using extra libraries, but that's pretty much the point of RxJS - it has a bunch of stuff built in and uses a paradigm that fits with the concept of async reactivity well, so you don't have to build these sort of imperative workaround/special handling for things.

[@JacksonMarshal]

AbortController is crying at the corner.

[@Gol_D_Roger_The_Pirate_King]

ReactJS is not reactive just saying.

[@HonkletonDonkleton]

I definitely don't thanks

[@hyperactivepuss]

you don't