I don't know if its your pace, or your depth of knowledge, but I find your videos very easy to take in. You have a real talent for conveying highly technical information into consumable content.
ปีที่แล้ว +2
I agree. Her narrative skill is TOP
ปีที่แล้ว +1
As well as the video editing (code writing + comments)
You were born to be a teacher. I just thank God for the Internet that allows you to reach thousands of students. Thank you for another amazing video!!! Subscribed.
Thanks for this, Deborah! I've been looking for a video that describes in simple terms how and where to combine RxJS and signals, and you've done a great job of that here! Appreciate the time and energy that you put into this!!
Great video with a great use case throughout. I think fromObservable is now toSignal and fromSignal is now toObservable in the angular/core/rx-interop.
Hi, as always great video with great explanation. One or two things that i would like you to show is / are : - template driven form with signals and if possible with reactive forms as well. - component child: input and output with signals Thanks
Thank you for the kind words! 🙏 Regarding forms, in talking to the Angular team recently they have not yet completed their thoughts on how signals will work with template driven or reactive forms. So there isn't anything yet on that topic. I'll keep an eye out for any discussions and post when there is something there. For parent/child components and input/outputs, they will play well with signals. I'll definitely cover that in an upcoming video. Thank you for the suggestions!
@@deborah_kurata Hi, with reactive forms, maybe do not make sense. But in previous video, you use ngmodel to connect signal on select element. So would be so different to work with template driven forms ?
Awesome, Deborah! Just wanted to say anyone who's has experience with Knockout JS should find it easier to grasp Angular Signals - they follow similar concept.
Using signals instead of observables in a component solves one of the biggest problems associated with observables: accessing the observable's value synchronously within the component. Thanks for the video!
Donno if my concept is correct or not: - The Signals are useful to simplify the data flow providing (Provider) - The Observables must be used to catch and work with data (Worker) The Observable must be hidden to the component which uses to listen to data changes only (Signals). In this video you didn't focus a lil part about error handling. However really great work and explaination skills!!
Thank you. I've created a set of samples in Stackblitz on error handling. I haven't yet had an opportunity to turn them into YT videos. You can find them here: stackblitz.com/@DeborahK/collections/angular-signal-error-handling-research
Hi Deborah, it s a awesome video first time ever did on rxjs and singnals combination. thank you so much. what about error handling and would like to display those errors on the component template like we have here errormessage proerty.
Thank you! Yes, error handling could use some attention! Some suggestions I've see use try/catch blocks, but those don't work with a declarative approach. Another suggestion I've seen is to wrap the returned object in another object that has the object and an error message. But AFAIK, nothing has been finalized on this yet. I'll work on a video as soon as I have more info. Thanks for the suggestion!
Thanks for this video and the rest in your series. They are great!! Do you have an example of using Signals with a POST method that has a request body?
Thank you! Is there a particular example you are working through? If so, could you post a link to a Stackblitz of the example (not your entire application) and I'll take a look.
Thanks for the kind words and the suggestion. It wouldn't be all that different from the Subject example provided in this video. But I'll put something together. Thanks again!
Variables: For data that you need to hold in the application, such as a path name. And for data that is displayed in the template via binding, but never changes. Such as a page title. Or for any other constant Signals: Any data that is displayed in the template via binding but can change. Any data that relies on and changes when other data changes (computed signal). Any data that you want to react to and perform an action. Observables: Asynchronous operations, such as http get/put/post or streaming operations where you must receive every emitted item, such keyboard events if you need every keystroke. The gray area: Responding to actions. We had previously done these with Subject/BehaviorSubject. We can now use signals instead. But if responding to the action requires an async operation (such as getting more data), or it requires receiving *every* change (not just the most recent value) then it may be easier to continue using Subject/BehaviorSubject.
Good suggestion! In the mean time, the short story is: - Create a user service - Define a signal in that service to hold the logged in user object with an initial value of null - When the user logs in, set that signal to the logged in user - The signal should then be accessible to all of the application as needed.
Since `selectedVehicle` is a member of singleton service, as far as I understand, it's value will persist even when the `VehicleListComponent` is destroyed, which might not be a desired behaviour in many cases. How to handle such scenarios? Should we provide the service at the component level for such use cases? Please correct me if my understanding is wrong.
I an application where vehicles are the main purpose of the application, defining the service as 'root' makes sense. But if it is a small part of a larger application and you want to ensure that the service is destroyed with the component, then yes, you use the providers array in the component instead of provided in root. Do you think it would be worth doing a video specifically on this topic?
@@deborah_kurata So, in my case I have two components on the same page and the user can switch between the two. Both need the same signal but I don't want the value of signal to persist when the user switches between the two. So I guess, I would need to provide the service at the component level so that both the components use different instances of the signal. Btw, thanks for the reply. Not sure if this is a common use case but yes, I think a video on this topic would be great. Also, I would like to thank you for making these videos. They are really helpful.
Great information on how to use signals. Could you show an example of how you could update the signal with new information from the server? For example, if a new vehicle became available, how would you have a button on the screen force the vehicles to refresh from the server? My current attempt is to use a Subject that can be "nexted" in the vehicles$ observable chain. Seems like there should be an easier way?
Thank you! Regarding your question, you can definitely replace the Subject with a signal. Then use toObservable to include the signal in your pipeline.
I put together a quick little demo here: stackblitz.com/edit/angular-signals-rxjs-deborah-hk2fah Basically: COMPONENT: onRefresh(): void { // Change the value of the signal // from true to false or false to true this.vehicleService.refresh.update(r => !r); } SERVICE: refresh = signal(true); private vehicles$ = toObservable(this.refresh).pipe( switchMap((doRefresh) => this.http.get(this.url).pipe( catchError(this.handleError), tap(() => console.log('Retrieved the data')), ) ) ); vehicles = toSignal(this.vehicles$, { initialValue: [], }); Would that work in your case?
So except for http calls which is unavoidable observable , we can replace all the other observable like subjects with signals , is it ? 🤔. And is that th new norm going to be ?
Thank you for watching the video! Http calls are not necessarily unavoidable. You can use fetch instead of HTTP Client to retrieve data using promises. Personally, I prefer HTTP Client (which as you said returns an observable). Using signals won't necessarily replace all Observables, especially when dealing with event-based actions. Things like tracking/reacting to keypresses, when you want every emitted value, you'll still want Observables. So yes, signals will replace many observables, especially those used to manage state. But we'll still want observables for event-based actions.
Awesome video, thanks a lot ! Your videos is really helping me on my Angular journey ! I have a question regarding the signal created inside the véhicule service when you call toSignal(). This line of code is triggering when the service is injected inside a component. Basically, how can I prevent this in the best way ? I mean with this approach I can’t choose when to trigger the request when I want because the véhicule signal will have the fetched data ? I’m still learning so this question may be a stupid one but I just want to learn this framework with the new signal feature ! Thank in advance and again, awesome video Deborah 👍🏻
Great to hear that it was useful! Thanks! If you want to trigger an HTTP request based on an action, you can define the action as a signal, then use toObservable to react to that signal and execute an Observable pipeline. Something like this: // When the selected user changes, get the user's tasks userTasks$ = toObservable(this.userService.selectedUserId).pipe( switchMap(userId => this.http.get(this.todoUrl + userId)), catchError(() => of([] as ToDo[])) // on any error, just return an empty array ); userTasks = toSignal(this.userTasks$, { initialValue: [] as ToDo[] }); Would something like that work for your case?
Hey Deborah, big long time fan of your videos here. What happens if you call the set method on the Signal that was created in the Service with the fromObservable method? Does it break the code?
Thank you! Since the making of this video, the team renamed `fromObservable` to `toSignal`. The `toSignal` method creates a *readonly* signal. So you can't call the set method on it to set a new value.
Thank you! Techniques such as NgRx will still be useful when an application has complex state management. And NgRx has already begun to embrace signals. Check out a summary here: dev.to/this-is-angular/signals-what-this-means-for-ngrx-eho
Hey!, very nice video illustrating a patterns of using rxjs with signals, thank you so much for the effort :) I was wondering though - while with RX we are usually retrieving the value from the async pipe to be used in our template, most commonly with *ngIf and using the "as" keyword, in your video you did not use it when changing to signals. any particular reason? Another, more general question - does signals offer better performance somehow compared with observables and async pipe? or are they just meant to make our presentational layer cleaner, for example makes the use of markForCheck from within the component almost entirely redundant, since we can use signal instead? I couldn't but notice the similarity between MOBX and signals, are signals inspired from it, but built in and work with angular natively? What was the main reason Angular team decided to support signals? Finally, do you think that in the future angular could be ridding zonejs for good?
Thank you! "you did not use it" - Are you referring to the "as" clause? As of now, signals don't support an "as" clause. Moving away from zone-based components to signal-based components means that the app will load more quickly (won't have to load zone.js). It will be smaller (won't have to load zone.js). And the app will feel more performant because it won't run change detection when it doesn't need to. This resource provides more information: github.com/angular/angular/discussions/49684 Yes, signals have been used by several other frameworks, such as Vue. You can implement the basic concept of signals in any language. Here is an article about implementing it in JavaScript: medium.com/codex/making-a-case-for-signals-in-javascript-edf9807f30dc The above referenced github link also outlines the reason the Angular team decided to support signals ... including their thought process and what other technologies they considered. Yes. In the FAQ in the above referenced document, the Angular team states that they do hope at some point in the future to be able to run "zoneless". Thanks again for your post!
@@deborah_kurata Hi, a correction the only frameworks that use signals implementation way are solidjs and preact. Vue is nowadays a Proxy native api base.
NgRx will still be useful when an application has complex state management. And NgRx has already begun to embrace signals. Check out a summary here: dev.to/this-is-angular/signals-what-this-means-for-ngrx-eho
Thanks as always for the great videos on these new features. One question I had and possibly created an anti-pattern for: how do you manage the developer's ability to change the WritableSignal from the component? I am comparing it to the BehaviorSubject pattern you have demonstrated in many of your videos where the methods updated the private BS (mutable) which was then accessed by the consumers through the public .toObservable() observable (immutable). This prevented writing directly to the BS from the component. However, the pattern you demonstrated here seems like it would allow a developer to .set() on the referenced WritableSignal from the component, would it not? To get around this, I instead made the WritableSignal private and then exposed a regular Signal with computed(), that just returned the value of the private WritableSignal. Do you agree with this pattern or how would you go about enforcing this in the same way that you have done in the past?
@@jurybalikov7063 that wouldn't solve the problem. I did find that a WritableSignal has an asReadOnly() method, and that was what the equivalent solution was.
I don't agree with exposing a network data source as a signal. This is because of the requirement to have an initial value. While that initial value is no problem in the template where it will just re-update upon the network value coming in, there is a problem with effects expecting the network value. For example, if I had a form field, a default value for which would be calculated when it is null; if the calculation (effect) were to use your signal, it would calculate a value using the wrong data (empty array instead of database data). For this reason, I think the whole toSignal paradigm is fundamentally flawed and signal based arrangements should never use such asynchronous sources, which is so limiting to signals that you may as well just use rxjs alone.
I got a stroke looking at the VehicleService... Why are people using Signals to add a new layer of complexity by mixing it with RxJs for REST request? HttpClient get, post, delete etc. will close automatically. There is no need for unsubscribing or creating a RxJS operator mess. Then people wonder why they have performance issues...
Since signals are meant for binding to the UI and must be synchronous, and RxJS is for retrieving the data, how would you get the data out of RxJS and into signals? And just FYI, see the later answers to the question here: stackoverflow.com/questions/35042929/is-it-necessary-to-unsubscribe-from-observables-created-by-http-methods
I have "hard head" - why use them? I am happy to have http requests in services and just subscribe in components. That's it. To use signals instead of subjects? - not big difference.
Yep. There is a lot there. And note that since recording the video, the Angular team changed "fromObservable" to "toSignal" and "fromSignal" to "toObservable".
Thanks for the video! I tried to do my own project using inspiration from this video. Why is it that I can not import fromObservable? I just get this error message: "'"@angular/core/rxjs-interop"' has no exported member named 'fromObservable'. Did you mean 'toObservable'?"
Thank you for watching! Yes, they changed the API. fromObservable 👉 toSignal and fromSignal 👉 toObservable I added a NOTE about it in the video notes. I also posted a second video about it. See the next video in the playlist "Changes to Signal and RxJS Interop in Angular RC1" here: th-cam.com/video/xQIOWkBe5wQ/w-d-xo.html So fromObservable is now toSignal.
Hi Deborah, I really enjoy and learn so much from your videos! wouldn't it be better to modify the vehicle-detail.component.html by using alias at the top like *ngIf="vehicle() as vehicle"?
Thank you, glad you like the content. Yeah, I use the lighter theme because I think the code is easier to see when in a video ... especially on a smaller device.
I don't know if its your pace, or your depth of knowledge, but I find your videos very easy to take in. You have a real talent for conveying highly technical information into consumable content.
I agree. Her narrative skill is TOP
As well as the video editing (code writing + comments)
I agree.
She sounds like a robot.
You were born to be a teacher. I just thank God for the Internet that allows you to reach thousands of students. Thank you for another amazing video!!! Subscribed.
That is so very nice of you to say! Thank you! 😊
Very nice video on signal and Rxjs, the best part is you take the problems practically and cover all the scenarios. Thanks for doing this video.
Glad it was helpful! Thank you!
I loved your analogy of "we need to open the box" Great way to remember that step
Great to hear it was useful. Thanks!
Thanks for this, Deborah! I've been looking for a video that describes in simple terms how and where to combine RxJS and signals, and you've done a great job of that here! Appreciate the time and energy that you put into this!!
Glad to hear it was useful. Thanks!
How glad I am that I found this channel. Now this is my mecca of knowledge))
Me too! 😊 Hope it continues to be useful!
Great video with a great use case throughout. I think fromObservable is now toSignal and fromSignal is now toObservable in the angular/core/rx-interop.
Thank you!
And yes, you are correct. I did a second video that covers the changes here: th-cam.com/video/xQIOWkBe5wQ/w-d-xo.html
Thanks to both of you !
You're brilliant as always. Thanks Deborah!
Thank you! 🙏
Hi, as always great video with great explanation.
One or two things that i would like you to show is / are :
- template driven form with signals and if possible with reactive forms as well.
- component child: input and output with signals
Thanks
Thank you for the kind words! 🙏
Regarding forms, in talking to the Angular team recently they have not yet completed their thoughts on how signals will work with template driven or reactive forms. So there isn't anything yet on that topic. I'll keep an eye out for any discussions and post when there is something there.
For parent/child components and input/outputs, they will play well with signals. I'll definitely cover that in an upcoming video.
Thank you for the suggestions!
@@deborah_kurata Hi, with reactive forms, maybe do not make sense. But in previous video, you use ngmodel to connect signal on select element. So would be so different to work with template driven forms ?
My understanding is that signals don't currently work well with ngModel ... but there is work to support that scenario expected in a later release.
You are amazing ! so underrated ! Hope you great successs
Thank you so much!! 😊
Thx a lot, Deborah! You are an excellent teacher! ❤
Thank you so much!
Awesome, Deborah! Just wanted to say anyone who's has experience with Knockout JS should find it easier to grasp Angular Signals - they follow similar concept.
Thanks!
Deborah, you are sooo good! Thank-you
That is so kind. Thank you! 🙏🏼
youre the best teacher ever
That is very kind of you. Thank you so much!
Using signals instead of observables in a component solves one of the biggest problems associated with observables: accessing the observable's value synchronously within the component. Thanks for the video!
Glad it was useful! Thank you!
Great Video. All my questions got answered.
That's great to hear! Thank you!
please more videos!!
thank you so much!!!
Have you seen my latest? th-cam.com/video/rHQa4SpekaA/w-d-xo.html
Marvelous! I cannot wait to share with my team!
Excellent! Thanks!
This was AMAZING! Thank you so much!
Thanks!
Donno if my concept is correct or not:
- The Signals are useful to simplify the data flow providing (Provider)
- The Observables must be used to catch and work with data (Worker)
The Observable must be hidden to the component which uses to listen to data changes only (Signals).
In this video you didn't focus a lil part about error handling.
However really great work and explaination skills!!
Thank you.
I've created a set of samples in Stackblitz on error handling. I haven't yet had an opportunity to turn them into YT videos.
You can find them here: stackblitz.com/@DeborahK/collections/angular-signal-error-handling-research
Hi Deborah, it s a awesome video first time ever did on rxjs and singnals combination. thank you so much. what about error handling and would like to display those errors on the component template like we have here errormessage proerty.
Thank you!
Yes, error handling could use some attention! Some suggestions I've see use try/catch blocks, but those don't work with a declarative approach.
Another suggestion I've seen is to wrap the returned object in another object that has the object and an error message.
But AFAIK, nothing has been finalized on this yet. I'll work on a video as soon as I have more info.
Thanks for the suggestion!
@@deborah_kurata thank you for your response.
It wasn't just good, it was fantastic. 😍👌👏
Thank you so much 😀
Great content as usual!
Thank you! 😊
Thanks for this video and the rest in your series. They are great!! Do you have an example of using Signals with a POST method that has a request body?
Thank you!
Is there a particular example you are working through? If so, could you post a link to a Stackblitz of the example (not your entire application) and I'll take a look.
@draylegend Not sure if you'll get notified of this message... I looked at your stackblitz. Do you still need help with it?
Thank you Deborah! I learned a lot from you 🙏
That's great to hear! Thank you and all the best! 😊
Amazing videos like always 😃
Thank you so much 😀
Great content !!
Suggestion: Video about the replacement of the behaviorSubject in a service by a signal
Thanks for the kind words and the suggestion.
It wouldn't be all that different from the Subject example provided in this video. But I'll put something together. Thanks again!
Here it is: th-cam.com/video/a6XKMj-WRhM/w-d-xo.html
Thanks so much, it clears a lot of questions that I had !!
when to use observables, signals or normal variables? what type of situation is best suited for each case?
Variables: For data that you need to hold in the application, such as a path name. And for data that is displayed in the template via binding, but never changes. Such as a page title. Or for any other constant
Signals: Any data that is displayed in the template via binding but can change. Any data that relies on and changes when other data changes (computed signal). Any data that you want to react to and perform an action.
Observables: Asynchronous operations, such as http get/put/post or streaming operations where you must receive every emitted item, such keyboard events if you need every keystroke.
The gray area: Responding to actions. We had previously done these with Subject/BehaviorSubject. We can now use signals instead. But if responding to the action requires an async operation (such as getting more data), or it requires receiving *every* change (not just the most recent value) then it may be easier to continue using Subject/BehaviorSubject.
Can you prepare a video on how to maintain the loggedIn user using Angular Signal?
Good suggestion!
In the mean time, the short story is:
- Create a user service
- Define a signal in that service to hold the logged in user object with an initial value of null
- When the user logs in, set that signal to the logged in user
- The signal should then be accessible to all of the application as needed.
Great explanation, thank you! 👏
Glad it was helpful!
Since `selectedVehicle` is a member of singleton service, as far as I understand, it's value will persist even when the `VehicleListComponent` is destroyed, which might not be a desired behaviour in many cases. How to handle such scenarios? Should we provide the service at the component level for such use cases? Please correct me if my understanding is wrong.
I an application where vehicles are the main purpose of the application, defining the service as 'root' makes sense. But if it is a small part of a larger application and you want to ensure that the service is destroyed with the component, then yes, you use the providers array in the component instead of provided in root.
Do you think it would be worth doing a video specifically on this topic?
@@deborah_kurata So, in my case I have two components on the same page and the user can switch between the two. Both need the same signal but I don't want the value of signal to persist when the user switches between the two. So I guess, I would need to provide the service at the component level so that both the components use different instances of the signal.
Btw, thanks for the reply. Not sure if this is a common use case but yes, I think a video on this topic would be great.
Also, I would like to thank you for making these videos. They are really helpful.
Great information on how to use signals. Could you show an example of how you could update the signal with new information from the server? For example, if a new vehicle became available, how would you have a button on the screen force the vehicles to refresh from the server? My current attempt is to use a Subject that can be "nexted" in the vehicles$ observable chain. Seems like there should be an easier way?
Thank you!
Regarding your question, you can definitely replace the Subject with a signal. Then use toObservable to include the signal in your pipeline.
I put together a quick little demo here: stackblitz.com/edit/angular-signals-rxjs-deborah-hk2fah
Basically:
COMPONENT:
onRefresh(): void {
// Change the value of the signal
// from true to false or false to true
this.vehicleService.refresh.update(r => !r);
}
SERVICE:
refresh = signal(true);
private vehicles$ = toObservable(this.refresh).pipe(
switchMap((doRefresh) =>
this.http.get(this.url).pipe(
catchError(this.handleError),
tap(() => console.log('Retrieved the data')),
)
)
);
vehicles = toSignal(this.vehicles$, {
initialValue: [],
});
Would that work in your case?
So except for http calls which is unavoidable observable , we can replace all the other observable like subjects with signals , is it ? 🤔. And is that th new norm going to be ?
Thank you for watching the video!
Http calls are not necessarily unavoidable. You can use fetch instead of HTTP Client to retrieve data using promises. Personally, I prefer HTTP Client (which as you said returns an observable).
Using signals won't necessarily replace all Observables, especially when dealing with event-based actions. Things like tracking/reacting to keypresses, when you want every emitted value, you'll still want Observables.
So yes, signals will replace many observables, especially those used to manage state. But we'll still want observables for event-based actions.
Awesome video, thanks a lot ! Your videos is really helping me on my Angular journey !
I have a question regarding the signal created inside the véhicule service when you call toSignal().
This line of code is triggering when the service is injected inside a component. Basically, how can I prevent this in the best way ? I mean with this approach I can’t choose when to trigger the request when I want because the véhicule signal will have the fetched data ?
I’m still learning so this question may be a stupid one but I just want to learn this framework with the new signal feature !
Thank in advance and again, awesome video Deborah 👍🏻
Great to hear that it was useful! Thanks!
If you want to trigger an HTTP request based on an action, you can define the action as a signal, then use toObservable to react to that signal and execute an Observable pipeline. Something like this:
// When the selected user changes, get the user's tasks
userTasks$ = toObservable(this.userService.selectedUserId).pipe(
switchMap(userId => this.http.get(this.todoUrl + userId)),
catchError(() => of([] as ToDo[])) // on any error, just return an empty array
);
userTasks = toSignal(this.userTasks$, { initialValue: [] as ToDo[] });
Would something like that work for your case?
That’s exactly what I needed thanks you so much 😁 And you just released a video on this topic awesome 🤩
Looks like "fromObservable" method name has been changed to "toSignal" in angular 17
Yes, that's correct. It's a bummer that we can't "update" a YT video. But I did add this: th-cam.com/video/xQIOWkBe5wQ/w-d-xo.html
What happens to the error handling?
Hey Deborah, big long time fan of your videos here. What happens if you call the set method on the Signal that was created in the Service with the fromObservable method? Does it break the code?
Thank you!
Since the making of this video, the team renamed `fromObservable` to `toSignal`. The `toSignal` method creates a *readonly* signal. So you can't call the set method on it to set a new value.
Hi Deborah,
Will Signal have an impact on how we use Stores for state management?
thx and great job!
Thank you!
Techniques such as NgRx will still be useful when an application has complex state management. And NgRx has already begun to embrace signals. Check out a summary here: dev.to/this-is-angular/signals-what-this-means-for-ngrx-eho
@@deborah_kurata thanks a lot for your response, can't wait for all your future videos 😍
very helpful. Thank you 🙂
Great to hear! Thanks!
Nice and perfect. thank you.
Glad you like it! Thanks!
Hey!, very nice video illustrating a patterns of using rxjs with signals, thank you so much for the effort :)
I was wondering though - while with RX we are usually retrieving the value from the async pipe to be used in our template, most commonly with *ngIf and using the "as" keyword, in your video you did not use it when changing to signals. any particular reason?
Another, more general question - does signals offer better performance somehow compared with observables and async pipe? or are they just meant to make our presentational layer cleaner, for example makes the use of markForCheck from within the component almost entirely redundant, since we can use signal instead?
I couldn't but notice the similarity between MOBX and signals, are signals inspired from it, but built in and work with angular natively?
What was the main reason Angular team decided to support signals?
Finally, do you think that in the future angular could be ridding zonejs for good?
Thank you!
"you did not use it" - Are you referring to the "as" clause? As of now, signals don't support an "as" clause.
Moving away from zone-based components to signal-based components means that the app will load more quickly (won't have to load zone.js). It will be smaller (won't have to load zone.js). And the app will feel more performant because it won't run change detection when it doesn't need to. This resource provides more information: github.com/angular/angular/discussions/49684
Yes, signals have been used by several other frameworks, such as Vue. You can implement the basic concept of signals in any language. Here is an article about implementing it in JavaScript: medium.com/codex/making-a-case-for-signals-in-javascript-edf9807f30dc
The above referenced github link also outlines the reason the Angular team decided to support signals ... including their thought process and what other technologies they considered.
Yes. In the FAQ in the above referenced document, the Angular team states that they do hope at some point in the future to be able to run "zoneless".
Thanks again for your post!
@@deborah_kurata thank you so much for the detailed response and the additional resources!
@@deborah_kurata Hi, a correction the only frameworks that use signals implementation way are solidjs and preact. Vue is nowadays a Proxy native api base.
Signal + rxjs is cool. And signal with NGRX. Is a good combination?
NgRx will still be useful when an application has complex state management. And NgRx has already begun to embrace signals. Check out a summary here: dev.to/this-is-angular/signals-what-this-means-for-ngrx-eho
Awesome video
Thank you! 🙏
Thanks as always for the great videos on these new features. One question I had and possibly created an anti-pattern for: how do you manage the developer's ability to change the WritableSignal from the component? I am comparing it to the BehaviorSubject pattern you have demonstrated in many of your videos where the methods updated the private BS (mutable) which was then accessed by the consumers through the public .toObservable() observable (immutable). This prevented writing directly to the BS from the component.
However, the pattern you demonstrated here seems like it would allow a developer to .set() on the referenced WritableSignal from the component, would it not? To get around this, I instead made the WritableSignal private and then exposed a regular Signal with computed(), that just returned the value of the private WritableSignal. Do you agree with this pattern or how would you go about enforcing this in the same way that you have done in the past?
A bit late, but that's solved really easily.
readonly #writable = signal();
readonly exposed = computed(() => #writable());
@@jurybalikov7063 that wouldn't solve the problem. I did find that a WritableSignal has an asReadOnly() method, and that was what the equivalent solution was.
No.. how to use ngrx and signals together with nestjs backend
Awesome ❤
Thanks!
I don't agree with exposing a network data source as a signal. This is because of the requirement to have an initial value. While that initial value is no problem in the template where it will just re-update upon the network value coming in, there is a problem with effects expecting the network value. For example, if I had a form field, a default value for which would be calculated when it is null; if the calculation (effect) were to use your signal, it would calculate a value using the wrong data (empty array instead of database data). For this reason, I think the whole toSignal paradigm is fundamentally flawed and signal based arrangements should never use such asynchronous sources, which is so limiting to signals that you may as well just use rxjs alone.
very good
Thanks
Thank ❤
I got a stroke looking at the VehicleService...
Why are people using Signals to add a new layer of complexity by mixing it with RxJs for REST request?
HttpClient get, post, delete etc. will close automatically. There is no need for unsubscribing or creating a RxJS operator mess.
Then people wonder why they have performance issues...
Since signals are meant for binding to the UI and must be synchronous, and RxJS is for retrieving the data, how would you get the data out of RxJS and into signals?
And just FYI, see the later answers to the question here: stackoverflow.com/questions/35042929/is-it-necessary-to-unsubscribe-from-observables-created-by-http-methods
I have "hard head" - why use them? I am happy to have http requests in services and just subscribe in components. That's it. To use signals instead of subjects? - not big difference.
thanks
Thank you for watching!
Wow that was too much knowledge to grasp. I will need to check the code now😅.
Yep. There is a lot there.
And note that since recording the video, the Angular team changed "fromObservable" to "toSignal" and "fromSignal" to "toObservable".
Thanks for the video! I tried to do my own project using inspiration from this video. Why is it that I can not import fromObservable? I just get this error message: "'"@angular/core/rxjs-interop"' has no exported member named 'fromObservable'. Did you mean 'toObservable'?"
Thank you for watching!
Yes, they changed the API. fromObservable 👉 toSignal and fromSignal 👉 toObservable
I added a NOTE about it in the video notes. I also posted a second video about it. See the next video in the playlist "Changes to Signal and RxJS Interop in Angular RC1" here: th-cam.com/video/xQIOWkBe5wQ/w-d-xo.html
So fromObservable is now toSignal.
@@deborah_kurata Thanks so much!
очень познавательно, спасибо
Спасибо!
Hi Deborah,
I really enjoy and learn so much from your videos!
wouldn't it be better to modify the vehicle-detail.component.html by using alias at the top like *ngIf="vehicle() as vehicle"?
Thank you!
AFAIK, the "as" syntax doesn't currently work with signals. But this might make a good future request!
Great content !
The white vs code theme is still causing my eyes to hurt. 🫥
Thank you, glad you like the content.
Yeah, I use the lighter theme because I think the code is easier to see when in a video ... especially on a smaller device.
Always a great fannof yours.. do you have any github link for source code you used 🙏