Comprendre le timing, la réponse et le passage (partie 3)

Mirage JS a été conçu pour donner aux développeurs frontaux la possibilité de simuler de véritables appels d'API backend. Jusqu'à présent, nous avons vu comment créer des enregistrements avec Mirage, intercepter des demandes d'API via des gestionnaires de routes et, enfin et surtout, comment la forme des données qui nous sont retournées par Mirage est affectée.

Dans cette partie de la série , nous verrons le mécanisme Mirage pour simuler d'autres aspects d'un serveur d'arrière-plan réel comme le réseau lent, la réponse du code d'état HTTP, et aussi faire des demandes à un arrière-plan réel même si Mirage intercepte vos demandes frontales.

Commençons par simuler un réseau lent

Timing

Lors du développement de votre application frontend qui repose sur une API backend, il est utile de voir comment votre application se comporte sous des réseaux lents (pensez à tester les messages de chargement et les chargeurs). Ce test est important car les demandes d'API backend sont de nature asynchrone . Cela signifie que nous ne pouvons pas faire d'hypothèses sur le moment où nous obtiendrons la réponse, nous devons donc écrire notre code comme s'il pouvait venir immédiatement, ou qu'il pourrait y avoir un retard. est une connexion Internet lente. Il est alors très important de savoir comment votre application se comporterait dans de telles circonstances. Mirage répond à ce besoin en mettant à disposition une option timing qui est une propriété transmise à un gestionnaire d'itinéraire qui indique au gestionnaire d'attendre une durée particulière spécifiée par l'option timing (en millisecondes) avant de renvoyer une réponse chaque fois

Remarque : Par défaut, Mirage définit un délai 400 ms pour le serveur pendant le développement et 0 pendant les tests afin que vos tests puissent s'exécuter plus rapidement (personne n'aime vraiment les tests lents).

Nous savons maintenant en théorie comment personnaliser le temps de réponse du serveur de Mirage. Voyons quelques façons de modifier ce temps de réponse via l'option timing .

timing Sur routes ()

Comme indiqué précédemment, Mirage définit un délai par défaut pour le le temps de réponse du serveur doit être 400 ms pendant le développement et 0 pour les tests. Vous pouvez remplacer cette valeur par défaut sur la méthode routes sur l'instance de serveur.

Dans l'exemple ci-dessous, je configure l'option timing sur 1000ms dans le routes méthode pour définir artificiellement le délai de réponse pour toutes les routes:

 import {Server} de 'miragejs'

nouveau serveur ({
    routes () {
        this.routes = 1000
    }
})

Ce qui précède indique à Mirage d'attendre 1000 millisecondes avant de renvoyer une réponse. Donc, si votre serveur frontal fait une demande à un gestionnaire d'itinéraire comme celui ci-dessous:

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

Mirage prendra 1 000 millisecondes pour répondre.

Conseil : Au lieu d'utiliser directement l'objet schéma vous pouvez utiliser la restructuration d'objet ES 6 pour tracer votre itinéraire gestionnaire plus propre et plus court comme ci-dessous:

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

timing Pour les itinéraires individuels

Bien que la propriété this.timing soit utile, dans certains scénarios, vous ne voudriez pas retarder tous vos itinéraires. En raison de ce scénario, Mirage vous donne la possibilité de définir l'option timing dans un objet d'options de configuration que vous pourriez passer à la fin d'un gestionnaire d'itinéraire.
En prenant nos extraits de code ci-dessus, passons le délai de réponse de 1000 ms à l'itinéraire lui-même plutôt que de le définir globalement:

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

Le résultat est le même que l'attribution globale du timing. Mais maintenant, vous avez la possibilité de spécifier différents délais de temporisation pour des itinéraires individuels. Vous pouvez également définir une synchronisation globale avec this.timing puis la remplacer dans un gestionnaire d'itinéraire. Comme ceci:

 this.timing = 1000

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

this.get ('/ users /: id', ({users}, requête) => {
    let {id} = request.params;
     return users.find (id);
 }, {timing: 500});

Alors maintenant, lorsque nous faisons une demande à / users / 1 il renverra l'utilisateur JSON ci-dessous dans la moitié du temps (500 ms) qu'il faudrait pour tous les autres itinéraires.

 {
  "utilisateur": {
    "nom": "Kelvin Omereshone",
    "âge": 23,
    "id": "1"
  }
}

Passthrough

Les gestionnaires de route sont le mécanisme Mirage pour intercepter les requêtes de votre application frontale. Par défaut, Mirage générera une erreur similaire à celle ci-dessous lorsque votre application fera une demande à un point de terminaison pour lequel vous n'avez pas défini de gestionnaire d'itinéraire dans votre instance de serveur.

Erreur: Mirage: votre application a essayé de GET '/ unknown' mais aucune route n'a été définie pour gérer cette demande. Définissez un itinéraire pour ce noeud final dans votre configuration routes () . Avez-vous oublié de définir un espace de noms?

Vous pouvez cependant dire à Mirage que s'il voit une demande vers un itinéraire pour lequel vous n'avez pas défini de gestionnaire d'itinéraire, il doit autoriser le traitement de cette demande. Ceci est utile si vous disposez d'un backend réel et que vous souhaitez utiliser Mirage pour tester des points de terminaison qui n'ont pas encore été implémentés dans votre backend. Pour ce faire, vous devez appeler la méthode passthrough dans les méthodes routes dans votre instance de serveur Mirage.

Voyons cela dans le code:

 import {Serveur} de 'miragejs'

nouveau serveur ({
    routes () {
        // vous pouvez définir vos gestionnaires d'itinéraire au-dessus de l'appel passthrough
        this.passthrough ()
    }
})

Remarque : Il est recommandé de garder l'appel à passthrough en bas afin de donner la priorité à vos gestionnaires d'itinéraire.

Maintenant, quand Mirage voit des demandes à un itinéraire que vous n'avez pas défini dans Mirage, cela leur permettrait de «passer». Je trouve cela vraiment utile car cela fait que Mirage joue bien avec un backend réel. Donc, un scénario serait, vous êtes en avance sur votre équipe de backend et vous voulez faire une demande à un point de terminaison que vous n'avez pas dans votre backend de production, vous pouvez simplement simuler ce point de terminaison par mirage et à cause du passthrough vous n'aurez pas à vous soucier de l'échec des autres parties de votre application.

Utilisation de passthrough Vers la liste blanche

passthrough accepte les options pour vous permettre d'avoir plus de contrôle sur les itinéraires que vous souhaitez ajouter à la liste blanche. Ainsi, au lieu d'appeler passthrough sans aucune option et d'autoriser les itinéraires non présents dans mirage vers passthrough vous pouvez transmettre une ou plusieurs chaînes des itinéraires que vous souhaitez ajouter à la liste blanche passthrough . Donc, si nous voulons mettre sur liste blanche / reviews et / pets nous pouvons le faire en utilisant passthrough comme ceci:

 this.passthrough ('/ reviews', '/animaux domestiques)

Vous pouvez également effectuer plusieurs appels vers passthrough :

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

Remarque : Je trouve que le passage de plusieurs chaînes de routage vers le passthrough est plus propre que d'effectuer plusieurs appels. Mais vous êtes libre d'utiliser tout ce qui vous semble naturel.

Utilisation du passthrough sur un ensemble de verbes HTTP

Le passthrough ci-dessus que nous avons défini permettra tous les verbes HTTP (GET , POST, PATCH, DELETE) à passthrough . Si votre cas d'utilisation vous oblige à autoriser un sous-ensemble des verbes HTTP à passer Mirage fournit un tableau d'options sur la méthode passthrough dans lequel vous passez les verbes que vous voulez que Mirage ajoute à la liste blanche sur un itinéraire particulier. Voyons cela dans le code:

 // cela permet de publier des demandes vers la route / reviews vers le passthrough
this.passthrough ('/ reviews', ['post']);

Vous pouvez également transmettre plusieurs chaînes de routes ainsi que le tableau de verbes HTTP comme ceci:

 // ceci permet aux demandes de publication et de correctif de / revues et / des routes d'animaux de compagnie à passer

this.passthrough ('/ pets', 'reviews', ['post', 'patch'])

Réponse

Vous voyez maintenant le niveau de personnalisation que Mirage vous offre avec l'option de synchronisation et la méthode passthrough il vous semble naturel de savoir comment personnaliser le Le code d'état HTTP que Mirage envoie pour les demandes que vous faites. Par défaut, Mirage renverrait un état de 200 qui indique que tout s'est bien passé. (Consultez cet article pour une mise à jour sur le code d'état HTTP.) Mirage, cependant, fournit la classe Response que vous pouvez utiliser pour personnaliser le code d'état HTTP ainsi que d'autres en-têtes HTTP. à renvoyer à votre application frontend.

La classe Response vous donne plus de contrôle sur votre gestionnaire d'itinéraire. Vous pouvez transmettre ce qui suit au constructeur de la classe Response :

• Le code d'état HTTP,
• En-têtes HTTP
• Données (une charge utile JSON à renvoyer au frontend)

Pour voir comment fonctionne la classe Response nous commencerions sur une note facile en réécrivant notre gestionnaire d'itinéraires précédent en utilisant la classe Response . Nous prendrions donc le gestionnaire d'itinéraire ci-dessous:

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

puis réimplémentation en utilisant la classe Response . Pour ce faire, nous devons d'abord importer la classe Response de Mirage:

 import {Response} de 'miragejs'

Nous réécririons alors notre gestionnaire d'itinéraire en utilisant la classe Response :

 this.get ('/ users', ({users}) => {
    renvoyer une nouvelle réponse (200, {}, users.all ());
});

Remarque : Nous passons un {} vide à l'argument d'en-tête car nous ne voulons pas définir de valeurs d'en-tête pour cette réponse. [19659005] Je pense que nous pouvons déduire que Mirage sous le capot utilise la classe Response lorsque nous avons précédemment renvoyé users.all () car les deux implémentations agiraient de la même manière et renverraient le même JSON

J'admets que l'utilisation ci-dessus de La ​​réponse est un peu verbeuse parce que nous ne faisons rien de spécial pour le moment. Cependant, la classe Response contient un monde de possibilités qui vous permet de simuler différents états de serveur et de définir des en-têtes.

Définition des états de serveur

Avec la classe Response vous pouvez simulez maintenant différents états du serveur via le code d'état qui est le premier argument pris par le constructeur Response . Vous pouvez désormais passer 400 pour simuler une mauvaise requête, 201 pour simuler l'état créé lorsque vous créez une nouvelle ressource dans Mirage, etc. Dans cet esprit, personnalisons le gestionnaire de route / users /: id et passons 404 pour simuler qu'un utilisateur avec l'ID particulier n'a pas été trouvé.

 this.get ('/ users /: id ', (schéma, requête) => {
   let {id} = request.params;
   renvoie une nouvelle réponse (404, {}, {erreur: 'L'utilisateur avec l'ID $ {id} est introuvable'});
});

Mirage retournerait alors un code d'état 404 avec le message d'erreur similaire à la charge utile JSON ci-dessous:

 {
  "erreur": "Utilisateur dont l'ID 5 est introuvable"
}

Avec la classe Response vous pouvez définir des en-têtes de réponse en passant un objet comme deuxième argument au constructeur Response . Avec cette flexibilité, vous pouvez simuler la définition des en-têtes de votre choix. Toujours en utilisant notre route / users /: id nous pouvons définir des en-têtes comme ceci:

 this.get ('/ users /: id', (schéma, requête) => {
     let {id} = request.params;
     return new Response (404, {"Content-Type": "application / json", auteur: 'Kelvin Omereshone'}, {erreur: `Utilisateur dont l'ID $ {id} est introuvable`});
});

Maintenant, lorsque vous vérifiez les journaux Mirage dans la console de votre navigateur, vous voyez les en-têtes que nous avons définis.

Conclusion

Dans cette partie de la série Mirage JS Deep Dive, j'ai exposé trois mécanismes auxquels Mirage s'expose. ses utilisateurs afin de simuler un vrai serveur. J'ai hâte de vous voir mieux utiliser Mirage à l'aide de cet article.

Restez à l'écoute pour la prochaine et dernière partie de la série à venir la semaine prochaine!

• Partie 1 : Comprendre Mirage JS Modèles et associations
• Partie 2 : Comprendre les usines, les montages et les sérialiseurs
• Partie 3: Comprendre le timing, la réponse et le passage

(ra, il) [19659078]

Le meilleur outil 2023 pour ta croissance Instagram !

Source link

Partager :

• Cliquez pour partager sur Twitter(ouvre dans une nouvelle fenêtre)
• Cliquez pour partager sur Facebook(ouvre dans une nouvelle fenêtre)