Replies: 3 comments 7 replies
-
I have to say I used it extensively in redux-observables and also as a component state management tool. once I grasped the concepts then it was really pleasant to work with. but yes it required effort. "new team members" is something that was indeed a problem also for us, but I think if we want to raise the quality bar of our web apps in general, that cannot be a limiting factor any longer. we are hiring software engineers after all, I am sure they can manage given proper guidance |
Beta Was this translation helpful? Give feedback.
-
I'm on the same boat. I got first introduced to RxJS when I moved from AngularJS to Angular 2 on the company I was, although I didn't fully understand reactive programming back then. I think there was not really good documentation on how to use RxJS reactively in angular, at least at that time. Essentially the HTTP service returned an Observable instead of a promise, and you could put subjects everywhere to have the UI update when you push new data to them. That was my level of understanding. Then I moved to another company where I've been using React for the last 6 years now, started with Redux + Redux Observable, and here is where I started learning about reactive programming, but soon enough it felt like the state itself was not reactive. Redux Observable just works as a way of reacting to actions to trigger some side effects, and end up spitting more redux actions, but it was easy to fall in the pitfall of using the redux store as a "subject" and making the actions just a setter of that store (.next on a subject) Talking this with some of the colleagues we spiked something to manage the state directly with RxJS, and hook it into the react components by tapping on those states. This lets us declare our state reactively and keep it independent from the component tree. It also makes it trivial to code split (something extremely challenging with a redux store). From that spike we released a library, https://github.com/re-rxjs/react-rxjs, which we keep using and maintaining (adding in more features or making it easier to use). We've been using it in a few projects on our company for the past 2 years, and we also have received some good feedback from others that use it. I'm on a point where I realised that I don't know how to do any sort of application in vanilla React that's a bit more complex than a todo list. I'm so used of thinking reactively when building state that now it's challenging for me to revert it to imperative way (and even more if you have the common issues of vanilla react in the way: useEffect closures, useMemo hell, having to lift state up, etc.) |
Beta Was this translation helpful? Give feedback.
-
I just can't figure out what is the good case for picking RxJS in 2022 for frontend if you don't use Angular. In Angular you don't have much choice, they don't have many choices. But if RxJS will close only in Angular world it's dead end I think. |
Beta Was this translation helpful? Give feedback.
-
Hello guys, I want to discuss RxJS, and it parts in developments right now.
I was an Angular dev for 4+ years, then I switched to React, and in my project we use RxJS a lot for state management, and all business logic. I don't think it's the best idea, because it's super complex, and onboarding for new team members it's a hell.
In Angular world, RxJS is everywhere, but I saw a lot of misusing this concept of reactivity. Because if you want to write clean reactive code everything thing is a steam, and then you combine these steams together, and after all you have 1 subscription that run it, most of the angular dev don't do that, instead that do a lot of subscribe() in their code, that's wrong. So what's yours thoughts about this technology.
In my opinion is good it's useful sometimes, the famous example is autocomplete, but in general it's to complicated to use it properly. What's your thoughts? Do you use it in your companies?
Beta Was this translation helpful? Give feedback.
All reactions