Posted on Jul 18 YouTubeWhy shouldn't Rxjs do everything?RxJS is amazing, but it has limitations. Consider a counter implemented using a simple variation of the "Subject in a Service" approach:Now multiple components can share and react to this state by subscribing to count$:Now let's add some derived states with the RxJS map and combineLatest operators:Here's a diagram of these reactive relationships:Here's what that looks like:Isn't this easy? RxJS just takes care of everything for us. There's probably nothing wrong with this.Actually there is. Let's put a console log inside the map for message$ and see what happens when we increment the count once.Why did it run 4 times? We only incremented the count once. That's not efficient.Something weird is going on. Let's put Console Logs inside each observable so we can get a view into everything happening. And think for a minute about what we should expect. We have a single event, and 5 derived states: double$, triple$, combined$, over9000$, and message$. Shouldn't we see 5 console logs? Well, here's what we actually get:It's over 9000!!! We just implemented our feature in the simplest way possible, and this is what RxJS gave us. This is 40 logs, or 8x what it should be.We need to understand how subscriptions work. We have 2 components subscribing to several of these observables. Here I've added a colored line for each subscription:Each subscription gets passed all the way up to the top of the chain. If you count the number of blue and green lines next to double$ and triple, it's 8 each. That's the number of console logs for each of those. combined$ has 12 lines around it (because of the branching), and 12 logs. But message$ has 2 lines and not 2 but 4 console logs, and over9000$ has 4 lines but 8 console logs. That's because each of those lines ends up splitting into 2 lines up at the combineLatest. We have to learn more operators to deal with these problems: map and distinctUntilChanged (sometimes with a comparator), combineLatest and debounceTime, and shareReplay. Actually, not shareReplay, more like publishReplay and refCount. Or actually, merge, NEVER, share and ReplaySubject (more on these later). The really crazy thing is that most people aren't even aware of all these issues. It takes some painful experiences to learn that these operators are necessary.But asking everyone to avoid the numerous RxJS pitfalls, become intimately familiar with how subscriptions work, and learn all these operators, all just for basic derived state, is absurd. And, these operators increase bundle size and do work at runtime. Creating a custom operator doesn't fix that. So, while RxJS is amazing for managing asynchronous event streams, it is inefficient and difficult to use for synchronizing states.Selectors are pretty efficient at computing derived states.But I never liked their syntax:So for StateAdapt I came up with new syntax:But selectors require a state management library with a global state object, which makes them impossible to integrate tightly with framework APIs, such as component inputs.Angular needed a reactive primitive of its own, and out of all the options, signals were the best choice for synchronization.Let's implement our counter with Angular signals:Now when we click, we get the 5 expected logs:It's more efficient than even optimized RxJS, and we only needed one "operator": computed. The Angular team did an amazing job with the implementation, too. If you want to learn more about how it works, I recommend this interview they did with Ryan Carniato. Signals are awesome, but like RxJS, they have limitations:These will be the topics of my next articles. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse Connie Leung - May 26 Alex Skoropad - May 26 Eduard Tar - May 15 Nicolas Frizzarin - May 24 Once suspended, mfp22 will not be able to comment or publish posts until their suspension is removed. Once unsuspended, mfp22 will be able to comment and publish posts again. Once unpublished, all posts by mfp22 will become hidden and only accessible to themselves. If mfp22 is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to Mike Pearson. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag mfp22: mfp22 consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging mfp22 will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.