Se agrega prop disabled opcional en DefaultRadioGroup

[iTzGooDLife]

Descripción

Se agrega el prop "isDisabled" opcional de tipo boolean al componente DefaultRadioGroup, el cual dependiendo su valor, se verá si se renderiza o no el componente radiogroup.

Motivación y Contexto

Actualmente si se usa el componente DefaultRadioGroup y no hay opciones, entonces aparece un error en el aplicativo, este arreglo busca que se maneje desde el componente padre si está habilitado o no el componente, esto permitiría evitar dicho problema en radio groups variables. No hay tickets relacionados.

¿Cómo ha sido probado?

Versión de node: 20.15.0

• El entorno de pruebas es el actual vulnerabilities-pareja3 (con data real).
• Las pruebas fueron realizadas con y sin elementos en el radriogroup y con elementos variables.

Capturas de pantalla (si es apropiado):

Renderizado al usar radiogroup sin items/elementos:

Renderizado con el cambio, donde el lado izquierdo no tiene "isDisabled" y el derecho lo tiene en "true":

Tipos de cambios

• [X] Bugfix (cambio que no interrumpe el funcionamiento y que soluciona un problema)
• [ ] New feature (cambio que no interrumpe el funcionamiento y que añade funcionalidad)
• [ ] Breaking change (corrección o funcionalidad que podría causar que la funcionalidad existente cambie)

Lista de verificación:

• [X] Mi código sigue el estilo de código de este proyecto.
• [ ] Mi cambio requiere una modificación en la documentación.
• [ ] He actualizado la documentación en consecuencia.

[iTzGooDLife]

No me hace sentido este cambio, si el prop options es requerido, entonces el problema se debería abordar de otra manera.

En mi caso, el problema actualmente lo abordo de otra manera, especificamente un bool en el componente padre que lo habilite o deshabilite, pero esto es un workaround que el eslint no permite. Además, es lógico que si uno tiene un componente donde los radio varian y puede que incluso no haya, entonces este se pueda comportar como tal.

Por otro lado, un prop "disabled" debería deshabilitar el uso del componente, no quitarlo de la vista

Propones un cambio de nombre o tienes algo más en mente?

[jllanosg]

No me hace sentido este cambio, si el prop options es requerido, entonces el problema se debería abordar de otra manera.

En mi caso, el problema actualmente lo abordo de otra manera, especificamente un bool en el componente padre que lo habilite o deshabilite, pero esto es un workaround que el eslint no permite. Además, es lógico que si uno tiene un componente donde los radio varian y puede que incluso no haya, entonces este se pueda comportar como tal.

Por otro lado, un prop "disabled" debería deshabilitar el uso del componente, no quitarlo de la vista

Propones un cambio de nombre o tienes algo más en mente?

¿Podrías agregar código de prueba al PR?

[iTzGooDLife]

Por qué añadir un nuevo prop en vez de decidir renderizarlo sólo si options no es vacío? Siento que es una lógica innecesaria agregar un prop, indicar por qué en caso de estar equivocado pls

Tienes razón, se puede gestionar sin añadir un nuevo prop. Se realizó un cambio donde se quitó el nuevo prop y se añadió la posibilidad de que el prop de "options" sea "undefined", lo que permitiría el que no haya elementos. Revisar los cambios por favor.