Angular incorporó linkedSignal como una nueva primitiva reactiva que combina lo mejor de computed con la capacidad de modificar el valor manualmente. Si trabajas con signals y necesitas estado derivado que también puedas actualizar, esta API te ahorra effects innecesarios y código imperativo.

¿Qué problema resuelve linkedSignal en Angular?

Dentro del ecosistema de Angular existen tres primitivas base para trabajar con reactividad: signal para declarar estado, computed para derivar un signal a partir de otro, y effect para reaccionar a cambios. Una regla no escrita de la comunidad es evitar el uso de effect siempre que exista una alternativa más declarativa, y aquí es donde entra el linkedSignal [1:30].

El caso práctico aparece en el detalle de un producto con un carrusel de imágenes. La imagen de portada, llamada cover, se calcula a partir del producto cargado desde la API. En la versión inicial, el código hacía un set del producto y luego un if para verificar si tenía imágenes y asignar la primera al cover de forma imperativa.

¿Qué es linkedSignal? Es una primitiva reactiva de Angular que funciona como un computed (deriva su valor de otro signal) pero permite hacer set manualmente para sobrescribir su valor cuando lo necesitas.

¿Por qué computed no era suficiente para el cover?

La primera mejora natural fue convertir el cálculo del cover en un computed, ya que su valor depende directamente del producto. La sintaxis quedaba así:

typescript cover = computed(() => this.product()?.images[0] ?? '');

Esto eliminó el if manual y volvió el código más declarativo. Cada vez que el producto cambia, el cover se recalcula automáticamente [5:00]. El problema apareció con la galería: al hacer clic en una miniatura, el código intentaba hacer cover.set(imagen) para cambiar la portada manualmente.

Y ahí está la limitación clave: un computed no se puede modificar directamente. Su único camino para actualizarse es que cambie el signal del que depende. No tiene método set.

¿Y si usamos un effect como solución intermedia?

Una salida sería volver el cover a un signal normal y usar un effect que escuche cambios en el producto para reasignarlo. Funciona y es más declarativo que el if original, pero agrega un effect que la comunidad de Angular recomienda evitar. La solución sigue sintiéndose forzada.

¿Cómo se usa linkedSignal paso a paso?

La API resuelve exactamente esta tensión. Su forma básica es idéntica a un computed, pero con la diferencia de que sí acepta set:

typescript cover = linkedSignal(() => this.product()?.images[0] ?? '');

Con esto, el cover se recalcula automáticamente cuando cambia el producto, pero también puedes hacer this.cover.set(nuevaImagen) cuando el usuario hace clic en una miniatura del carrusel [9:30]. Sin effects, sin ifs extra, sin lógica imperativa duplicada.

Un detalle de limpieza: si en tu template usabas cover() varias veces dentro de una expresión, conviene asignarlo a una variable local con @let cover = cover$() para evitar suscribirte dos veces al mismo signal. Una convención útil es prefijar los signals con $ para distinguirlos de variables comunes y evitar choques de nombres.

¿Cuándo usar linkedSignal en lugar de computed? Úsalo cuando necesites un valor derivado que también puedas sobrescribir manualmente. Si el valor solo depende de otros signals y nunca se modifica desde fuera, computed es suficiente.

¿Qué ventaja extra aporta la sintaxis con source y computation?

linkedSignal tiene una segunda forma de declaración más expresiva, usando un objeto con dos propiedades: source y computation [12:00].

• source: el signal del que depende, pasado sin invocar (sin paréntesis).
• computation: una función que recibe el valor actual del source y, además, el valor previo del propio linkedSignal.

typescript cover = linkedSignal({ source: this.product, computation: (product, previous) => product?.images[0] ?? previous?.value });

La ventaja real está en el previous value. Imagina que el producto se actualiza pero no trae imágenes: en lugar de dejar el cover vacío, puedes conservar el valor anterior. Es un patrón útil para evitar parpadeos en la UI o mantener estado cuando los datos llegan incompletos.

¿Qué es el previous value en linkedSignal? Es el valor que tenía el signal antes del recálculo. Está disponible solo cuando declaras el linkedSignal con la sintaxis de objeto (source + computation), y sirve para fallbacks o lógica condicional basada en el estado anterior.

¿Qué ganas al adoptar esta primitiva en tu código Angular?

Migrar de la combinación signal + effect + if hacia linkedSignal trae beneficios concretos:

• Código más declarativo y corto, sin ifs manuales después de cada set.
• Mejor rendimiento interno porque Angular gestiona las dependencias entre signals.
• Menos effects en tu aplicación, lo que reduce efectos secundarios difíciles de rastrear.
• Posibilidad de acceder al valor anterior cuando lo necesites, algo imposible con un computed puro.

La funcionalidad del carrusel sigue intacta: la imagen de portada se carga al traer el producto y cambia al hacer clic en cualquier miniatura. La diferencia está en la experiencia de desarrollo y en la claridad del código.

¿Ya identificaste un effect en tu proyecto que podrías reemplazar con un linkedSignal? Cuéntame en los comentarios cómo lo refactorizarías.