0

In short, I want to ask about the differences between:

A: {{ variable | filter }}

and

B: {{ 'static string' | filter }}

These are my questions:

  1. Are both of them called interpolations or only A?
  2. A uses $interpolate, while the B uses $parse - is that true? (basing on another SO question)
  3. What is the performance difference? When I use A, each time the variable value changes, the template is updated (the variable is listened for changes). If there are great lots of interpolations such as A, there might be performance problems due to lots of listening on models. Is that different for B? Especially, I'm considering using http://angular-translate.github.io/, which uses translate filter. There is a global variable somewhere, holding actual language used in the interface and when it is changed, all B interpolations using translate filters will be updated. But how does it work underneath, what is listening on what? Is there just one listener on the language variable value (held inside angular config) which enables registering multiple i18n-labels to be translated when the language changes? Or are there multiple listeners? If I have 500 {{ 'static string' | translate }} interpolations, will it slow down my application due to listeners?

If I'm mistaken anywhere, please correct me.

Community
  • 1
  • 1
ducin
  • 25,621
  • 41
  • 157
  • 256

1 Answers1

1

Both are interpolations. Whenever {{ and }} are involved (unless you of course changed the symbols), the wrapped content will go through the interpolation service.

As stated above, both A and B will use the $interpolate service. The $interpolate service uses the $parse service, so both A and B will "use" both services.

These are the exact strings that will get passed from $interpolate to $parse:

Case A: variable | uppercase

Case B: 'static string' | filter

There is no difference in the number of watchers added for the two cases, as it is the node's combined nodeValue that is being watched.

For example, there is no difference is the number of watchers added in these two cases either:

<div>{{one}}</div>

<div>{{one}} {{two}}</div>

The performance difference between case A and B comes down to the functions that are used to get the left-hand side of the expression.

In case A it will basically be:

function (locals, scope) {
  return ((locals && locals.hasOwnProperty('variable')) ? locals : scope).variable;
}

In case B (where string is held in a clojure and has the value of static string:

function() { return string; }

The difference between the two in execution time shouldn't be noticeable (unless you have an absurd amount of interpolations).

Generally filters should be kept simple, as they can get executed many times.

In AngularJS 1.3.0-rc.2 filters were made stateless by default which was a major performance improvement.

Take the following example:

<div>{{ variable | uppercase }}</div>

When the digest loop runs it will detect the value of variable and apply the filter. The next time the digest loop runs the value of variable might not have changed. Since filters are stateless, meaning that one value on the left side should always generate the same value from the filter, it does not have to apply the filter again, and can instead use the cached value from the last time the filter was applied.

Again a bit simplified, but you can read more about it here.

Filters can however override this and become stateful, which the translate filter in Angular Translate has done. This is required since you can change languages runtime, and the value of hello is obviously not translated to the same value in every language.

I do not know enough about Angular Translate to say anything about the performace of it, but I will take a closer look at it tomorrow and edit my answer.

tasseKATT
  • 38,470
  • 8
  • 84
  • 65
  • your answer is fabulous. It gives me required background. Anyway, I would appreciate it a lot, if you provided information about the translate plugin. – ducin Feb 11 '15 at 21:23
  • I didn't have time today, but I will try to take a look at it tomorrow :) – tasseKATT Feb 11 '15 at 21:24