This is literally the best general and practical explanation for this in the whole internet. I came here already knowing the difference, but still enjoyed every moment of it.
Good video, short enough but good. Always love your video, explain a knowledge in a short video. I tried on my side, yes, works and understand. Thanks.
Thanks for the crystal clear explanation. Its been a year working on Angular and I was living in a delusion about Private properties😵 I wonder how many things I am doing wrong already, please get a course on pluralsight or youtube where you cover the fundamentals of latest Angular
In most cases, uses private is "good enough". On most good teams, you shouldn't have to worry about another team member trying to access properties they shouldn't. But I am considering doing a new v18 "Angular: Getting Started". That would be of interest?
Glad it was helpful. And for many scenarios, the difference doesn't matter because the team most likely won't try to access private fields in that way. But it's good to be aware. :-)
An interesting addition to javascript. The error message at @6:30 could be improved, though. Since #productUrl can't be accessed, it should not be recommended. This looks like it is a typescript message (TS2551), correct? Templates having access to only public properties has been an annoyance of mine for ages. To me templates feel like they should be part of the class and have access to private members. The one stylistic advantage I see is that you can make services private and thus prevent an abuse of service code in templates. Always love your conference talks, thanks for these mini-lessons.
Thank you for providing such informations, i am a grt fan of yours..i learned angular from your plural sight tutorial, very clear and tonthe point explanation.
I didn't know this, thanks for the video. I really don't see using this in my projects (why I use Typescript), but if I did, it seems annoying that I have to use # to access the field even inside the class where it's declared.
After doing this video, I *thought* I would shift to using this syntax. But I have not. I agree that it is annoying to use the # everywhere. And for the types of apps I create, the "true privacy" isn't really needed.
Great question! Primarily, they don't want to implement a breaking change. If you *do* use `#` in your TypeScript, TypeScript *does* transpile that to `#` in JavaScript. See this for more information: www.typescriptlang.org/docs/handbook/2/classes.html#private, especially the end of "caveats" section.
Thank you! v16. Though I didn't think I covered anything that would be version specific? Was there a particular feature you're looking at? I did use standalone components, that were new in v14.
Great content Deborah, thank you so much for this, it was really helpful. I would like to know what Visual Studio extensions do you have/recommend to work with Angular?
Thank you! Great to hear it was helpful! I use the Angular Language Service extension. And I sometimes enable the GitHub Copilot extension. That's all I use.
I honestly don't think that there is a lot of real use case where you really want to hide the private properties. Maybe if you are an library developper... and even then... And I think that it should be the role the Typescript transpiler to transform private properties to #properties.
It may be useful for encapsulation ... especially for a large project with lots of team members. No one may try to do something nefariously, but someone may try to access a property that is being more carefully managed in the service. (But you could argue that `private` would be good enough for that.) From what I've seen, the TypeScript team sees the use cases for both `private` and `#`. So I don't think there is the intention of replacing one with the other at compile time. See this TypeScript documentation for more information: www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#ecmascript-private-fields
Great content as always .. are u planing to make angular 16 (signals and ssr topics) course in pluralsight or youtube ? i watched most of your courses its really good thanks
Pluralsight won't allow me to update the "Getting Started" course. They plan to retire it. When they do, I'm considering updating the content and posting it to YT. Would that be useful? Or are you primarily interesting in just the new features? (I have quite a few signals videos already posted to this channel.)
Deborah Kurata i already took your getting started course and the rxjs .. what i meant is a new course similar to the rxjs one but with signals and also cover new features of angular i think this would be interesting course .. and thanks ;)
I don’t see me using this myself. When you use Typescript you’re opting in to it’s way of type checking. Can you cheat the typing you get with Typescript? Sure. But if you are doing that then why are you using Typescript? Personally I like seeing the ‘private’ keyword.
Definitely that `private` keyword is more readable. And technically you aren't cheating the typing. The TypeScript docs covers this here: www.typescriptlang.org/docs/handbook/2/classes.html#private But I agree. I thought after doing this post I would start using the hash in my work ... but I find that private is just easier to read and doesn't require the hash on the variable name everywhere.
Currently, Pluralsight *owns* the content that it has. We are not allowed to post it anywhere else. However, that changes when Pluralsight retires a course, which for this course is expected to happen some time later this summer. At that point, I'm considering updating the content and reposting it on TH-cam.
vscode can generate getter and setter when I use "private _name" by double click the variable name > right click > refractor > generate get/set but when I use "#name" there is no option to generate getter and setter
Interesting ... looks like the VS Code refactor feature doesn't understand the # syntax as a property that can be refactored. Thanks for pointing that out!
Makes sense if you aren't worried about the values getting updated at runtime. And you are right ... A seemingly random # vs "private readonly" ... the "private readonly" would definitely win on readability!
Hey Deborah, do you have any videos in regards to passing observables from a parent to child? I've done two ways and not sure which ones correct. 1) pass the observable as an @Input in the child component so: @Input data$: observable. And then in the html you just pass the data source to that observable. The other way i just recently found was doing an @Input of the actual data the observable returns, but in the html of the parent you call the async pipe like . Which way is better?
For most of my scenarios, I've used "option 3": I've defined a service with the Observable and accessed that service from both parent and child. So in a service: data$ = this.http.get(...); And in both the parent and child: data$ = this.service.data$; That way all of the code shares the same data source and it does not need to be passed from the parent to the child.
@@deborah_kurata Thank you for that response! How does that work with reusable components? For instance, in our home component we create a new child component instance ~6 times. So: home.component.html -> we use tag 6 times to render 6 different table instances. Each instance we pass along different data (hence the parent to child), this doesn't sound possible doing the service way, correct? Because if we don't pass the data, how will our 1 child component know which data to use between 6 different data sets?
You can do this by registering the service in the component instead of registering it in "root". That way each component instance gets its own service instance. (Sorry, I don't seem to always get notifications when someone replies to my posts. So I didn't see this until I went to look for it today.)
That *could* break existing code. But if your code is targeting ES2022, TypeScript will transpile the `#` to the JavaScript `#`. See this for more information: www.typescriptlang.org/docs/handbook/2/classes.html#private Be sure to read down to the "Caveats" section.
In all my projects were private readonly, thats interesting how now it will be created. Is it posssible created somekind connection beetween ts private readonly to # symbol to still use readable from ts and functionality of js?
I would guess that there would not be a change to support this due to concern over backward compatibility. You can see what the TypeScript documentation says about it here: www.typescriptlang.org/docs/handbook/2/classes.html#private Look for the "Caveats" section of that document.
Not instead of ... we still use TypeScript for our Angular applications. But by using the native JavaScript syntax, when the code is transpiled from TypeScript to JavaScript the # syntax is compiled into the # JavaScript syntax. TypeScript has had support for using the hash since TypeScript v3.8: www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#ecmascript-private-fields (even when the JavaScript feature was only in stage-3 proposal stage). There is more info here: www.typescriptlang.org/docs/handbook/2/classes.html#private Thanks for your post!
is there anyway to hide the url from user client. for example to hide the url that I want to request from the server. even not show in the network panel. thanks
When issuing an HTTP request, you don't have to show the URL in the address bar. (It won't show in the address bar by default.) But as you mentioned, it will appear in the network panel.
Here is a link to a discussion about this topic: stackoverflow.com/questions/54150743/it-is-possible-to-hide-the-request-url-from-in-the-chrome-web-inspector-network
Agreed, the readability is much better with private or private readonly. Problem with underscore is it's purely convention and doesn't mean anything to the compiler or language services. But if your team all follow the convention, and maybe create a LINT rule for it, it could work.
This is literally the best general and practical explanation for this in the whole internet. I came here already knowing the difference, but still enjoyed every moment of it.
Wow! That is kind of you to say. Thank you so much! 😊
Good video, short enough but good. Always love your video, explain a knowledge in a short video.
I tried on my side, yes, works and understand. Thanks.
Great to hear! Thank you!
Very nice. I was confused when this first came out and why I would use it. Very informative!
So glad to hear it was useful! Thanks!
Just a few words to thank you for the content you share. Very valuable. That's it! Have a great day :)
I appreciate that! Thank you!
Thanks for the crystal clear explanation.
Its been a year working on Angular and I was living in a delusion about Private properties😵
I wonder how many things I am doing wrong already, please get a course on pluralsight or youtube where you cover the fundamentals of latest Angular
In most cases, uses private is "good enough". On most good teams, you shouldn't have to worry about another team member trying to access properties they shouldn't.
But I am considering doing a new v18 "Angular: Getting Started". That would be of interest?
@@deborah_kurata For sure
@@deborah_kurata Nothing can be better then that for the Angular community.
🤗😄
Thanks so much for this knowlege. All this while, i had no idea TS's private wasnt so private after all
Glad it was helpful. And for many scenarios, the difference doesn't matter because the team most likely won't try to access private fields in that way. But it's good to be aware. :-)
An interesting addition to javascript. The error message at @6:30 could be improved, though. Since #productUrl can't be accessed, it should not be recommended. This looks like it is a typescript message (TS2551), correct?
Templates having access to only public properties has been an annoyance of mine for ages. To me templates feel like they should be part of the class and have access to private members. The one stylistic advantage I see is that you can make services private and thus prevent an abuse of service code in templates.
Always love your conference talks, thanks for these mini-lessons.
Thank you for providing such informations, i am a grt fan of yours..i learned angular from your plural sight tutorial, very clear and tonthe point explanation.
Thank you for the kind words!
Thank you for great explanation!
Thanks! 😊
Wow. I did not know this at all. Thank you so much!
Glad it was useful!
I didn't know this, thanks for the video. I really don't see using this in my projects (why I use Typescript), but if I did, it seems annoying that I have to use # to access the field even inside the class where it's declared.
After doing this video, I *thought* I would shift to using this syntax. But I have not. I agree that it is annoying to use the # everywhere. And for the types of apps I create, the "true privacy" isn't really needed.
Helpful! So...why doesn't Typescript simply transpile private to the native # approach?
Great question!
Primarily, they don't want to implement a breaking change. If you *do* use `#` in your TypeScript, TypeScript *does* transpile that to `#` in JavaScript.
See this for more information: www.typescriptlang.org/docs/handbook/2/classes.html#private, especially the end of "caveats" section.
Great explanation & demonstration!
Glad it was helpful!
Thank you for this video. subscribed!!!
Awesome, thank you!
Neetly explained.. Thank you so much
You are welcome 😊 Thank you for watching!
I use "protected" access modifier for the component properties if I need to show them in the template. Better than public
Great explanations, thanks.
Thank you!
Thank you! Your explanations and examples are very helpful. Quick question - what version of Angular are you using here?
Thank you!
v16. Though I didn't think I covered anything that would be version specific? Was there a particular feature you're looking at?
I did use standalone components, that were new in v14.
Great content Deborah, thank you so much for this, it was really helpful. I would like to know what Visual Studio extensions do you have/recommend to work with Angular?
Thank you! Great to hear it was helpful!
I use the Angular Language Service extension. And I sometimes enable the GitHub Copilot extension. That's all I use.
Nice explaination! Thank you!
Thank you!
Thank you for another great lesson 🙌
Glad you liked it! Thanks for watching!
Good information❤
Thank you!
Thnaks...very informative
Glad it was helpful!
Great! Thank you for your share 👍
Thank you for watching!
Amazing video🙌
Thank you 🙏
Great as usual
Thanks! 🙏
Great video. Very helpful.
Glad it was helpful! Thank you!
I honestly don't think that there is a lot of real use case where you really want to hide the private properties. Maybe if you are an library developper... and even then...
And I think that it should be the role the Typescript transpiler to transform private properties to #properties.
It may be useful for encapsulation ... especially for a large project with lots of team members. No one may try to do something nefariously, but someone may try to access a property that is being more carefully managed in the service. (But you could argue that `private` would be good enough for that.)
From what I've seen, the TypeScript team sees the use cases for both `private` and `#`. So I don't think there is the intention of replacing one with the other at compile time.
See this TypeScript documentation for more information: www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#ecmascript-private-fields
Great content as always .. are u planing to make angular 16 (signals and ssr topics) course in pluralsight or youtube ? i watched most of your courses its really good thanks
Pluralsight won't allow me to update the "Getting Started" course. They plan to retire it. When they do, I'm considering updating the content and posting it to YT.
Would that be useful? Or are you primarily interesting in just the new features? (I have quite a few signals videos already posted to this channel.)
Deborah Kurata i already took your getting started course and the rxjs .. what i meant is a new course similar to the rxjs one but with signals and also cover new features of angular i think this would be interesting course .. and thanks ;)
looooove ur videos , thank u sooo much
Thank you for watching!
I don’t see me using this myself. When you use Typescript you’re opting in to it’s way of type checking. Can you cheat the typing you get with Typescript? Sure. But if you are doing that then why are you using Typescript? Personally I like seeing the ‘private’ keyword.
Definitely that `private` keyword is more readable.
And technically you aren't cheating the typing. The TypeScript docs covers this here: www.typescriptlang.org/docs/handbook/2/classes.html#private
But I agree. I thought after doing this post I would start using the hash in my work ... but I find that private is just easier to read and doesn't require the hash on the variable name everywhere.
You are a champ. thanks
Thank you!
valuable 8.35 minutes in my lifetime.
That is kind of you to say. Thank you.
Hey Deborah Kurata,do you have the same content on Getting Started with Angular same as the one in Plural Sight available to students?
Currently, Pluralsight *owns* the content that it has. We are not allowed to post it anywhere else. However, that changes when Pluralsight retires a course, which for this course is expected to happen some time later this summer. At that point, I'm considering updating the content and reposting it on TH-cam.
vscode can generate getter and setter when I use "private _name"
by double click the variable name > right click > refractor > generate get/set
but when I use "#name" there is no option to generate getter and setter
Interesting ... looks like the VS Code refactor feature doesn't understand the # syntax as a property that can be refactored.
Thanks for pointing that out!
i still think "private readonly" is still the way to go, it's really readable and does the same thing except at runtime
Makes sense if you aren't worried about the values getting updated at runtime.
And you are right ... A seemingly random # vs "private readonly" ... the "private readonly" would definitely win on readability!
Hey Deborah, do you have any videos in regards to passing observables from a parent to child? I've done two ways and not sure which ones correct. 1) pass the observable as an @Input in the child component so: @Input data$: observable. And then in the html you just pass the data source to that observable. The other way i just recently found was doing an @Input of the actual data the observable returns, but in the html of the parent you call the async pipe like . Which way is better?
For most of my scenarios, I've used "option 3": I've defined a service with the Observable and accessed that service from both parent and child.
So in a service:
data$ = this.http.get(...);
And in both the parent and child:
data$ = this.service.data$;
That way all of the code shares the same data source and it does not need to be passed from the parent to the child.
@@deborah_kurata Thank you for that response! How does that work with reusable components? For instance, in our home component we create a new child component instance ~6 times. So: home.component.html -> we use tag 6 times to render 6 different table instances. Each instance we pass along different data (hence the parent to child), this doesn't sound possible doing the service way, correct? Because if we don't pass the data, how will our 1 child component know which data to use between 6 different data sets?
You can do this by registering the service in the component instead of registering it in "root". That way each component instance gets its own service instance.
(Sorry, I don't seem to always get notifications when someone replies to my posts. So I didn't see this until I went to look for it today.)
Would there be any disadvantage for typescript to change how private properties are transpiled to make use of the Javascript # modifier too?
That *could* break existing code. But if your code is targeting ES2022, TypeScript will transpile the `#` to the JavaScript `#`.
See this for more information: www.typescriptlang.org/docs/handbook/2/classes.html#private
Be sure to read down to the "Caveats" section.
Nice! 😊
Thanks! 😄
In all my projects were private readonly, thats interesting how now it will be created. Is it posssible created somekind connection beetween ts private readonly to # symbol to still use readable from ts and functionality of js?
I would guess that there would not be a change to support this due to concern over backward compatibility.
You can see what the TypeScript documentation says about it here: www.typescriptlang.org/docs/handbook/2/classes.html#private
Look for the "Caveats" section of that document.
Very nice. Happy 2024.
Thank you! Cheers!
So it's all about native JavaScript features instead TypeScript?
Not instead of ... we still use TypeScript for our Angular applications. But by using the native JavaScript syntax, when the code is transpiled from TypeScript to JavaScript the # syntax is compiled into the # JavaScript syntax.
TypeScript has had support for using the hash since TypeScript v3.8: www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#ecmascript-private-fields (even when the JavaScript feature was only in stage-3 proposal stage).
There is more info here: www.typescriptlang.org/docs/handbook/2/classes.html#private
Thanks for your post!
@@deborah_kurata copy that :)
thanks for sharing
Thanks! Great seeing you last week! Having fun in New York?
Unfortunately this doesn't work with shortend constructor :(
Could you elaborate?
nice 🏋🏻♀
Thank you!
is there anyway to hide the url from user client. for example to hide the url that I want to request from the server. even not show in the network panel.
thanks
When issuing an HTTP request, you don't have to show the URL in the address bar. (It won't show in the address bar by default.) But as you mentioned, it will appear in the network panel.
Here is a link to a discussion about this topic: stackoverflow.com/questions/54150743/it-is-possible-to-hide-the-request-url-from-in-the-chrome-web-inspector-network
@@deborah_kurata Thanks a lot , I got it
Don't like that symbol with that regard. The readability is awful. Private modifier is way better. Wouldn't it better to go with underscore..
Agreed, the readability is much better with private or private readonly.
Problem with underscore is it's purely convention and doesn't mean anything to the compiler or language services. But if your team all follow the convention, and maybe create a LINT rule for it, it could work.