¿Qué son las validaciones condicionadas en formularios reactivos?
Las validaciones condicionadas son un poderoso concepto en el desarrollo de formularios reactivos en Angular. Este tipo de validaciones se adaptan dinámicamente a los cambios que realiza el usuario en el formulario, permitiendo modificar las reglas de validación en tiempo de ejecución. Un ejemplo práctico es en un formulario de registro, donde dependiendo de si el usuario selecciona ser una "company" o un "customer", el campo "company name" puede ser obligatorio o no. Este enfoque ayuda a crear formularios más inteligentes y adaptativos, mejorando la experiencia del usuario.
¿Cómo se configuran campos dependientes en un formulario?
Es esencial comprender cómo implementar estos campos dependientes en Angular para dinamizar las validaciones. Aquí te explicamos los pasos a seguir:
Agregar campos al formulario: En tu componente de registro, incluye el campo "type" con un valor por defecto, y el campo "company name". Este último será opcional según la selección de usuario.
Configurar radio buttons: Utiliza el MatRadioGroup para que el usuario pueda elegir el tipo de usuario. Asocia el campo con formControlName al formulario reactivo.
Campo de texto para 'company name': Crea un campo de tipo texto similar al correo electrónico, y asígnale un 'placeholder'. Este campo estará ligado al control de formulario company name.
// Creación del control para 'company name'companyNameField =this.formBuilder.control('');
¿Cómo se implementan las validaciones en tiempo de ejecución?
La implementación de estas validaciones dinámicas es crucial para definir cuándo un campo debe ser obligatorio. Veamos cómo:
Suscribirse a cambios en el campo 'type': Utiliza un getter para acceder a typeField y llama a valueChanges para detectar las variaciones.
Activar o desactivar validaciones: Según el valor de typeField, usa setValidators para definir si companyNameField es requerido o no.
Tras implementar las validaciones, es vital verificar que funcionen como se espera:
Probar interacción en la interfaz: Cambia entre las opciones de usuario y observa cómo el campo "company name" se vuelve obligatorio o no.
Simular casos de uso comunes: Ingresa un correo, contraseña y cambia el tipo de usuario. Observa cómo las validaciones se activan o desactivan de acuerdo al cambio realizado.
Las validaciones condicionadas te permiten crear aplicaciones más robustas y centradas en la usabilidad. Te animamos a seguir practicando y aplicando estas técnicas para mejorar tus habilidades en el desarrollo de aplicaciones con Angular. ¡Adelante, sigue explorando la potencia de los formularios reactivos!
Validaciones Condicionadas en Formularios Reactivos
Hay un detalle a tener en cuenta con las validaciones en runtime, si la validación nueva es diferente el setValidators no elimina las validaciones anteriores que pudiese tener el campo, si un campo tenia por ejemplo un min = 3 y luego le pones un max = 6 las nuevas validaciones se mezclan, es por ello que para no tener errores con las validaciones en tiempo de ejecución es recomendable ante de aplicar las nuevas validaciones a un control usar el método clearValidators, si están usando versiones de angular 10 o superiores el setValidators(null) no elimina las validaciones presentes. Esto lo aprendí a la mala cuando estaba validando un formulario muy chungo
Si tiene errores con las validaciones de un formulario este método los puede ayudar a saber que validaciones se están aplicando a un formulario
Que seria mejor, hacer un valueChange del controler o utilziar una funcion y un metodo (change) en el controler ? otra duda que me surge es si el observable deberia ejecutarse en el buildForm que se ejecuta en el constructor, tenia entendido que los observables era mejor ponerlos en el onInit ?
Holis, si alguno tuviera una solucion genérica (lazy loading), para el error NG0100: Expression has changed after it was checked, se lo agradeceria un montón si lo compartiera, puesto que no creo sea muy eficiente agregar ngAfterViewInit para cada componente, Gracias de antemano.
Hola amigo, no es necesario, al menos que quieras estar detectando los cambios que tiene tu fomulario atraves del tiempo, es decir, cada vez que cambie un campo,
SI no matamos la subscripcion, se sigue monitoreando los cambios hasta que cerramos el browser, lo cual es ineficiente y se pierde el control, aqui te dejo un ejemplo,
por favor abre la consola para que veas que se subscribe cada vez que entras en contacto, se envia el mensaje en la consola
Cuando entendí el operador ternario, quería usarlo hasta en la sopa... Pero luego uno encuentra cosas como estas y se da cuenta de varias cosas
Que si se van a usar y, (peor?) anidar, al menos se agradecen unos buenos paréntesis, tanto por legibilidad como por interpretación, dado que no en todos los lenguajes en los que está implementado tiene la misma jerarquía
Si no se va a aprovechar precisamente que una terna retorna un valor, para qué usarla? O para qué usarla en casos que una de las ramas es null o cero?
No por nada en Golang decidieron simplemente no implementar ternas, tener un solo operador de decisión (if/else) y preferir un enfoque explícito