Análisis profundo de Mirage JS: comprensión del tiempo, la respuesta y la transferencia (Parte 3)

En esta tercera parte de la serie Mirage JS Deep Dive, nos centraremos en el uso de responsey timingen passthroughMirage para manejar mejor la simulación de un servidor backend real. Sin embargo, antes de comenzar a leer este artículo, lea primero la introducción a MirageJS , así como las Partes 1 y 2 de esta serie.

Mirage JS se creó para brindar a los desarrolladores de frontend la capacidad de simular llamadas API de backend reales. Hasta ahora, hemos visto cómo podemos crear registros con Mirage, interceptar solicitudes de API a través de controladores de ruta y, por último, pero no menos importante, cómo se ve afectada la forma de los datos que nos devuelve Mirage.

En esta parte de la serie, veremos el mecanismo de Mirage para simular otros aspectos de un servidor backend real, como una red lenta, una respuesta de código de estado HTTP y también realizar solicitudes a un backend real aunque Mirage esté interceptando sus solicitudes de frontend.

Comencemos simulando solicitudes de red lentas.

Momento

Al desarrollar su aplicación frontend que se basa en una API backend, es útil ver cómo se comporta su aplicación en redes lentas (piense en probar la carga de mensajes y cargadores). Esta prueba es importante porque las solicitudes a la API de backend son de naturaleza asincrónica . Lo que esto significa es que no podemos hacer suposiciones sobre cuándo obtendremos la respuesta, por lo que debemos escribir nuestro código como si pudiera llegar inmediatamente o como si hubiera un retraso.

Una razón común para una demora en la respuesta es una conexión a Internet lenta. Entonces es muy importante saber cómo se comportaría su aplicación en tales circunstancias. Mirage satisface esta necesidad poniendo a disposición una timingopción que es una propiedad pasada a un controlador de ruta que le indica al controlador que espere un período particular especificado por la opción de tiempo (en milisegundos) antes de devolver una respuesta cada vez que se llama a la ruta que está manejando. .

Nota : De forma predeterminada, Mirage establece un 400msretraso para el servidor durante el desarrollo y 0durante las pruebas para que sus pruebas puedan ejecutarse más rápido (a nadie le gustan las pruebas lentas).

Ahora sabemos, en teoría, cómo personalizar el tiempo de respuesta del servidor de Mirage. Veamos un par de formas de modificar ese tiempo de respuesta mediante la timingopción.

timingEn rutas()

Como se indicó anteriormente, Mirage establece un retraso predeterminado para el tiempo de respuesta del servidor 400msdurante el desarrollo y 0las pruebas. Puede anular este valor predeterminado en el routesmétodo de la instancia del servidor.

En el siguiente ejemplo, estoy configurando la timingopción 1000msen el routesmétodo para establecer artificialmente el retraso de respuesta para todas las rutas:

import { Server } from 'miragejs'new Server({    routes() {        this.routes = 1000    }})

Lo anterior le dice a Mirage que espere 1000milisegundos antes de devolver una respuesta. Entonces, si su interfaz realiza una solicitud a un controlador de ruta como el siguiente:

this.get('/users', (schema) = {    return schema.users.all();});

Mirage tardará 1000 milisegundos en responder.

Consejo : en lugar de usar directamente el schemaobjeto, puede usar la reestructuración de objetos de ES 6 para hacer que su controlador de ruta sea más limpio y más corto, como se muestra a continuación:

this.get('/users', ({ users }) = {    return users.all()}

timingPara rutas individuales

Aunque la this.timingpropiedad es útil, en algunos escenarios no querrás retrasar todas tus rutas. Debido a este escenario, Mirage le brinda la posibilidad de configurar la timingopción en un objeto de opciones de configuración que puede pasar al final de un controlador de ruta. Tomando nuestros fragmentos de código anteriores, pasemos el 1000msretraso de respuesta a la ruta misma en lugar de configurarlo globalmente:

this.get('/users', ({ users }) = {  return users.all(); }, { timing: 1000 });

El resultado es el mismo que asignar globalmente el tiempo. Pero ahora tiene la posibilidad de especificar diferentes retrasos para rutas individuales. También puede establecer un tiempo global this.timingy luego anularlo en un controlador de ruta. Al igual que:

this.timing = 1000this.get('users', ( { users } ) = {    return users.all()})this.get('/users/:id', ({ users }, request) = {    let { id } = request.params;     return users.find(id); }, { timing: 500 });

Entonces, ahora, cuando hagamos una solicitud a /users/1, devolverá el siguiente JSON de usuario en la mitad del tiempo (500 ms) que tomaría para cualquier otra ruta.

{  "user": {    "name": "Kelvin Omereshone",    "age": 23,    "id": "1"  }}

Pasar por

Los controladores de ruta son el mecanismo de Mirage para interceptar las solicitudes que realiza su aplicación frontend. De forma predeterminada, Mirage generará un error similar al siguiente cuando su aplicación realiza una solicitud a un punto final para el que no ha definido un controlador de ruta en su instancia de servidor.

Error: Mirage: su aplicación intentó hacerlo GET '/unknown', pero no había ninguna ruta definida para manejar esta solicitud. Defina una ruta para este punto final en su routes()configuración. ¿Olvidaste definir un espacio de nombres?

Sin embargo, puede decirle a Mirage que si ve una solicitud para una ruta para la que no definió un controlador de ruta, debería permitir que se realice esa solicitud. Esto es útil si tiene un backend real y desea utilizar Mirage para probar puntos finales que aún no se han implementado en su backend. Para hacer esto, deberá realizar una llamada al passthroughmétodo dentro de los routesmétodos en su instancia del servidor Mirage.

Veámoslo en código:

import { Server } from 'miragejs'new Server({    routes() {        // you can define your route handlers above the passthrough call        this.passthrough()    }})

Nota : Se recomienda mantener la llamada passthroughen la parte inferior para dar prioridad a los controladores de ruta.

Ahora, cuando Mirage vea solicitudes a una ruta que usted no definió en Mirage, las permitirá "pasar". Realmente lo encuentro útil porque hace que Mirage funcione bien con un backend real. Entonces, un escenario sería: usted está por delante de su equipo de backend y desea realizar una solicitud a un punto final que no tiene en su backend de producción, podría simplemente simular ese punto final en Mirage y, debido a la passthroughopción, No tendría que preocuparse de que otras partes de su aplicación realicen solicitudes fallidas.

Uso passthroughde la ruta en la lista blanca

passthroughIncluye opciones que le permiten tener más control sobre las rutas que desea incluir en la lista blanca. Entonces, en lugar de llamar passthroughsin ninguna opción y permitir rutas que no están presentes en Mirage passthrough, puede pasar una o más cadenas de las rutas que desea incluir en la lista blanca passthrough. Entonces, si queremos incluirlo en la lista blanca /reviews, /petspodemos hacerlo passthroughasí:

this.passthrough('/reviews', '/pets)

También puedes hacer múltiples llamadas a passthrough:

this.passthrough('/reviews')this.passthrough('/pets')

Nota : encuentro pasar varias cadenas de ruta al passthroughlimpiador en lugar de realizar varias llamadas. Pero eres libre de usar lo que te parezca natural.

Usar passthroughen un conjunto de verbos HTTP

Lo anterior passthroughque definimos permitirá que todos los verbos HTTP (GET, POST, PATCH, DELETE) passthrough. Si su caso de uso requiere que permita un subconjunto de verbos HTTP passthrough, Mirage proporciona una matriz de opciones en el passthroughmétodo en el que pasa los verbos que desea que Mirage incluya en la lista blanca en una ruta particular. Veámoslo en código:

// this allows post requests to the /reviews route to passthroughthis.passthrough('/reviews', ['post']);

También puedes pasar varias cadenas de rutas, así como la matriz de verbos HTTP, así:

// this allows post and patch requests to /reviews and /pets routes to passthroughthis.passthrough('/pets', 'reviews', ['post', 'patch'])

Respuesta

Ahora que ve el nivel de personalización que Mirage le ofrece tanto con la timingopción como con passthroughel método, le parece natural saber cómo personalizar el código de estado HTTP que Mirage envía para las solicitudes que realiza. De forma predeterminada, Mirage devolvería un estado que 200dice que todo salió bien. (Consulte este artículo para obtener un repaso sobre el código de estado HTTP). Sin embargo, Mirage proporciona la Responseclase que puede usar para personalizar el código de estado HTTP, así como otros encabezados HTTP que se enviarán a su aplicación frontend.

La Responseclase le brinda más control sobre su controlador de ruta. Puede pasar lo siguiente al constructor de la clase Respuesta :

• El código de estado HTTP,
• encabezados HTTP ,
• Datos (una carga útil JSON que se devolverá al frontend).

Para ver cómo Responsefunciona la clase, comenzaríamos con una nota sencilla reescribiendo nuestro controlador de ruta anterior usando la Responseclase. Entonces tomaríamos el siguiente controlador de ruta:

this.get('users', ( { users } ) = {return users.all()})

y luego volver a implementar usando la Responseclase. Para hacer esto primero necesitamos importar la Responseclase desde Mirage:

import { Response } from 'miragejs'

Luego reescribiríamos nuestro controlador de ruta usando la Responseclase:

this.get('/users', ({ users }) = {    return new Response(200, {}, users.all());});

Nota : Pasamos un {}argumento vacío al encabezado porque no queremos establecer ningún valor de encabezado para esta respuesta.

Creo que podemos inferir que Mirage bajo el capó usa la Responseclase cuando regresamos anteriormente users.all()porque ambas implementaciones actuarían de la misma manera y devolverían la misma carga útil JSON.

Admito que el uso anterior de Responsees un poco detallado porque todavía no estamos haciendo nada especial. Sin embargo, la Responseclase tiene un mundo de posibilidades que le permite simular diferentes estados del servidor y establecer encabezados.

Configuración de estados del servidor

Con la Responseclase, ahora puedes simular diferentes estados del servidor mediante el código de estado, que es el primer argumento que Responsetoma el constructor. Ahora puede pasar 400 para simular una solicitud incorrecta, 201 para simular el estado creado cuando crea un nuevo recurso en Mirage, y así sucesivamente. Con eso en mente, personalicemos /users/:idel controlador de ruta y pasemos 404 para simular que no se encontró un usuario con la ID particular.

this.get('/users/:id', (schema, request) = {   let { id } = request.params;   return new Response(404, {}, { error: 'User with id ${id} not found'});});

Luego, Mirage devolvería un código de estado 404 con un mensaje de error similar a la siguiente carga útil JSON:

{  "error": "User with id 5 not found"}

Configuración de encabezados

Con la Responseclase, puede establecer encabezados de respuesta pasando un objeto como segundo argumento al Responseconstructor. Con esta flexibilidad, puede simular la configuración de los encabezados que desee. Aún usando nuestra /users/:idruta, podemos configurar encabezados de esta manera:

this.get('/users/:id', (schema, request) = {     let { id } = request.params;     return new Response(404, {"Content-Type" : "application/json", author: 'Kelvin Omereshone' }, { error: `User with id ${id} not found`});});

Ahora, cuando revise los registros de Mirage en la consola de su navegador, verá los encabezados que configuramos.

Terminando

En esta parte de la serie Mirage JS Deep Dive, he expuesto tres mecanismos que Mirage expone a sus usuarios para simular un servidor real. Espero verle utilizar mejor Mirage con la ayuda de este artículo.

¡Estén atentos a la próxima y última parte de la serie que se lanzará la próxima semana!

• Parte 1 : Comprensión de los modelos y asociaciones de Mirage JS
• Parte 2 : Comprensión de las fábricas, accesorios y serializadores
• Parte 3: Comprender el momento, la respuesta y la transferencia
• Parte 4 : Uso de Mirage JS y Cypress para pruebas de UI

(ra, il)Explora más en

• API
• javascript