Un CRUD atomizado (II). La lista de usuarios.

En el artículo anterior dedicamos todo el contenido a preparar la estructura básica de la aplicación CRUD que queremos desarrollar. Ha llegado el momento de ponernos a trabajar «en serio».

En este artículo vamos a empezar desarrollando el componente que lista los miembros. Para ello, tendremos, no sólo que crear dicho componente, sino que también empezaremos a crear algunos contenidos complementarios: parte del código de uno de los servicios, la API que obtiene la lista, la estructura de la base de datos con algunos datos para probar… Aprenderemos como hacer una lista de datos en Angular, de un modo eficiente, aprovechando las prestaciones y funcionalidades que este framework nos ofrece.

Esto nos llevará a un pequeño esfuerzo para aprender y asimilar cosas nuevas. El resultado merecerá la pena.

Antes de seguir adelante, crea en tu localhost un directorio al que llamarás aca_apis, donde iremos almacenando las API’s PHP para manejar el CRUD. Como este directorio correspondería a tu servidor, crea dentro un directorio llamado avatares, donde se irán almacenando los avatares de los miembros. De todos modos, toda esta estructura, incluyendo una base de datos MySQL básica, te la pondré al final del artículo en un enlace, como siempre.

Vamos a trabajar.

LA BASE DE DATOS

Antes de ponernos a trabajar, vamos a conocer la base de datos en la que persistiremos los datos de los miembros. La he llamado ang_aca_miembros y tiene una tabla llamada socios, con la siguiente estructura:

CAMPO USO COMENTARIOS
id Un identificador único para cada usuario Un campo numérico autoincrementable, que actuará como clave primaria.
doi El DNI, NIF, NIE, Pasaporte u otro documento Un campo de cadena de longitud variable. Este campo tiene un índice de tipo UNIQUE para que no se puedan duplicar números de documento.
nombre El nombre y apellido(s) Un campo de cadena de longitud variable.
fecha_de_ingreso La fecha en que ingresó en la aplicación Un campo de fecha en el formato ISO 8601 extendido (el habitual de MySQL: YYYY-MM-DD)
genero El género (hombre o mujer) Un campo de tipo enum, con los posibles valores H o M
avatar La fotografía o avatar elegido por el usuario, si decide ponerlo. Un identificador único generado por la API que hace la grabación. Los avatares estarán en formato JPG.
activo El estado del usuario. Un campo de tipo enum, para indicar si el miembro sigue activo o no. Los posibles valores son S o N.

Los campos de tipo cadena de longitud variable se han establecido con la longitud convencional de 255 caracteres máximo. Seguramente, nunca lleguen a ocuparse, pero la ventaja de los campos VARCHAR de MySQL es, como sabes, que si no se ocupa el espacio máximo, tampoco lo reserva, con lo que no aumenta innecesariamente el tamaño de la tabla. La estructura en SQL queda así:

LA LISTA DE USUARIOS

En la base de datos hemos creado una lista de cuatro usuarios ficticios para empezar construyendo nuestra aplicación por el componente encargado de mostrar esta lista. Una vez montado, su aspecto es el siguiente:

En realidad, el aspecto no es lo que nos interesa. Este es sólo bootstrap, que usaremos con más o menos acierto para hacer nuestra vista medianamente atractiva y usable. Lo que realmente nos importa, y es en lo que vamos a centrarnos, es la funcionalidad. Antes de que sigas adelante, déjame decirte que, en esta primera fase, los botones de nuevo y de editar los registros no funcionan aún (no hacen nada). Esto es porque estos botones deberán conducirnos a otro componente del que, de momento, no hemos tocado nada. Están ahí, pero no hacen nada aún.

Los que si son ya perfectamente funcionales son los botones destinados a cambiar la ordenación, y los de eliminar registros. Vamos a ver la operativa.

EL SERVICIO

Aunque en el artículo anterior creamos dos servicios, en este componente usamos sólo uno de ellos: HttpConnectService. Este servicio contendrá todas las llamadas a API’s que necesite el MembersModule pero, por ahora, sólo contiene las que necesita el componente MembersListComponent. Son dos: la encargada de leer la lista de usuarios, y la que borra un usuario cuando se solicita desde la vista. El código queda así:

Como ves, en esta ocasión en el servicio solo hemos incluido los dos métodos de conexión con API’s que obtienen (o no) un observable, pero no lo procesamos aquí. Eso lo hacemos en la lógica del componente (members-list.component.ts):

Aquí ves que en la lógica del componente hemos incluido todos los métodos necesarios para la gestión de ese componente. El código es muy fácil de analizar, por dos razones: la primera es que no hay, realmente, nada nuevo. La segunda es que lo he llenado de comentarios para que sepas lo que hace cada método y por qué está ahí. Te sugiero que lo revises, junto con la vista y el css, porque en el próximo artículo cambiaremos alguna cosa, y seguiremos consolidando conocimientos.

CONCLUYENDO

En este artículo hemos preparado la lista de usuarios registrados en un componente específico, y hemos separado la lógica en dos partes: el servicio del móduo y el propio TypeScript del componente. La vista y el css no los he listado aquí porque, realmente, no aportan nada que no sepas ya. Hasta ahora estamos usando lo mismo que ya conocemos, con más o menos adornos, o colocando las cosas en uno u otro sitio. La aplicación, en su estado actual, te la puedes descargar en este enlace. En el próximo artículo vamos a seguir ampliando este CRUD, viendo detalles interesantes.

   

Deja un comentario