@@JoshuaMorony lol I don't know how I ended up here because I have never liked RxJS, but I'm working on a webapp for playing piano and this has me thinking too. Rare win from the YT algorithm
I'd name it RxJS mandolin. Violin and mandolin have the same GDAE tuning. But a mandolin has frets and a violin is fretless which allows to play microtonal things. The virtual solution above generates exact notes from chromatic scale which makes it a mandolin instead of violin.
Very Awesome use of RxJS. From what I've seen, many people find using RxJS challenging. Personally, I don't use RxJS in my web projects because hooks usually is enough. But I do use RxJava in all my Android projects. It's very good for handling forms, user input, and API calls. UniRx for Unity Game, very very useful for object update and inputs. While I can't say RxJS is exactly the same as RxJava or UniRx. The problem I can think of are that it might be overkill for some projects
Personally I never see it as overkill, I find it the simpler solution (versus not having RxJS or any alternative) in any app where any state changes asynchronously (which is pretty much always) - I find not including RxJS the harder option, so I never see it as overkill.
Месяц назад
Brilliant! I think RxJs helps a lot with complex business logic. Thanks!
Josh, we know you are rxjs god. But please make a rxjs course where you explain how to think reactive, what mindset we should have in your awesome style. So that we humans could reach upto some level.
Based on my experience, the problem with RxJS is that when a team includes junior developers or developers with little RxJS experience, they can create significant issues and introduce challenging bugs that are difficult to resolve later on.
This is certainly a problem, and a counterpoint I hear a lot to using RxJS, but personally I don't think it make sense to list this as a con for RxJS. To me it feels similar to putting devs who don't know TypeScript on a TypeScript project and being unsatisfied with the resulting typing issues. If a team decides to use RxJS then they should also invest into the training/hiring for their devs to understand RxJS.
I understand that RxJS requires some practice, a change of mindset and just learning. But I don't understand the complaint about its difficulty. It's simply one of the key skills to Angular. It's not that difficult at all, any course teaches this skill pretty well from scratch. You just spend, for example, 10h reworking some course and practical tasks and you just know how to RxJS. The path to learning is really easy, you just have to spend some hours and it is impossible not to learn. Of course, later it's a matter of practice and experience, but no one becomes a senior developer without learning and experience.
I think A"I" is a gamechanger here. It makes the entry for noobs so much easier, compared to looking at 250 operators w/o a clue. I'm not saying copilot is doing the right thing always but the entry and the test samples for juniors to play with use cases they specified in plain english is insanely useful.
@@armynyus9123 this is a good point for the RxJS learning journey - from what I've seen ChatGPT is usually pretty good at recommending operators for scenarios, and also just generally is quite good at answering conceptual questions
I can of course understand that you are trying to justify RxJs. But what we mean by "everyday" usage is really just making a request and then doing something with the response not much more is needed. Sure it's nice to tap into observables via Reactive Forms and then make your RxJs magic there but you can do all that without RxJs see Vue.js. We have many developers who have to familiarize themselves with (Nest.js + Angular) => Rxjs - everyone always has difficulties at the beginning. The big problem is that you have to know a lot and understand it well to be able to use it properly. That alone is the reverse-USP of RxJs
The positioning of a virtual violin being a common scenario is tongue-in-cheek, but I'm still of the view that RxJS is useful for mundane things - even things that look like just one off requests to load data. RxJS ultimately is good at handling things that happen over time, and that's exactly what happens in an app (I would say perhaps that's an entirely what an app "is" - state changing over time via events). Even something like a request to load data for a page often isn't just a once off request - assuming an SPA app here, what if the user wants to refresh that data? filter the data? go to the next page? These are events that change that data over time. What if we want to derive something else from that page data (maybe a "total items" or something) that should react to the page data changing? I won't disagree that learning RxJS is hard, but RxJS handles the complexities of these scenarios upfront and handling them in a more "simple" imperative way often either ends up leading to more complicated code than what could be created with RxJS, or quite often bugs/edge cases/race conditions that are just ignored which leads to worse UX Also will add that I don't think RxJS is the only way to adequately deal with these things, it is the declarative aspect that I think is important, and there are other ways to achieve that
