Angular is about to get its most IMPORTANT change in a long time...

hey it's me the guy who Fanboys over rxjs constantly and how great I think it is I'm here to tell you about a change that is coming to angular that will result in me using rxjs way less and why that's a good thing to my fellow rxjs lovers Don't Panic this change is actually good for rxjs and will likely lead to the ability to integrate rxjs with angular much more smoothly so the change we are going to talk about is angular's new reactive primitive which will be signals so signals have risen to stardom recently popularized by solid.js and Ryan carniado who I believe has been helping out the angular team a great deal with their own implementation of signals so a big thank you to Ryan for helping spread the signal love around so a signal will look something like this its basic purpose is to hold a value just like a standard variable but one key interesting part here is that if a signal changes then anything that depends on that signal will also be updated the other important part is that it will be possible for angular to utilize this mechanism as the way that change detection is triggered rather than the current default approach of dirty checking the entire component tree so for the rxjs people a signal is kind of like a behavior subject but you can react to a signal changing without needing to subscribe to it to get the value out and there are some other important differences but I don't want to get too into the weeds in this video so before we get into some more specific details let's rewind a little and discuss what a reactive primitive even is and what purpose it would have in angular so let's take a look at angular as it works today with the default change detection strategy so we're going to keep this high level because we don't really want to go down the change detection rabbit hole but let's say I update this count value angular needs to know something has changed in order to update the template so that we actually see the change I click a button it triggers a function that updates the account value and angular knows to update the template and display the new value but how is it that angular knows this value changed so the way that angular knows this has changed is through its use of the Zone JS Library so the role of Zone JS is essentially to patch browser apis such that anytime anything happens that could possibly cause something to change like a set timeout or set interval or an HTTP request or a Dom event whenever any of these things happen it's going to let angular know and angular can do what it needs to do so in this case we triggered this click Handler event so now angular knows that something might have changed because Zone JS has told it hey this Dom event was just triggered you might want to look into that so angular will go ahead and check the entire component tree for changes even though we have made just this one local change so this isn't quite as bad as it sounds angular does this quite efficiently but still it it is quite heavy-handed and signals allow for much finer control when reacting to changes so rather than keeping track of every potential thing that could possibly cause a change we can instead use signals as a mechanism for indicating to angular that something has changed and the view needs to update so it's great for change detection but it also provides us with additional power when coding our applications so if you've seen any videos on this channel before then you might know that I advocate for a reactive and declarative style of code I'm not going to rehash that here but with rxjs it would look something like this this is declarative because everything we need to know about this particular value here is contained within this declaration other parts of the code can't imperatively change this value we can see exactly what it depends on and how it is calculated right here and if anything else depends on this value then anytime this value updates the value that depends on it also updates so in short we can easily see what something is just by looking at its declaration and its declaration alone and everything in our application is just going to react automatically to changes so if we tried to do this without rxjs in the current version of angular it wouldn't work when count changes the double count and double double count wouldn't also update but now with this new reactive primitive signals we will be able to do the same thing without needing observables like this so the syntax is arguably a bit simpler but more importantly signals are not observables with a signal we can just access the value directly without having to subscribe to it with the rxjs version we would need to use the async pipe in the template to pull values out so if you're an rxjs fan that might not seem like that big of a deal is it really worth all this fuss over introducing an entirely new primitive called a signal to avoid having to use a subscription or using the async pipe why don't we just go more all in on rxjs so I'll explain why I think this is actually a very big deal in the last point of the video but first let's talk about how rxjs integrates with signals so what about rxjs is the angular team moving away from rxjs and so the answer to that is definitely no perhaps surprisingly the addition of signals is likely going to improve the integration of rxjs into angular in many ways so the most important thing to understand about signals at least in their basic or default form is that they are great at handling synchronous reactivity they do not handle asynchronous reactivity so I'll link to a separate video that explains this concept in more depth but the basic idea is this synchronous reactivity is where a value is known and can be set immediately a simple example being incrementing a counter we do not need to wait for the new value it can just be calculated and set immediately asynchronous reactivity is where we need to wait some time before we can set the new value so maybe we need to wait for a response from an API for example so signals do not have all of the tools needed deal with asynchronous reactivity built in so imagine we have an input box that allows us to search against an API and display results we make an HTTP request and update a signal with the result so we type J and expect to see a list of results containing all the results with J then we type j o and expect to see all the results that match Jo so this works fine as long as the first request finishes before the second request does but the response time from the server will vary it might be that the first request takes longer to complete than the second and so we end up getting our results back out of order and our signal will just naively be set to whichever value came in last and so this is a race condition rxjs comes with tools built in to handle these types of asynchronous reactivity situations so this is where we might want to reach for things like switch map or exhaust map to explicitly Define how we want this to work should the second request always win and the first one be canceled if it is still in progress or should we ignore any requests until the first request is finished so this is just one of a myriad of situa operations that rxjs can handle gracefully the great news is that we will be able to use signals for more simple synchronous reactivity but when we need to we'll be able to easily convert a signal to an rxjs observable using built-in methods that angular will provide so these apis are not finalized yet but likely it would look something like this we'll be able to easily convert a signal into an observable and an observable into a signal that means we can start with signals and if we need to deal with a situation that involves asynchronous reactivity we can easily convert the signal into an observable we can then also convert the resulting observable back into a signal which will allow us to just access its value directly in the template rather than using the async pipe so this really is the best of both worlds approach now to get to what I think is the biggest benefit of this change and that is that if we switch to signals as the new default way to learn and build with angular everyone is going to be on the same path whether you prefer a more more imperative style of coding with angular or you want to learn a more declarative style of coding so at the moment there is this big Chasm between coding imperatively in angular encoding declaratively most people begin coding imperatively because it is generally more intuitive and familiar to people but switching from the imperative way to the declarative way involves a huge paradigm shift and a total change in your mental model there are effectively two distinct ways to learn to code in angular and they are not compatible with each other as much as I love declarative coding with rxjs and I think it's worth it I know that it's not easy to learn signals will bring these two separate approaches together now everyone can learn signals by default and start to develop these ideas around reactivity and not even have to worry about incorporating rxjs if they don't want to or if they're not ready to yet but once they are feeling comfortable with the angular Basics if they do want to switch to a more declarative style of coding and handle asynchronous reactivity in a more robust way rxjs can more easily just be added into the concepts they already understand it builds on top of what they already know rather than dragging them through the thorn bushes to a totally different path a path that all these people on Twitter say is so great and please just suffer through this pain for a while it's worth it we promise so there are many more benefits that this is going to bring to angular for those of us who love rxjs and those who don't I'm sure I'll do more videos on this as the RFC is released and as the signals API becomes finalized but for now I mostly just wanted to make the point that this change is great for the future of angular it's great for people who do not want to use rxjs and it's great for people who do want to use rxjs if you found this video helpful at all a like or subscribe before you go will be very much appreciated and I hope to see you around again for the next video [Music] [Music]

Channel: Joshua Morony

Views: 78,811

Keywords: ionic, tutorial, tutorials, ionic tutorials, ionic framework, coding, coding tutorials, angular, angular tutorials, capacitor tutorials, mobile, mobile apps, apps, html5, ios, android, native, hybrid, pwa, web apps, progressive web applications, programming, stenciljs, stencil, performance, ui, ux, animations, screencast, rxjs, nx, ngrx, architecture

Id: 4FkFmn0LmLI

Length: 10min 14sec (614 seconds)

Published: Wed Feb 22 2023