🍪📖 Encapsule tes dictionnaires dans des classes dédiées

Au programme aujourd’hui :

• Encapsule tes dictionnaires dans des classes dédiées par Mélanie

Temps de lecture : 5 minutes

---

Hello les petits Biscuits ! Bonne et heureuse année à tous, prenez soins de vous ❤️

Bienvenue sur la 29ème édition de Ruby Biscuit.
Vous êtes maintenant 546 abonnés 🥳

Maintenant Ruby biscuit, c’est aussi votre meilleur allié pour recruter des devs Ruby !
Si vous n’avez pas encore rejoint le club, RDV sur https://recrutement.rubybiscuit.fr

Bonne lecture

---

Dans les applications Rails, il est courant de travailler avec des API : que ça soit pour créer des documents à signer, intégrer un prestataire de paiement, envoyer des informations à un site vitrine ou encore utiliser l’API de Google Maps pour la géolocalisation. Dans la plupart des cas, cela implique de transmettre à ces API des hashes (dictionnaires) de paramètres, plus ou moins longs. Chaque valeur de ces dictionnaires doit impérativement respecter le format attendu par l’API, sans quoi une erreur est vite arrivée.

Chez Capsens, nous avons récemment décidé d’améliorer notre manière de gérer ces dictionnaires pour réduire des erreurs fréquentes de formatage. Comment ? En les encapsulants dans des fichiers dédiés.

Cette pratique, en apparence anodine, rend le code plus lisible, plus réutilisable et surtout plus facilement testable. Dans cet article, je vais vous présenter notre méthode et tenter de vous convaincre de l’adopter vous aussi.

Pour illustrer mon propos, nous allons prendre comme exemple un service qui crée un document au format PDF à l'aide de l'API Doclift. Ce document correspond à un contrat généré après une souscription financière à un projet.

Doclift est une API qui permet la génération dynamique de vos documents PDF.
Vous créez vos templates de document directement sur l'app Doclift (entièrement codée en RoR), vous y ajoutez des variables et via l'API vous envoyez le contenu des variables. Pratique !
Vous trouverez son fonctionnement détaillé ici : https://www.doclift.io/how-it-works

Voici la V1 de notre service :

Ici on constate donc qu'il y a beaucoup de paramètre à envoyer pour la génération de notre document. Le format des variables étant pré-défini dans Doclift lors de la création du template, il est essentiel de le respecter à la lettre avant d'envoyer le dictionnaire. On retrouve certaines méthodes spécifiques au formatage des données, qui ne sont utiles que dans ce contexte.

Les tests associés :

Inconvénient d'avoir son dictionnaire directement dans son service :

• Trop de responsabilités pour le service

• On ne teste pas les dictionnaires alors qu'ils sont la cause de bcp d'erreurs. Erreurs qui peuvent être critiques en fonction du moment où se fait la génération du document. Au milieu d'un flow de souscription dans notre cas.

• Dictionnaire non réutilisable

Bien sûr, nous pourrions améliorer nos tests et tester davantage notre dictionnaire ici, mais cela alourdirait les tests de notre service, tout comme la création du hash alourdit déjà ce dernier. Cela ne résoudrait pas non plus le problème de réutilisabilité. Si demain nous devons gérer un second template de contrat avec seulement quelques variantes mais des paramètres globalement similaires, il serait bien plus intéressant de ne pas tout réécrire.

Alors comment avons nous amélioré notre code

Vous remarquerez en particulier :

Doclift::SubscriptionDictionary.new(
  @subscription
).to_h

Les tests :

• Ceux du service pourraient rester les mêmes

• Test du dictionnaire :

Il est maintenant facile de tester son dictionnaire et en prime, avec différents contextes.

Nous avons donc une solution :

• Facilement testable et maintenable

• Qui allége le service

• Réutilisable

Bien sûr si vous utilisez une gem comme Draper pour avoir des décorateurs sur votre application, il est tout à fait possible de créer des décorateurs plutôt que des dictionnaires !

Au mois prochain !

— Mélanie