Menu
1. Public: All the properties and methods could be accessed everywhere if they are declared as public. 2. Private: The private declared properties and methods can be accessed only within the class definition itself.
Constructor in Angular is put into use to inject dependencies into the component class. It creates a new instance of the class when the compiler calls 'new MyClass ()'. While calling 'new MyClass()', it is vital that the exact match of the parameter passes the Angular component constructor of the class.
By default Public is the default access modifiers for all properties and methods so if you define any properties or method without access modifiers that will be consider as public and then as name suggests it can be accessible outside the class.
There's a lot to say in response to this question, these are the first thoughts that jumped to my mind:
First and foremost, keep in mind that private is only a compile-time construct - it cannot be enforced at runtime (see here and here for relevant discussion). As such, please disabuse yourself of any notions of private being useful in any way for security purposes. That's simply not what it's about.
It is about encapsulation, and when you have a field or method on your component that you want to encapsulate in it, making it clear that it shouldn't be accessed from anywhere else, then you should absolutely make it private: That's what private is for: It signals your intent that whatever you've put it on shouldn't be touched from outside the class.
The same goes for public: It too is a compile-time-only construct, so the fact that class members are public by default, while true, has exactly zero meaning at runtime. But when you have a member that you explicitly intend to expose to the outside world as a part of your class's API, you should absolutely make it public to signal this intent: That's what public is for.
This is all applicable to Typescript in general. In Angular specifically, there are definitely valid use-cases for having public members on component classes: For instance, when implementing the container/component (aka smart/dumb) pattern, with "dumb" children injecting "smart" parents via constructor injection, it's extremely important to communicate your intent about what members on the parent should and should not be touched by the children: Otherwise, don't be surprised when you catch those dumb kids fooling around in their parents' liquor cabinet.
So, my answer to your question:
should I always add private for all of them like below?
is an emphatic no. You shouldn't always add private because in doing so you defeat the purpose of the keyword, because it no longer signals any intent if you put it everywhere: You might as well not put it anywhere.
@drewmoore provides a good answer in that private/public boils down to intent. But there are a few more things to consider when using injected private values:
@Import() private foo, or constructor(private foo) {}, and only use foo in your templateIf we want to emit TypeScript as output of the AoT compilation process we must make sure we access only public fields in the templates of our components**
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With