bookpaso1c - keblato/TutorialesTalleres-Angular GitHub Wiki

Book - paso 1b

Cambios en este paso:

Checkout del paso 1b

Comience por realizar el checkout del paso-1b del front. Si no encuentra la rama del paso1b significa que cuando clonó el proyecto no clonó esta rama, en ese caso por favor clone la rama.

git checkout -f paso-1b

Actualice, preferiblemente en una ventana de comandos, la instalación de paquetes con:

npm install

Conectarse desde la aplicación front al back

Lo primero es que para que su aplicación del front se pueda conectar a su aplicación del back, está debe estar ejecutándose. Entonces debe desplegarse en el servidor de aplicaciones de su máquina. Note que por defecto esta se ejecuta en el puerto 8080 y el servidor del front (node) se ejecuta en el puerto 4200

Para conectarse con el back, debe cambiar las variables que definen la URL de acceso a los servicios del API-REST. Debe ir a las clases servicio, por ejemplo EditorialService y reemplazar por la url donde está desplegada su aplicación back. En el caso de backstepbystep sería:

const API_URL = "http://localhost:8000/frontstepbystep-api/api";
const editorials = '/editorials';

Para no tener que cambiar en todos los componentes, hemos creado un json llamado environments/environment.ts que contiene el valor del API_URL.

Cambio en la aplicación back para permitir la conexión CORS

Para que la aplicación front que corre desde un servidor node pueda conectarse con la aplicación back que corre sobre un servidor payara, debemos habilitar el acceso desde la aplicación back, específicamente desde el proyecto donde se implementa el API-REST con Jax-RS.

Esto se hace con un mecanismo que implemente Intercambio de Recursos de Origen Cruzado (CORS cross-origin resource sharing). En nuestra implementación del API-REST en Jax-RS se hace agregando un filtro que interceptará las peticiones, las validará y dejará realizar el acceso.

Ud. debe copiar este filtro CORSFilter.java en el proyecto api en un paquete co.edu.uniandes.nombreproyecto.filters. Este filtro da permiso para acceder a todos los servicios desde cualquier parte. Para el ejemplo que estamos haciendo está bien pero obviamente es algo que hay que diseñar adecuadamente en una aplicación de verdad.

Una vez que cree este filtro, debe hacer clen&build y run del back.

Volver al Inicio

El manejo de errores que vienen del back en el front

Angular ofrece una librería, con un conjunto de servicios, para **interceptar **las peticiones http ya sea al momento de la salida de la petición hacia el API-Rest o del regreso de la petición desde el API-Rest.

Recordemos que los llamados a http como http.get o http.post están es muchos archivos, tantos como servicios tiene el API o más. Cada servicio de un módulo funcional con seguridad tiene muchos llamados a http. Si uno quiere preprocesar la invocación del request, por ejemplo, agregando información para autenticación, o preprocesar el retorno, por ejemplo para manejar los errores si el request viene en error, tendría que escribirse en cada lugar de la aplicación donde se hace un llamado hht.

La ventaja de tener esta librería que implementa el patrón de diseño Interceptor, es que el código se escribe en un solo lugar (se factoriza) de tal forma que los llamados individuales no hay que modificarlos sino que el interceptor se ocupará de las acciones que, eventualmente, hay que realizar antes o después del llamado.

En este paso , vamos a utilizar un interceptor para manejar el retorno de los request http cuando vienen con un código de error. Para capturar los mensajes de error enviados desde el API REST, ya sea porque el back envió un error 412 de una regla de negocio que falló o porque envió un error 500 de un fallo general en la aplicación, necesitamos mostrar el problema al usuario.El mensaje que vamos a mostrar será el que enviamos en las excepciones BusinessLogicException y WebApplicationException.

Para hacer esto necesitamos dos cosas:

  1. Crear un interceptor que atrape el regreso de un llamado http e identifique si viene con error.
  2. En cada llamado a un servicio donde se está usando http, debemos agregar una instrucción para que muestre el error.
Volver al Inicio

HttpInterceptor

Como este en un servicio general para toda la aplicación, creamos una carpeta llamada interceptors y allí un archivo httperrorinterceptor.service.ts.

La clase HttpErrorInterceptor debe ser una clase inyectable y debe extender de HttpErrorResponse:

@Injectable()
export class HttpErrorInterceptor  extends HttpErrorResponse

La clase debe implementar el método intercept . Este método recibe el request que va a interceptar y el siguiente interceptor. Lo que hace es construir un mensaje de error y llamar al servicio que lo va a a desplegar.

Despliegue del mensaje de error

Para desplegar el mensaje de error hacemos uso de la librería ngx-toastr. Esta dependencia ha sido agregada y se importa tanto en el app.module.ts como en los componentes.

El llamado que se hace es:

Para cambiar la configuración de la manera como se despliega el mensaje y como se puede quitar de la pantalla, ensaye las opciones en toster.

Puede probarlo modificando el back de modo que genere un error intencionalmente por ejemplo no ejecutando el servidor del back.

Volver al Inicio