Binding a propiedad vs interpolación de strings, en Angular

  • Por
Cuándo usar el binding de propiedad o la interpolación de strings, dos alternativas con objetivos distintos en Angular, que a veces pueden confundir.

En este artículo vamos a analizar en contraposición dos alternativas de binding en Angular, que a veces pueden producir dudas, básicamente porque podrían ser usadas en contextos similares.

El objetivo es ayudar al lector a identificar los casos donde se recomienda usar el bindeo de propiedades o la interpolación de strings, de modo que sea capaz de escoger la mejor opción en cada caso.

Recuerda que estos conceptos ya se han explicado, de modo que deberías conocer al menos qué diferencias tienen. Si no es así te recomendamos leer el artículo sobre la interpolación de strings y el binding de propiedades.

Dos mecanismos distintos, que pueden usarse en situaciones parecidas

Sabiendo que la interpolación de strings y el binding de propiedades son cosas bien distintas, queremos mostrar que en ocasiones pueden ser usadas en los mismos lugares, produciendo idéntico resultado.

Observemos el siguiente código.

<p>
  <img src="{{urlImagen}}">
</p>
<p>
  <img [src]="urlImagen">
</p>

En el primer caso se está realizando interpolación, colocando como valor de una propiedad algo que viene de una variable del componente. En el segundo caso se está usando binding a la propiedad src, colocando el valor de la misma variable.

Ambos casos resuelven el HTML del componente con el mismo resultado. ¿Cuál es el correcto?

Tenemos más ejemplos. Observa ahora este otro caso, en el que básicamente colocamos una clase obtenida por medio de una propiedad del componente. El resultado será el mismo.

<ul>
  <li [class]="valorClass">item 1</li>
  <li class="{{valorClass}}">item 2</li>
</ul>

Por último veamos un caso donde también obtenemos el mismo resultado, pero usando dos aproximaciones mucho más diferentes.

<p>{{texto}}</p>
<p [innerHTML]="texto"></p>

En el primer párrafo estamos colocando como contenido un texto por interpolación. Mientras que en el segundo párrafo se coloca el mismo texto, a través de la propiedad del componente innerHTML.

Si estás confuso con ambas posibilidades sería más que normal. Intentaremos arrojar algo de luz sobre cuál de ellas te conviene usar en cada caso.

Uso de la interpolación con cadenas

En todos los casos anteriores estamos en definitiva volcando cadenas en diversos puntos del template. Aunque esas cadenas a veces se coloquen en propiedades del componente, no dejan de ser cadenas.

En todos los lugares donde se trate de colocar cadenas en una vista, puede que tenga más sentido usar interpolación, debido en mi opinión a la claridad del código de la vista.

Pero ojo, porque esto es una opinión personal, que no atiende a ningún motivo relacionado con el propio framework. De hecho, lo cierto es que no existe una diferencia real entre una u otra posibilidad, por lo que se pueden usar indistintamente.

Lo importante sería establecer una norma a seguir por todos los desarrolladores en cuanto a cuál usar en los casos en los que no exista diferencia, de modo que todo el mundo tome las mismas decisiones y obtengamos un código más homogéneo.

Uso de property binding con valores distintos de cadenas

El caso de valores que no sean cadenas de caracteres es ya distinto. Realmente la interpolación de strings siempre debe devolver una cadena, por lo que no será adecuada si aquello que se tiene que usar en una propiedad no es directamente una cadena.

Por ejemplo, la propiedad "disabled" de un botón debe igualarse por property binding a un valor boleano, luego no será adecuado usar interpolación. Por tanto, lo correcto sería esto:

<button [disabled]="activo">Clic aquí</button>

En este caso concreto, no deberíamos usar interpolación, ya que el resultado no será el deseado. Por ejemplo, esto no sería correcto.

<button disabled="{{activo}}">Clic aquí</button>

El motivo es que activo se interpolaría por la palabra "false". En este caso disabled="false" en HTML sería lo mismo que colocar el atributo "disabled" sin acompañarlo de ningún valor, lo que equivale al final a que el botón esté desactivado.

En definitiva, cada vez que tengamos que usar un dato que no sea una cadena, es preferible colocar el binding de propiedad. Por ejemplo, la directiva ngStyle espera un objeto como valor, por lo que estaríamos obligados a usar property binding.

<div [ngStyle]="estilo">Test de estilo</div>

Sanitización de cadenas en templates de Angular

En el caso que tanto property binding como string interpolation se usen para volcar cadenas en el template, hay una diferencia destacable en la manera como las cadenas se van a sanitizar antes de volcarse al template.

En vista de esta propiedad en el componente:

cadenaXSS = 'Esto es un <script>alert("test")</script> con XSS';

La propiedad cadenaXSS presenta un problema de seguridad, por una inyección de código de un script, lo que se conoce por XSS.

Podríamos volcarla en un template de la siguiente manera:

<div>{{ cadenaXSS }}</div>
<div [innerHTML]="cadenaXSS"></div>

Angular en ambos casos hace un saneamiento de la cadena, desactivando la etiqueta SCRIPT, para evitar problemas de seguridad por inyección de código XSS. Pero el resultado de ese saneamiento es diferente en cada caso.

En este caso concreto, la salida que obtendremos es la siguiente:

Esto es un <script>alert("test")</script> con XSS
Esto es un alert("test") con XSS

Tienes que observar que, en el caso de la interpolación de strings, la etiqueta script te aparece como texto en la página. Es decir, será un simple texto y no una apertura y cierre de una etiqueta para colocar un script Javascript.

Esperamos que con estas indicaciones hayas resuelto algunas dudas típicas que pueden surgir cuando empiezas a trabajar en el desarrollo con Angular. Ahora estás en condiciones de escoger la mejor opción en cada caso, entre string interpolation y Property binding.

Autor

Miguel Angel Alvarez

Miguel es fundador de DesarrolloWeb.com y la plataforma de formación online EscuelaIT. Comenzó en el mundo del desarrollo web en el año 1997, transformando su hobby en su trabajo.

Compartir