Implementar el patrón de smart and dumb components en Angular trae beneficios claros en separación de responsabilidades, pero también introduce retos concretos cuando la información que fluye entre componentes es asíncrona. Aquí se aborda cómo resolver uno de los problemas más comunes: que el formulario no se rellene correctamente al editar, y la solución elegante que ofrece usar un setter en el input del componente.

¿Por qué el formulario no se rellena al editar con smart and dumb components?

Al separar responsabilidades, el smart component se encarga de obtener la categoría desde el servidor y enviarla al dumb component mediante un input. Sin embargo, al migrar la lógica de patchValue fuera del componente inteligente, el formulario deja de recibir los datos para rellenarse [01:06].

El problema es claro: el input recibe la categoría, pero en ningún momento se ejecuta un patchValue que lleve esa información al formulario. Simplemente se recibe el dato y se usa para validaciones visuales, no para poblar los campos.

¿Se puede usar el constructor o ngOnInit para resolver esto?

• Constructor: no es viable porque la categoría llega de forma asíncrona, es decir, puede aparecer mucho después de que el componente ya fue construido [02:06].
• ngOnInit: tampoco resuelve el problema. Se ejecuta solo una vez y, normalmente, el componente se monta antes de que el fetch de la categoría haya terminado [02:18].
• ngDoCheck: es otra opción disponible en Angular, pero no es la más recomendada para este caso.

La solución más precisa es convertir el input en un setter [02:32].

¿Cómo funciona un setter en un input de Angular?

Así como existen getters, también existen setters. Al definir el input como un set, se obtiene el momento exacto en que la información llega al componente, sin importar si es asíncrona o no [02:42].

typescript @Input() set category(data: Category) { if (data) { this.form.patchValue(data); this.isNew = false; } }

• Si data existe, se ejecuta patchValue para llenar el formulario y se marca isNew como false.
• Si no llega información, isNew permanece en true por defecto, indicando que se trata de una creación.

Esta variable isNew de tipo boolean reemplaza la referencia directa a category en el template, ya que al convertir el input en un método, deja de comportarse como una variable con estado [03:22].

¿Cómo impacta el setter en la lógica de guardado y en el template?

Con la bandera isNew disponible, la lógica del método save se simplifica [05:28]:

• Si isNew es true, se ejecuta la creación.
• Si isNew es false, se ejecuta la actualización.

En el HTML del dumb component, el texto del botón cambia dinámicamente: muestra "crear" cuando isNew es verdadero y "editar" cuando es falso [04:08].

html <button>{{ isNew ? 'Crear' : 'Editar' }}</button>

¿Qué ventajas ofrece esta técnica en el ciclo de vida de Angular?

Usar un setter en el input garantiza varias cosas importantes [04:24]:

• Se conoce el momento exacto en que llega la información.
• El componente ya pasó por su ciclo de constructor y ngOnInit, por lo que se pueden usar con confianza métodos e instancias declaradas.
• Se evitan errores derivados de datos nulos o inválidos gracias a la validación dentro del setter.

Es fundamental mantener la calma al encontrar errores durante estos cambios. Leer con atención los mensajes de la consola y aplicar correcciones de forma pausada es parte natural del proceso de refactorización [05:50].

El patrón de smart and dumb components combinado con setters en los inputs es una estrategia de arquitectura muy valorada profesionalmente. Dominar esta técnica permite construir componentes más predecibles, mantenibles y con responsabilidades bien definidas. Si ya lo implementaste, cuéntanos cómo te fue en los comentarios.