Hide Your Properties in Angular: # vs private

Have you noticed a hash symbol showing up in Angular code samples? If not, you may see it soon! What is the purpose of the # and when should you use it?
The # symbol was recently added to JavaScript to denote private class properties. Making a class variable private means that the variable can only be accessed within its class. That allows us to encapsulate data we only want to access within a service.
But don't we already have a private accessor for our class fields? Yep!
Then why do we need the new hash syntax?
Let's take a look at the private accessor first, then examine the # syntax and why it is a better choice in our Angular applications.
*Content*
00:00 JavaScript private class members (#)
00:50 The sample application
01:16 The danger of public class properties
02:47 TypeScript's private accessibility feature
03:39 Accessing variables with private accessibility at runtime
05:41 JavaScript's private class members (#)
07:11 Private properties in components
08:04 Wrap Up
*Links*
TypeScript documentation on private and #: www.typescriptlang.org/docs/handbook/2/classes.html#private
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
😊About Me
Hey! I'm Deborah Kurata
I'm a software developer and KZbin content creator. I speak at conferences such as VS Live and ng-conf. I write articles for freeCodeCamp. And I'm a Pluralsight author with courses in the top 10 most popular (out of 10,000+) over the past 5 years. For my work in support of software developers, I've been recognized with the Microsoft Most Valuable Professional (MVP) award, and I'm a Google Developer Expert (GDE).
Contact me on Twitter: DeborahKurata
Find my Pluralsight courses: www.pluralsight.com/profile/author/deborah-kurata
Access my freeCodeCamp articles: www.freecodecamp.org/news/author/deborah-kurata/
View my KZbin content: www.youtube.com/@deborah_kurata
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
#angular #bestpractices #angulartutorial #demo
#typescriptprivate #privateaccessibility #javascripthash #javascriptprivate #hashvsprivate

[@turboheadcrab666]

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.

[@deborah_kurata]

Wow! That is kind of you to say. Thank you so much! 😊

[@blokche_dev]

Just a few words to thank you for the content you share. Very valuable. That's it! Have a great day :)

[@deborah_kurata]

I appreciate that! Thank you!

[@StephenMoreira]

Very nice. I was confused when this first came out and why I would use it. Very informative!

[@deborah_kurata]

So glad to hear it was useful! Thanks!

[@havefun5519]

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.

[@deborah_kurata]

Great to hear! Thank you!

[@bruinscat]

Great explanation & demonstration!

[@deborah_kurata]

Glad it was helpful!

[@_dinesh]

Wow. I did not know this at all. Thank you so much!

[@deborah_kurata]

Glad it was useful!

[@alexandercisnerosvinelli5644]

Thank you for another great lesson 🙌

[@deborah_kurata]

Glad you liked it! Thanks for watching!

[@baoviettran9033]

Thank you for great explanation!

[@deborah_kurata]

Thanks! 😊

[@SanketLakhera]

Thank you for this video. subscribed!!!

[@deborah_kurata]

Awesome, thank you!

[@MultiWarrr]

Great as usual

[@deborah_kurata]

Thanks! 🙏

[@ashishnayak2666]

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.

[@deborah_kurata]

Thank you for the kind words!

[@mktrann]

Nice explaination! Thank you!

[@deborah_kurata]

Thank you!

[@abhirajgawai505]

Neetly explained.. Thank you so much

[@deborah_kurata]

You are welcome 😊 Thank you for watching!

[@OlehBiblyi]

Great explanations, thanks.

[@deborah_kurata]

Thank you!

[@waelmoh]

looooove ur videos , thank u sooo much

[@deborah_kurata]

Thank you for watching!

[@dhineshrajendran3277]

Amazing video🙌

[@deborah_kurata]

Thank you 🙏

[@cathyf5449]

Great video. Very helpful.

[@deborah_kurata]

Glad it was helpful! Thank you!

[@dev-rachid]

Great! Thank you for your share 👍

[@deborah_kurata]

Thank you for watching!

[@yimnaineruszaumu3082]

Thanks so much for this knowlege. All this while, i had no idea TS's private wasnt so private after all

[@deborah_kurata]

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. :-)

[@sameerdas3672]

Good information❤

[@deborah_kurata]

Thank you!

[@rd_45]

Thnaks...very informative

[@deborah_kurata]

Glad it was helpful!

[@jackiecooper9439]

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

[@deborah_kurata]

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?

[@jeantalar]

@@deborah_kurata For sure

[@jackiecooper9439]

@@deborah_kurata Nothing can be better then that for the Angular community. 🤗😄

[@user-ttishere]

You are a champ. thanks

[@deborah_kurata]

Thank you!

[@azeriwindowoz]

I use "protected" access modifier for the component properties if I need to show them in the template. Better than public

[@NuncNuncNuncNunc]

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.

[@pazzuto]

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.

[@deborah_kurata]

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.

[@ErickCcsVzla]

Nice! 😊

[@deborah_kurata]

Thanks! 😄

[@jchacon2]

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?

[@deborah_kurata]

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.

[@DebugModeVideos]

thanks for sharing

[@deborah_kurata]

Thanks! Great seeing you last week! Having fun in New York?

[@tleveque]

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.

[@deborah_kurata]

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

[@Brendan2Alexander]

Helpful! So...why doesn't Typescript simply transpile private to the native # approach?

[@deborah_kurata]

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.

[@thirukumaran7294]

valuable 8.35 minutes in my lifetime.

[@deborah_kurata]

That is kind of you to say. Thank you.

[@MommaRoo36]

Thank you! Your explanations and examples are very helpful. Quick question - what version of Angular are you using here?

[@deborah_kurata]

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.

[@wojciechlasota9488]

nice 🏋🏻‍♀

[@deborah_kurata]

Thank you!

[@mohamedal-qadeery6530]

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

[@deborah_kurata]

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.)

[@mohamedal-qadeery6530]

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 ;)

[@pawello94lech]

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?

[@deborah_kurata]

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.

[@huizhao2050]

Very nice. Happy 2024.

[@deborah_kurata]

Thank you! Cheers!

[@buyanimhlongo2414]

Hey Deborah Kurata,do you have the same content on Getting Started with Angular same as the one in Plural Sight available to students?

[@deborah_kurata]

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 KZbin.

[@esdegan7176]

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

[@deborah_kurata]

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!

[@TheAlanFerguson]

Would there be any disadvantage for typescript to change how private properties are transpiled to make use of the Javascript # modifier too?

[@deborah_kurata]

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.

[@bdcp]

i still think "private readonly" is still the way to go, it's really readable and does the same thing except at runtime

[@deborah_kurata]

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!

[@dg-cg5gi]

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?

[@deborah_kurata]

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.

[@dg-cg5gi]

@@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?

[@deborah_kurata]

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.)

[@TheZukkino]

Unfortunately this doesn't work with shortend constructor :(

[@deborah_kurata]

Could you elaborate?

[@RyoCodes]

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

[@deborah_kurata]

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.

[@deborah_kurata]

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

[@RyoCodes]

@@deborah_kurata Thanks a lot , I got it

[@craigritchie8470]

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.

[@deborah_kurata]

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.

[@gesiud]

So it's all about native JavaScript features instead TypeScript?

[@deborah_kurata]

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!

[@gesiud]

@@deborah_kurata copy that :)

[@NagornovAlex]

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..

[@deborah_kurata]

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.