Un CRUD atomizado (IV). La edición.

En este artículo vamos a modificar el componente del formulario de nuestro CRUD para que nos sirva no sólo para las altas nuevas (que ya las hace) sino también, sin cambiar de componente, para las ediciones.

Esto es muy habitual en gran cantidad de CRUD’s. El proceso de alta de un elemento y de edición del mismo son tan similares desde el punto de vista operativo, que es muy normal usar los mismos procesos con muy pocas variaciones.

Si vamos a modificar ligeramente algunos detalles, como la clase Member, y parte de los métodos que hicimos en el artículo anterior, para optimizar al máximo la operativa. Sobre todo, trataremos de mantener el código lo más claro, desacoplado y mantenible que se pueda. Así mismo, seguiremos los principios del paradigma SOLID de POO, el más relevante de los cuales es que cada método haga una cosa, y sólo una. Eso nos obliga a crear muchos métodos, ya que cada proceso que se deba llevar a cabo deberá estár en su propio método. A cambio, logramos un código más trabajable y optimizado.

LA CLASE Member

Esta clase es la que modela los objetos que representan a los usuarios en nuestro CRUD. En este caso hemos tenido que añadirle un dato y modificar ligeramente la firma dle constructor. Al final, el archivo member.ts nos queda así:

El campo avatar se ha incluido para incorporar el nombre del avatar actual del miembro, en los casos de edición, a fin de actualizarlo si se le cambia o se le elimina.

Por lo demás, el resto de los cambios están, como es natural, en la lógica del componente (member-form.component.ts) y en la vista del mismo (member-form.component.html).

EN LA LÓGICA

No voy a reproducir aquí el código completo, por el espacio que ocupa (como siempre, está para descargar al final del artículo). Sólo aquellas líneas o fragmentos en los que debamos fijarnos.

En primer lugar, tenemos una propiedad nueva, llamada avatarName, para almacenar temporalmente el nombrew del avatar, por si este cambia o se elimina.

También, en donde declaramos las propiedades que mostrarán u ocultarán posibles errores en el formulario, o la grabación correcta, hemos añadido una llamada errorMessage. En caso de que se produzca un error de tipo HttpResponse (por ejemplo, si las API’s no funcionaran bien), nos mostrará el mensaje del error, lo que nos ayudará a saber lo que pasa. Lo vemos en el método catchError():

En el constructor de la clase retocamos la variable idRecibido. Esta variable era undefined si llegábamos como un alta nueva, o contenía el id de un miembro, en caso de una edición. Lo que hacemos ahora es que si es undefined la ponemos con el valor '0'. Esto hace que manejarla en la lógica y en la vista resulte más cómodo.

También en el constructor establecemos la ruta para volver a la lista de socios en otra variable nueva, llamada rutaParaLista. De este modo, no tenemos que crear dos enlaces en la vista. Creamos uno solo, cuyo destino viene determinado por esta variable. Como sabes, la ruta para retornar a la lista de miembros es diferente si estamos en alta o en edición, porque la edición tiene un parámetro en la URL que no tiene el alta.

El método readCurrentData(), que es como hemos llamado finalmente al encargado de leer los datos actuales de un registro que vamos a editar, es una gran ayuda. No sólo lee los datos del registro al llegar a edición, si no que también se ejecuta, leyéndolos de nuevo si, por ejemplo, pulsamos el botón de Reset. Este botón, en el alta nueva sólo limpia el formulario. En la edición, lo deja con los datos originales del registro que vamos a editar. Además, si editamos el registro y grabamos los cambios, se ejecuta de nuevo este método, de forma que siempre se nos muestren los datos actualizados del registro.

Además, verás algunos cambios menores (aunque imprescindibles) en los métodos checkRecord()selectAvatarToShow(), donde el comportamiento es ligeramente diferente si estamos en alta o edición. Sobre todo, el último método ya que, durante la edición, podemos cambiar el avatar, o volver a dejar el que había, o borrarlo definitivamente. Todas estas posibilidades han sido contempladas en el código que, a pesar de ello es, como verás, muy simple de seguir.

Por lo demás, con los comentarios incluidos en el código, no tendrás problemas para entenderlo, máxime que, realmente, estamos optimizando los procesos, pero no estamos implementando nada que no hayamos visto ya a lo largo del curso.

EN LA VISTA

En la vista también hemos introducido algunas pequeñas mejoras o novedades para permitir la edición de registros. La parte más novedosa está entre las líneas 51 y 68. Si estamos en edición, se muestra otro juego de botones de radio, relativos al estado de activo o no activo del miebro. Este no se muestra en las altas nuevas, ya que, como hemos dicho desde el principio, asumimos que los nuevos miembros están activos por defecto.

También tenemos, en el caso de las ediciones, un botón nuevo, para indicarle a la aplicación que queremos borrar el avatar existente. Se define en las líneas de la 104 a la 106. En las altas nuevas este botón no es necesario.

CONCLUYENDO

Es cierto que no hemos comentado nada sobre el código de la API que graba el registro. El artefacto save_record.php es el mismo para altas nuevas o para ediciones. Sin embargo, dado que el id del usuario es 0 en el caso de altas nuevas, la API usa esto para realizar una inserción o una actualización. El código PHP es muy fácil de seguir. Sin embargo, no es el objetivo de este curso. Podríamos tener la API en Java, o en Node, o en Python, o creada con Laravel o Symfony, o lo que sea. El código de la API se sale del tema de Angular, por lo que no vamos a detenernos en ella. Como siempre, la aplicación completa, en su estado actual, te la puedes descargar en este enlace.

   

Deja un comentario