Angular incorporó las variables locales con @let en los templates, una característica que mejora la legibilidad del código y evita ejecuciones repetidas de signals. Si trabajas con Angular y quieres optimizar tus componentes sin caer en malas prácticas, aquí te muestro cómo aprovechar esta sintaxis y qué errores debes evitar.

¿Qué es @let en Angular y cómo se declara en un template?

La directiva @let te permite declarar variables directamente dentro del template HTML sin tener que pasar por el componente TypeScript. La sintaxis es simple: escribes @let seguido del nombre de la variable y le asignas un valor o expresión [02:15].

Por ejemplo, en un archivo product-details.html podrías escribir algo como @let myVar = 'hola' y luego renderizarlo dentro de un <h1>. Funciona, pero no significa que debas usarlo así.

¿Para qué sirve @let en Angular? Sirve para crear variables locales dentro de un template, evitando llamadas repetidas a signals u otras expresiones costosas. Es ideal cuando reutilizas el mismo valor varias veces en el HTML.

¿Cuándo conviene usar @let con signals?

El mejor caso de uso aparece cuando trabajas con signals que se ejecutan múltiples veces en el mismo template. Recuerda que un signal necesita ejecutarse para entregar su valor, así que escribir product() cinco veces significa cinco ejecuciones [03:40].

La solución elegante es guardar el resultado en una variable local:

• Declaras @let data = product() una sola vez.
• Reemplazas todas las apariciones de product() por data.
• Reduces ejecuciones y mejoras la lectura del código.

Además, cuando tu signal puede devolver null (por ejemplo, mientras un fetch asíncrono a la API aún no responde), puedes envolver el bloque en un @if (data) { ... } y eliminar el operador ? de encadenamiento opcional. Dentro del if, TypeScript ya sabe que data existe, así que el código queda más limpio.

¿Por qué un signal puede venir nulo al inicio?

Porque la conexión a la API no es instantánea, es asíncrona. El valor inicial del signal es null y solo cambia cuando el endpoint responde [04:55]. Por eso, antes de @let, era común ver operadores ? por todo el template para evitar errores. Con @let más @if, ese ruido visual desaparece.

¿Qué malas prácticas debes evitar al usar @let?

Aquí entra el famoso un gran poder conlleva una gran responsabilidad. La sintaxis @let abre la puerta a cosas que no deberías hacer en el template.

La primera regla es no asignar valores arbitrarios que deberían vivir en el componente. Si una variable no deriva de un estado existente en el TypeScript, probablemente no tiene por qué nacer en el HTML.

La segunda regla es evitar lógica de negocio dentro del template. Por ejemplo, calcular un cover así:

html @let cover = data.images?.length ? data.images[0] : '';

Es técnicamente válido, pero mezcla responsabilidades. Cuando alguien quiera entender tu código, va a tener que leer dos archivos: el .ts y el .html, buscando lógica en ambos lados.

¿Dónde debe vivir la lógica de negocio en Angular? Siempre en el componente TypeScript, idealmente con computed signals o linked signals. El template solo debe renderizar valores ya precalculados.

¿Cómo mantener templates limpios y mantenibles?

Sigue estos principios cuando uses @let:

1. Úsalo para cachear el valor de un signal que se repite varias veces.
2. Combínalo con @if para eliminar verificaciones de nulidad innecesarias.
3. No declares variables sueltas sin relación con el estado del componente.
4. No metas cálculos complejos ni condicionales largos dentro del @let.
5. Mueve la lógica derivada a computed() en el componente.

Después de aplicar estas reglas, vas a notar que el template se lee como una descripción visual del UI, no como un segundo controlador escondido en HTML.

¿Cómo aplicar @let junto con Prettier y ESLint?

Mientras refactorizas, Prettier puede marcarte advertencias como saltos de línea sobrantes o problemas entre corchetes. La buena noticia es que ya integraste Prettier con ESLint en clases anteriores, así que basta con correr el formateador o el linter para que ambos arreglen los detalles automáticamente [08:20].

Un flujo típico sería:

• Refactorizas tu template introduciendo @let.
• Ejecutas el formateador (npm run format o el comando que tengas configurado).
• ESLint aplica las reglas de Prettier y deja el archivo listo para commit.

Reto: aplica @let en header.component

Para practicar, abre el archivo header.component y revisa cómo se está usando el signal cart, que representa el carrito de compras [10:05]. Vas a encontrar varias llamadas a cart(): una para obtener length y otra para recorrer los productos.

Tu reto es reemplazar esas suscripciones múltiples por una sola variable @let, reutilizándola en todo el template. Es el mismo patrón que aplicamos en product-details, así que te servirá para fijar el concepto.

¿Cómo te quedó tu refactor del header? Comparte tu solución en los comentarios y cuéntanos qué otras mejoras encontraste al usar @let en tus propios proyectos.