Is it a good practice to use getter setter in angular 2 application

Question

I am working on angular2 application in which my team member are using getter and setter to set input properties as follow

private _showModal;
@Input() set showModal(showModal){
     this._showModal = showModal;
}
get showModal() {
     return this._showModal;
}

but I am not sure its a good way to do this. I thought one should use getter setter in the case where dev have to do some validation or check or do some other function while setting or getting value

Answer 1

Where we do the reading(get) and writing(get) majorly determines how much cost we pay for performance.

setters

A setter function is called every time we write some value.

Now we generally do the writing part that calls the setters in our TypeScript Classes. So they don't get called so often unless there's a set operation, which isn't quite frequent in general.

getters

A getter function is called every time we read some value.

getters are generally called in templates in different data binding syntax like string interpolation({{}}), property binding([---]=""), attribute binding([attr.---]=""), style binding([style.---]="") etc.

Now the catch with this is, every time Angular performs change detection, the getters get called. It's fine as long as there isn't much logic in your getter. But that still leaves a room for newer developers in the team to add logic in there without being aware of the performance hits that it's gonna create.

So in summary, from what I understand, it's okay to have setters. But having getters and it's cost on performance would mainly depend on where those getters are used. If they're used in one of the template binding syntaxes, then it's safe to NOT HAVE THEM IN THE FIRST PLACE. If they're not being used in the template, it's okay to have them.

I've actually written an article and a few answers on various StackOverflow Threads that you might want to check out as well. So I'm adding them as a list below:

1. Angular: Prevent DomSanizer from updating on DOM Events

2. Angular performance: ngStyle recalculates on each click on random input

3. Angular 7 ,Reactive Form slow response when has large data

4. Angular Performance: DOM Event causes unnecessary function calls

5. I changed my implementation of an EXTREMELY deeply nested Angular Reactive Form and you won’t believe what happened

Hope this gives you some perspective. :)

Answer 2

avoid getters specifically if possible. Getters have a negative effect on change detection. In order to know whether the view should be updated, Angular needs to access the new value, compare it with the old one and make the decision on whether the view should be updated. For this reason, the value is compared and updated on every change detection cycle. If for some reason you need to transform data when an @Input() is changed in a component a setter is fine for example.

value;
@Input('myValue') set myValue(v) {
 transformValue(v);
}
transformValue(v) {
...*sometransform*
this.value = transforrmedValue
}

in this example, a setter is placed on the Input and the value is transformed every time a new myValue is pushed to the component. However, if a getter is introduced the component will check the getter every time change detection cycles anyway. You could also use other things like pipes or ngOnChange instead of setters.

UPDATE

as long as your component is using ChangedetectionStategy.OnPush now using a getter is fine but still avoid it if you are not using OnPush

Answer 3

This is part opinion, part the requirements of your application. It is certainly not bad to use getters and setters. But I would also use them with discretion and in most cases getters and setters may be unnecessary.

In the example code you provide, there is no reason to use a getter and setter. You are correct in that it can help when doing some sort of validation check or when something else in contingent upon the value being set, etc. For example, maybe you need to call some function when an @Input() property changes value, this can be an easy way to accomplish that. But in many cases, this is probably not a requirement for every variable/input in your application.

Hope this helps.

Answer 4

I would only do this if you alter _showModal in the get or set.

Using it like your team member does (with a backing property) just adds more lines of code.. In that case I would make a public showModal property.

I don't know if there is a "best practice" for this. I think it mostly has to do with personal preference.

Answer 5

It is a good practice as you have more control on your data. Especially when you need to know when your data has changed with angular change detection.

Most of the time, I use them in my services to share the data over several components.

They also interact well with observables to avoid calling several times an endpoint to get your data.