Seguimos en liza. En las entradas anteriores vimos como configurar las rutas para poder separar nuestro proyecto en la parte “frontend” o la que vera el usuario, y la parte “backend” o zona de administración de los contenidos. También configuramos nuestra app para poder tener las variables de entorno separadas en desarrollo y producción.

Hasta este momento, a la hora de buscar un usuario correcto, utilizabamos dos direcciones de correo y sus contraseñas “hardcodeadas” en el archivo de login.

Esto, evidentemente, es mala idea, lo que necesitamos es que nuestros usuarios puedan entrar con las credenciales que tengan en la base de datos. Y para ello vamos a consumir nuestra api Laravel que hemos ido desarrollando.

Una vez tenemos configurados los entornos, es hora de comenzar a consumir nuestra API de Laravel, comenzando con la llamada de login de usuario.

Para ello, realizaremos algunos cambios.

Servicios.

Primero crearemos un nuevo servicio llamado “user.service.ts”, que contendrá la clase para los datos del login. Dicho archivo quedará así:

Despues, en login.service.ts, realizaremos algunos cambios. Comenzaremos por adecuar los imports:

Despues la clase y el constructor, donde añadiremos el objeto http para poderlo utilizar en la llamada a la api:

Ahora, y por no cambiar de momento el orden de las funciones con respecto al momento anterior del login, para no perdernos, adecuamos la función logout, de tal manera que borre los datos que se recogieron al conseguir un login correcto.

Y ahora viene el login. Hay varios cambios con respecto al anterior. Donde antes unicamente se comprobaba si los datos estaban en el array de usuarios que teniamos hardcodeado, ahora es necesario realizar una petición http a la api para que nos devuelva los datos adecuados del usuario o bien un error de existir algún problema.

Para ello, en la funcion, conformamos las cabeceras (headers), el cuerpo (body) y las opciones de la petición (request) que vamos a efectuar, y esperaremos que nos devuelva una respuesta (response) que será la que trataremos.

Hasta aquí es sencillo, ¿no?. Bueno, el cambio mayor en esta funcion es que la función login(user) pasa a ser una promesa (promise) de angular. Y esto es así porque necesitamos que se efectue el login y que según el resultado la aplicación efectue una acción u otra. En otros momento que se necesiten cargas asincronas de datos, será posible usar los Observables de Angular, pero, en mi humilde opinión, en este caso que se necesita disponer de la respuesta a la petición para poder tomar una decisión sobre si dejar actuar al usuario o no, es mejor utilizar una Promise, que nos permite esperar la respuesta de una forma más sencilla, ya que tiene dos eventos (reject y resolve) para las situaciones de error y satisfactorias, que nos permitiran tomar las decisiones adecuadas para el caso.

Para ello, al declarar la función login(user) le añadimos que sera de parametro Promise<any>.

La función queda así (ahora sigo desgranandola):

Cómo se puede observar, se genera el usuario a realizar el login (usertologin), se generan las cabeceras, cuerpo y opciones para la petición (headers, body y options), y se efectua la petición http, y su respuesta es la que se devuelve como resultado de la función. Si se observa la implementación, se utiliza la petición http también como una promesa al ponerla el modificador .toPromise(), y se utilizan los bifurcadores .then() y .catch() para recibir el resultado, bien satisfactorio o bien de error, y se envían a dos funciones auxiliares que trataran los datos.

Y las funciones auxiliares quedan como sigue:

Esta función ya la utilizabamos para decidir si volviamos al login porque el usuario no estuviera guardado en memoria, y de momento no se ha cambiado.

En esta funcion resolvemos el error que nos haya podido dar la petición. En este caso lo que hacemos es escribir en la consola el error (recomiendo comentar esta línea antes del paso a producción), y devolvemos el rechazo de la promesa y devolvemos el error, que ya viene personalizado de la api para los casos adecuados.

Y esta es la función de login satisfactorio. Como veis es similar a la anterior, pero esta vez resolviendo la promesa satisfactoriamente y devolviendo los datos de usuario para que sean tratados.

Componente.

Ahora, en el componente de nuestro formulario de login, que controla su funcionamiento, es donde le diremos que debe hacer con estos nuevos datos, y lo adecuaremos a la nueva situación.

Como se puede observar, lo que se ha hecho es utilizar la llamada al servicio para generar una respuesta, y en función de los datos obtenidos, bien redirigir al usuario al inicio de la administración, o bien presentarle un mensaje de error en el formulario, para que pueda observar que está mal introducido o si ha habido algún otro error.

Y con esto estaremos en disposición de continuar.

Nota: Es posible que os encontreis con problemas de CORS (recursos remotos) cuándo trateis de hacer el login y lo esteis viendo en las consolas de los navegadores. Vereis que los clientes REST que utiliceis funcionan correctamente, pero el login de nuestro servidor de desarrollo angular (localhost:4200, el creado con npm start) no hay forma de hacerlo andar. De forma rápida, aunque no es lo adecuado en sitios de producción, lo que debeis hacer es que en el servidor que este sirviendo la api (iis, apache, nginx, etc) hagais que para la api siempre mande la cabecera “Access-Control-Allow-Origin” con el valor “*”. y que os instaleis una extensión en el navegador que os permita activar o desactivar el CORS a voluntad.