- Il est facile de le manquer : la première fois que vous mettrez en place un override, votre navigateur vous demandera certainement de sélectionner un dossier dans lequel les placer. Si vous voyez que vous ne pouvez pas modifier la réponse, c’est que vous avez peut-être oublié de renseigner ce dossier.
-
Vous ne pouvez pas directement créer d’override
pour une erreur ou une réponse qui n’a pas encore été mise
en place. Ma méthode, pour forcer un override sur
une route qui n’existe pas encore, consiste soit à :
- Créer une route factice côté back-end avec une réponse simple que je modifie ensuite avec les overrides.
-
Côté front-end, changer l’URL de la requête afin
de cibler un endpoint renvoyant une réponse
(cela pourrait très bien être
https://jsonplaceholder.typicode.com/posts/1)
-
Souvenez-vous que vous avez mis en place des overrides ! Combien de fois ne m’est-il pas arrivé de me demander pourquoi les modifications faites côté back-end n’avaient aucun effet ou pourquoi l’application ne marchait plus — tout cela, à cause des overrides.
Fort heureusement, une icône est affichée dans l’onglet réseau pour vous aider à vous en rendre compte.
Retour
En attendant le back-end
Introduction
La situation est courante : vous travaillez sur la partie front-end d’une application, mais les données retournées par le back-end sont, soit inexistantes, soit en retard par rapport au modèle dont vous avez besoin. Voici quelques astuces pour vous aider à avancer malgré cela.
Les overrides
Un moyen très simple pour mettre à jour le format de réponse du serveur lorsqu’on travaille sur une nouvelle fonctionnalité ou que l’on souhaite simplement faire des tests est d’utiliser l’outil override fourni par les DevTools du navigateur. Si vous utilisez un dérivé de Chromium, ce guide explique très bien comment procéder : Override web content and HTTP response headers locally. Pour Firefox, voyez ici : Network overrides. Enfin, pour Safari, c’est expliqué ici : Local Overrides.
Les outils de test API
Si vous disposez déjà de collections ou avez l’habitude d’utiliser des outils de test API (comme Bruno ou Postman), vous pouvez mettre en place un serveur factice (mock server) et aisément tester l’interface avec un back-end simulé. Pour plus de détails, je vous renvoie aux documentations respectives de Bruno — Mock servers et Postman — Simulate your API in Postman with a mock server.
json-server est un outil qui rentre également dans cette catégorie : c’est un moyen très simple de simuler une API Rest au moyen d’une bibliothèque npm.
MSW
MSW est probablement la solution la plus professionnelle pour simuler des réponses, mais le coût de mise en place est sensiblement plus élevé : il est nécessaire de configurer la bibliothèque, apprendre comment s’articulent ses différentes composantes, et idéalement, vous mettre d’accord au sein de l’équipe de la façon d’utiliser cette bibliothèque.
En effet, msw n’est pas, comme les autres solutions proposées, quelque chose qui se met à la volée pour tester rapidement : cette bibliothèque permet, de façon évolutive, de tester votre interface avec un minimum de friction avec le back-end. Idéalement, vous ne devriez pas même avoir besoin de rédiger le code porteur des données factices : avec une approche contract-first, vous devriez pouvoir le générer via le contract OpenAPI avec des outils comme Kubb.
Bonne nouvelle si vous utilisez GraphQL : msw permet de travailler avec des API de ce type également (Mocking GraphQL).
Modifier le code côté front-end
Ce qui va sans dire va toujours mieux en le disant et il n’y a aucune honte à l’admettre : parfois, il est beaucoup plus expéditif de modifier en dur dans le code côté front-end afin d’obtenir la réponse attendue.
C’est tout pour les confessions ; je sens déjà mon âme plus pure.