🍪🧑‍🔧 Crée des partials robustes et maintenables avec les strict locals

Temps de lecture : 5 minutes

Hello les petits Biscuits !

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

---

Ruby Biscuit, c’est aussi votre meilleur allié pour trouver un job !

🎯 En ce moment, nous recherchons 5 profils Ruby confirmé·es ou intermédiaires pour des postes au sein de notre réseau.
Écrivez-nous ou postulez directement sur le site !

Bonne lecture ❤️

---

Crée des partials robustes et maintenables avec les strict locals

Lorsque nos vues deviennent complexes ou grandes, ou que des parties doivent être réutilisées ailleurs dans notre application, un découpage en partial s'impose.

Nous avons souvent besoin d'accéder à des variables dans ces partials et il n'est pas rare d'utiliser des variables d'instance qui viennent de notre action de controller car elles sont faciles d'accès partout dans nos vues et dans nos partials, peu importe le niveau d'imbrication. Wait ... est ce que pratique rime avec maintenable ? 🤔

L'aspect négatif de cette méthode est qu'elle rend nos partials très dépendantes de nos actions de controller : si une autre vue souhaite utiliser notre partial, l'action de controller qui lui est associée devra implémenter cette variable d'instance, sans que ça ait vraiment forcément du sens dans le contexte de cette action.
Pire, si ce controller implémente déjà une variable d'instance du même nom, on pourrait se retrouver à utiliser dans notre partial une variable erronée dans ce contexte sans le savoir.

Chez Capsens nous avons pris la décision d'interdire l'utilisation des variables d'instance dans nos partials pour privilégier l'utilisation systématique des locals.

Cela a l'avantage de faciliter la lecture des partials, on sait exactement d'où viennent nos variables et nos partials deviennent auto-suffisantes : il suffit de passer les bonnes variables en paramètres pour l'utiliser : moins de magie, moins d'indirection et des tests plus faciles à écrire.

Afin de rendre nos partials robustes et de s'assurer qu'on n'oublie pas de leur passer telle ou telle variable, Rails nous met à disposition un outil très pratique : les strict locals.

Cette notation permet de déclarer quelles sont les variables que notre partial accepte et lesquelles sont obligatoires ou optionnelles. En cas de variable manquante, ou en trop, notre partial levera une erreur automatiquement. Elle prend la forme d'un "commentaire magique", avec une syntaxe spécifique dans lequel nous allons lister les paramètres de notre partial.

Exemple :

Dans cet exemple notre partial prend deux valeurs : une subscription, obligatoire (la partial va donc lever une exception si jamais on ne lui passe pas cette valeur) et une autre display_rate qui est passée optionnellement et sera par default à true.

N'oubliez pas d'aller jeter un coup d'oeil à la doc !

BONUS - Tests des partials

Nous avons pris l'habitude de tester unitairement nos partials afin de s'assurer que nos vues ne génèrent pas d'erreurs, ce qui évite des tests de requêtes lourds, compliqués, avec des tonnes de contexte selon les conditions d'affichage des éléments dans la vue associée. L'utilisation des locals et des strict locals par rapport aux variables d'instances nous permet de simplifier le setup de nos tests : on peut passer simplement nos variables en paramètre de notre partial plutôt que de devoir tricher pour créer des variables d'instances et un faux controller.

Avec RSpec, ajouter ces lignes dans le fichier spec/rails_helper.rb permettra d'accéder aux méthodes de helper de Devise pour, par exemple, avoir un utilisateur connecté dans notre test :

config.include Devise::Test::ControllerHelpers, type: :view
config.include Devise::Test::IntegrationHelpers, type: :view

Exemple d'un test unitaire de partial :

— Eliot