0

I'm getting a bit confused with Angular/Typescripting here. I thought that properties are to be kept hidden to prevent any possible external alteration to a properties value.

For example:

export class Foo{
  private _bar: string;

  constructor(private bar: string){
    this._bar = bar;
  }

  public get bindBar(): string {
      return this._bar;
  }
}

And some template

<span>{{ bindBar }}</span>

But in reading there are performance issues with having binding to a method from the html template as methods get called under every change detection that occurs on the page.

Options that I am seeing are to either make it a public property or to use Pipes.

Pipes just seem like overkill to have to implement for every property in a page that you need to bind and public vars have almost always been a no no.

I cannot find any clear direction on the Angular website on how to implement binding and not have a negative impact on performance but also this pipe thing just does not seem the right way of doing it.

Can someone explain?

Thank you for the links to other articles. In them I found an example of the triggering method calls and branched the example to test if it was component based or contained within a component.

As you can see in the example it is not bound to a component as the events triggered affect the other components. My Stackblitz 2 component test

Chris Hamilton
  • 9,252
  • 1
  • 9
  • 26
edjm
  • 4,830
  • 7
  • 36
  • 65
  • Why not using public properties? What's wrong with those? Do you need extra logic to be executed on every getter or setter that justifies having a private backing field? The template is pretty _intimate_ with the component, you can't exactly call it external. – Octavian Mărculescu Apr 13 '22 at 11:13
  • 1
    Repeated, check this https://stackoverflow.com/questions/48332039/methods-vs-pipes – Mustafa Omran Apr 13 '22 at 11:14
  • Does this answer your question? [Methods vs pipes](https://stackoverflow.com/questions/48332039/methods-vs-pipes) – R. Richards Apr 13 '22 at 11:18
  • @OctavianMărculescu I prefer to not use public properties because it tends to be an issue where other developers will directly set values to that property rather than utilizing the setProperty() methods that are put in place to ensure the values passed in are handled in a proper way. I'm coming from mainly a Java background and find the openness of properties stressful. Why have public properties or methods when nothing outside of the class is referencing them? If something needs to get or set a value then practice has always been to make them call a function & not directly alter the property. – edjm Apr 13 '22 at 11:58
  • @MustafaOmran this is just a misunderstanding about how change detection works. See my answer if you want. – Chris Hamilton Apr 13 '22 at 19:15

2 Answers2

1

This getter

  public get bindBar(): string {
      return this._bar;
  }

is not going to degrade the performance of your application. Calling this takes roughly the same amount of time as directly referencing the variable. All the variables in your template also get referenced at every change detection, to check if they've changed. So calling this in your template is no different than referencing a public variable.

That being said, if you want to make a variable read only, you can just use the readonly keyword.

readonly bar: string;

Don't believe me? Here's a test:

https://stackblitz.com/edit/angular-ivy-zgjwnw?file=src/app/app.component.ts

Over one million change detection cycles, both strategies take roughly 650 milliseconds with my hardware.

The only time you need to be worried about calling methods during change detection is if those methods take a significant amount of time, or if you're making requests to an API. Never put those sort of method calls in your template unless you're tying them to an event.

If you're worried about performance, you should be more concerned with how many times change detection actually fires, and how many components get checked each time. The default change detection strategy is to check every single variable and method call in all current component templates on every action that might have changed something.

The OnPush change detection strategy lets you change when component templates get checked, and the ChangeDetectorRef.detach() service method lets you completely detach the component from being checked automatically.

This is a great article for more info:

https://blog.angular-university.io/how-does-angular-2-change-detection-really-work/

I highly recommend putting a breakpoint right before calling ChangeDetectorRef.detectChanges() and walking through a change detection cycle in the debugger. You'll see that the change detector saves the last value of any interpolated values in the template (whether they're a property or the result of a method call) in an object called lView (last view). Then on a change detection cycle it recalculates those interpolated values again - whether that means referencing a variable or calling a method. If any of the values differ then the change detector will reference the associated html node and change it's value.

In the context of pipes, the change detector will check the input value and only call the pipe if that value has changed. That's because pipes are assumed to be pure functions (output only relies on input). So if you're calling a time consuming pure method, it's more efficient to make it a pipe. Examples: formatting a string, performing validation, math equations, deep comparisons, etc.

Chris Hamilton
  • 9,252
  • 1
  • 9
  • 26
  • With regards to the application I am working on it uses the Leaflet map and so it fires events all the time on the mouse movement. I would not be bothered by the binding of a method and it firing because the method purely returns the current value and does not modify it at all. However the lead on the app does not want to implement things that way claiming performance issues. The irony is that however this app was set up it has a big performance issue itself. Going the route of Pipes seems like a pain in the ass for binding a lot of form fields. – edjm Apr 14 '22 at 11:37
  • Maybe you should direct the lead to this post... you should be setting that component to the OnPush strategy or detaching it completely, and controlling change detection manually using the ChangeDetectorRef. If y'all are triggering change detection on mousemove that is a BIG issue. – Chris Hamilton Apr 14 '22 at 12:43
  • I would but I and others have been walking on eggshells on the project. Rather toxic environment. Stir the pot very little until something here changes for the better. – edjm Apr 15 '22 at 15:09
  • Ah I see, well good luck! – Chris Hamilton Apr 15 '22 at 20:57
0

In typescript, it is mostly safe to use public variables, and accessing them directly. When binding, things tend to go sideways when using methods, so it is recommended to use variables in your bindings.

Johnys
  • 111
  • 6