This ONE function makes RxJS + Signals in Angular so much better 

Same here. I dont comment on videos but that was amazing. We have some greenfield work upcoming and Ill be using this approach.

You definitely want to watch this one, watch it now 😉

You should

@@JoshuaMorony man I want to watch all of them 🤣😂 you rock in angular space

Respectfully, I think you're only looking at one side of the equation. The reason Angular has adopted signals is not about storing state, but about how change detection works. Ergo, the real benefit to signals isn't their usage for state, but for the dramatic performance increase they offer in terms of change detection. RxJS is great for async operations which populate state, but Angular sorely needed a reactive primitive that could track dependencies automatically and only mark components for rerender that depend on the signal that changed rather than dirty checking the entire component tree every time a DOM event emits. That's why Enea and Chau are using RxJS for the aysc bits (AKA fetching data and merging streams), but converting them to signals for use in the component.

@@kylerjohnson988 Good point

Yes absolutely you can use NgRx Store if you want (the only thing I think is slightly more declarative in the approach from the video is that you don't need to imperatively trigger things like load actions) - my main motivation for this style is to keep things more bare bones/vanilla for teaching purposes, but also I like to avoid using a library if I can (i.e. it isn't providing a significant benefit). At the moment I feel like with this default/vanilla approach + the connect function I don't need much else, but that also might change depending on the circumstance

`toSignal` does work the way you describe but it implies that your state is stored on an RxJS Stream. In a Signal-first world, we want to hold our state in a Signal (or some other signalState/signalStore abstractions). And `connect` allows us to bridge between the RxJS Event Sources (no state) to the Signals (state) in a more declarative way. You can connect a stream that emits the whole state, or in the case that the Signal state is an Object, you can also connect a stream to a specific slice of that object (like Josh shows in this video)

​@@ChauTran "it implies that your state is stored on an RxJS stream" is such a succinct way to explain the difference

This approach also made me think of this but I only really looked at auto signals when Mike was first talking about them, I should probably give that a proper look again - I get the impression that connect is similar but still different

@@JoshuaMoronyIf you think its worth sharing your thoughts I would really like to share them in a video like this one. It is awesome content, thank you!

If you are using takeUntilDestroyed (which connect does under the hood) it needs to be used within an injection context (which includes the constructor) otherwise you will manually have to supply it with a DestroyRef - this is how it knows what it needs to watch for it to be destroyed

Thanks, haha I think I need to take an Angular course to fully understand that sentence, coming from React where I haven't used a class in almost 4 years and you can clean up just by returning a function :D It's interesting though to see similar things like signals trickling into Angular.

Essentially yes and it's desirable (at least for my purposes) for the same reason that it was desirable to have the RxJS -> subscribe -> Signal set up with manually updating the state rather than using toSignal - it allows for this "imperative shortcut" zone where all state can be accessed and updated however you like, rather than strictly having to have everything derived in RxJS streams and then just consumed with toSignal. Adds flexibility and reduces complexity, at the cost of making the code a bit less declarative (but I think it is worth the cost). And to your final question, yes - if the stream emits { someProperty: someValue } it will update the 'someProperty' property on the signal - you can just map it to whatever you like and it will patch just those properties in the signal (assuming your signal stores an object).

@@JoshuaMorony I understand, that's cool! Mapping specific properties on a state signal I can see being very powerful and something I could use. Wherever possible though it's probably better to use a readonly signal

@@kingpinkentDefinitely `readonly signal` is the way to go but currently there's no way to create a readonly signal WITHOUT a writeable signal at the moment. And we want to create a state signal so `connect` (and sometimes computedFrom) is a natural bridge between Signal and RxJS at the moment if you choose not to use ngrx or rx-angular (which I think you should :D)

​@@ChauTran Are you sure? I'm pretty new to signals so I might be wrong but the toSignal method on an observable does return a readonly signal. Theres no writeable signal in that context other than what the observable passes in to it. I get the idea with the writeable state signal, it can however introduce unexpected behavior with the state being altered from other places, the common tradeoff essentially. I use ngxs at the moment, been looking at rx-angular though, a lot of nice things there, feels more well maintained as well, so a switch is probably likely :)

toSignal implies you use rxjs as the source of truth for your state. That’s the main difference. Yes, both ngrx/signals and rx-angular come out with awesome APIs. Until we have everything Signals (signal inputs, signals viewchild, signal form etc…), things like connect/computedFrom are 100% more valuable than toSignal alone

I feel like their purpose was adequately explained in his previous videos, as well as the videos of other prominent bleeding edge creators. Data and event streams can still be entirely rxjs based in services. Signals don't have to change that setup, and shouldn't. It does change the subject-as-a-service pattern if you're using that. Otherwise, adding signals to the template and component files allows us to communicate with those streams better imo, and makes a case for limiting the automatic decision to use NgRx and/or Component Store. You have to subscribe way less, use the async pipe way less, have to worry about whether or not a binding has a value way less, and so on. I'm not sure how the benefits could be clearer than that, but I'm open to be argued.

@@mikemarkovich69 Subscribe less? I never subscribe at all (some rare exceptions). I guess not writing async in the template is somehow an improvement? I don't think so. I don't have to use external state management now but I do need external libs like explained here or I get almost the same amount of boilerplate as I would with subject based state management. Not saying they're totally useless, just expected more when it was announced...