A quick guided tour on NgRx Signal Store, and the concept of Deep Signals, timestamps in the description 😊 No music after the intro, a shorter form video. Let me know if you enjoy these more, or prefer a lix of long and short format. Enjoy everyone!👍
This is like attaching individual reducers to store in REDUX , but here we are attaching pure objets that are converted to signals automatically. Really mind blowing. So there is no need to do normalization.
Notice that the state is still kept internally, together with the signals that are created, and normalization still helps. There is a plugin for entities, for NgRx Signal Store too, I'm thinking of covering it in a future videos. 😊👍
@@AngularUniversity I am a heavy user of the concept entity adapter in REACT REDUX. Waiting for your Signal Store based entity adapter video. Thank you. I have bought your course already in Udemy long back.
I think it's a matter of getting used to it, it's very new. 😉 With an Ngrx effect, a service is also used to call the backend and store data in the store. You can also plug the store into a RxJs chain and do something similar to an NgRx effect ngrx.io/guide/signals/rxjs-integration But I think that effects are better left for other things, if it's just calling the backend and getting data into the store, I personally prefer this new approach. 👍
Thanks a lot for the video! One quick question: Is there a browser extension to see the actual state? For the NGRX store I always used Redux extension to see in the browser the store (and it's very helpful to debug), is there something like that for this signal store?
Hola! Excelente video. Y si quiero que el store persista a nivel de memoria? Ejemplo que no quiero que a cada rato se este invocando el get todos del service (imaginando que es un llamado a un API) ya que previamente en otro componente ya lo había cargado? Como sería esto?
@@AngularUniversity muchas gracias !!! Ojalá puedas hacer un video explicando cómo hacerlo. Esta parte del manejo de store siempre se me ha sido complicado 🙏 con tus videos entiendo mejor. Muchas gracias por tu tiempo !!!!
Hi Vasco, just a question: if you reach out to a real backend you would use services that use httpclient, thus returning observables which, I assume, would be turned into signals using toSignal from the Angular RxJS interop package. Would you use toSignal in the service class already or inside the SignalStore?
Great question, actually I would call toPromise on the HTTP client for now, or the equivalent methods that replace it like firstValueFrom. Then use async / await to do HTTP requests, and send the value to a signal via set() or update(). I'm not sure if it's a good idea to handle HTTP responses as signals, as they might error out, and there is no such concept in signals. Using promises and setting the value in a signal is what I would do at this stage. The API of the HTTP client is going to be revisited down the line, together with other Angular APIs, in the common path of making RxJs optional in the framework. 👍Check out the latest Angular Q&A where the Angular team talks about the different options that you have for HTTP in Angular. 👍
Great question 😉 by having different signals per nested property instead of just one signal for the whole auth object, different parts of the application can get notified only when and if the properties that they use change. For example, this way if a component only uses auth.user.name(), if auth.user.roles() changes then the component will not get updated. I go into detail on this fine-grained reactivity concept in this other video - ruclips.net/video/BasNj-w5RMI/видео.html Let me know if that helped?
@@AngularUniversity I get that its providing fine grained reactivity at the property level, and its pretty cool how it does so with such little boilerplate. But in practice, is it really that much more efficient to adopt as a general approach though? Especially when its likely you're rendering more than one property from the object and ng will rerender the entire component anyway. (I'm assuming its smart enough to 'coalesce' the events) I've never used this lib so its probably time to play with it and see. It just feels like it falls into the 'OnPush' realm of maybe too much accidental complexity as a default :)
@@adambickford8720 I really like that though-process of keeping things simple, it's my approach too. 😊 👍 I think if the application does not use a centralized store, then using signal() at the component or service level would be more than enough, no differences would be noticeable in terms of performance in my view for most cases, so bending ourselves backwards to get fine-grained reactivity at all costs is definitively not worth it. However for applications with a centralized store pattern, this could actually become important because if we use signal() for the state object, then it means the whole application gets updated everytime anything changes. I still doubt it would be noticeable in most cases though, so your point stands. In the next video, I'm going to talk about a way of having deep signals without the store construct, so we can use a deep signal locally if needed. The only other advantage that i see of this type of constructs is the built in immutability which is nice, and that signal() does not provide by default. This inforced immutability could be a good thing if using signal-based change detection, and could have the practical benefit of removing a whole category of bugs from the code base (accidentally updating state directly without emitting a new signal value). Stay tuned for a new video probably early next week on this topic 👍😊
@@AngularUniversity I didn't mean *one* object/signal. Just that the sweet spot is probably between there and every property being a discreet source. I'm excited to see where it goes.
@@adambickford8720 I know what you mean. 👍 Something beyond signal() but with low boilerplate. signal() will be fine for most cases I believe. Stay tuned for the next video, I will show an alternative solution that I think is much closer to the sweetspot 👍
A quick guided tour on NgRx Signal Store, and the concept of Deep Signals, timestamps in the description 😊 No music after the intro, a shorter form video. Let me know if you enjoy these more, or prefer a lix of long and short format. Enjoy everyone!👍
Thanks for giving so much to the Angular community Vasco
You're welcome Johan, I'm happy to be of service 😊👍
Wow this is moving at some pace, it was only a few weeks ago we were discussing this requirement. I'm blown away with Angular it's just superb ❤
Yes, this truly is the Angular Renaissance 👍😊
Can you do a video on how to test SignalStores? And how to mock them when testing components that use SignalStores? Or can you provide some resources?
This is like attaching individual reducers to store in REDUX , but here we are attaching pure objets that are converted to signals automatically. Really mind blowing. So there is no need to do normalization.
Notice that the state is still kept internally, together with the signals that are created, and normalization still helps. There is a plugin for entities, for NgRx Signal Store too, I'm thinking of covering it in a future videos. 😊👍
@@AngularUniversity I am a heavy user of the concept entity adapter in REACT REDUX.
Waiting for your Signal Store based entity adapter video.
Thank you.
I have bought your course already in Udemy long back.
@@01binaryboyThank you, stay tuned for more videos and please enjoy the courses 😉
I do appreciate the dark theme in IDE, the lesson is more enjoyable to watch in this format
Thank you, dark theme rocks 😉 It's the theme Monokai Pro Webstorm 👍
Awesome content, Vasco. Angular developers are in good hands. Greetings from 39.6250° N, 19.9223° E
You're luck to live in Corfu, it must be wonderful to live in a beautiful island in the Mediterranean. 😉
Amazing video, Vasco!
Thank you. Stay tuned for more videos and Shorts!
i don't like that mixture of the store using services that make request, store just need to listen for changes and modify, i preffer effects
I think it's a matter of getting used to it, it's very new. 😉 With an Ngrx effect, a service is also used to call the backend and store data in the store. You can also plug the store into a RxJs chain and do something similar to an NgRx effect ngrx.io/guide/signals/rxjs-integration But I think that effects are better left for other things, if it's just calling the backend and getting data into the store, I personally prefer this new approach. 👍
Thanks a lot for the video! One quick question:
Is there a browser extension to see the actual state? For the NGRX store I always used Redux extension to see in the browser the store (and it's very helpful to debug), is there something like that for this signal store?
Thank you, there is so far no extension but there will be one soon I bet 👍
Hola! Excelente video. Y si quiero que el store persista a nivel de memoria? Ejemplo que no quiero que a cada rato se este invocando el get todos del service (imaginando que es un llamado a un API) ya que previamente en otro componente ya lo había cargado? Como sería esto?
Thank you it's awesome to hear that 😊 You can save the store content to local storage using an effect, and read it back at application startup time 👍
@@AngularUniversity muchas gracias !!! Ojalá puedas hacer un video explicando cómo hacerlo. Esta parte del manejo de store siempre se me ha sido complicado 🙏 con tus videos entiendo mejor. Muchas gracias por tu tiempo !!!!
Nice tutorial. Great thumbnail lol
Thank you 😉😊
Hi Vasco, just a question: if you reach out to a real backend you would use services that use httpclient, thus returning observables which, I assume, would be turned into signals using toSignal from the Angular RxJS interop package. Would you use toSignal in the service class already or inside the SignalStore?
Great question, actually I would call toPromise on the HTTP client for now, or the equivalent methods that replace it like firstValueFrom. Then use async / await to do HTTP requests, and send the value to a signal via set() or update(). I'm not sure if it's a good idea to handle HTTP responses as signals, as they might error out, and there is no such concept in signals. Using promises and setting the value in a signal is what I would do at this stage. The API of the HTTP client is going to be revisited down the line, together with other Angular APIs, in the common path of making RxJs optional in the framework. 👍Check out the latest Angular Q&A where the Angular team talks about the different options that you have for HTTP in Angular. 👍
Espetáculo
Obrigado 😉
I know the logo is physically centered but idk why it bugs me until they are visually centered 😅
You mean the AngularUniv logo on the TODO app on top?
The channel logo here on YT, btw great content!
@@tanishqmanuja Ohh I see what you mean 😊
What's the point w/o fine grained reactvity? Is auth.foo.bar() really that different from auth().foo.bar?
Great question 😉 by having different signals per nested property instead of just one signal for the whole auth object, different parts of the application can get notified only when and if the properties that they use change. For example, this way if a component only uses auth.user.name(), if auth.user.roles() changes then the component will not get updated. I go into detail on this fine-grained reactivity concept in this other video - ruclips.net/video/BasNj-w5RMI/видео.html Let me know if that helped?
@@AngularUniversity I get that its providing fine grained reactivity at the property level, and its pretty cool how it does so with such little boilerplate. But in practice, is it really that much more efficient to adopt as a general approach though?
Especially when its likely you're rendering more than one property from the object and ng will rerender the entire component anyway. (I'm assuming its smart enough to 'coalesce' the events)
I've never used this lib so its probably time to play with it and see. It just feels like it falls into the 'OnPush' realm of maybe too much accidental complexity as a default :)
@@adambickford8720 I really like that though-process of keeping things simple, it's my approach too. 😊 👍 I think if the application does not use a centralized store, then using signal() at the component or service level would be more than enough, no differences would be noticeable in terms of performance in my view for most cases, so bending ourselves backwards to get fine-grained reactivity at all costs is definitively not worth it. However for applications with a centralized store pattern, this could actually become important because if we use signal() for the state object, then it means the whole application gets updated everytime anything changes. I still doubt it would be noticeable in most cases though, so your point stands. In the next video, I'm going to talk about a way of having deep signals without the store construct, so we can use a deep signal locally if needed. The only other advantage that i see of this type of constructs is the built in immutability which is nice, and that signal() does not provide by default. This inforced immutability could be a good thing if using signal-based change detection, and could have the practical benefit of removing a whole category of bugs from the code base (accidentally updating state directly without emitting a new signal value). Stay tuned for a new video probably early next week on this topic 👍😊
@@AngularUniversity I didn't mean *one* object/signal. Just that the sweet spot is probably between there and every property being a discreet source. I'm excited to see where it goes.
@@adambickford8720 I know what you mean. 👍 Something beyond signal() but with low boilerplate. signal() will be fine for most cases I believe. Stay tuned for the next video, I will show an alternative solution that I think is much closer to the sweetspot 👍