Rails Afficher DRYness - Définissez-vous des variables dans la vue ou faites-vous simplement des méthodes propres?

Question

J'ai vue dans lequel j'ai le même lien 3 fois (vue réelle est grande):

%h1= link_to "Title", model_path(@model, :class => "lightbox") 
= link_to "Check it out", model_path(@model, :class => "lightbox") 
%footer= link_to "Last time", model_path(@model, :class => "lightbox") 

Ce model_path(@model, :class => "lightbox") appel, mais assez propre, peut être fait envelopper encore plus maigre dans ce (peut-être que vous aviez encore plus d'options, font donc cela en valait la peine):

def popup_model_path(model) 
    model_path(model, :class => "lightbox") 
end 

Ma question est, j'ai recalculer cette voie 3 fois dans une vue. Quelle est la meilleure façon de: a) Séchez-vous et b) optimisez la performance?

Je pense que la définition des variables en haut de la vue pourrait être une bonne idée ici:

- path = model_path(@model, :class => "lightbox") 
-# ... rest of view 

Il est presque comme la moustache à la fin alors. Quelles sont vos pensées?

Answer 1

I vraiment hate mettre des variables dans la vue. Je changerais votre aide pour

def popup_model_path(model) 
    @model_path ||= {} 
    @model_path[model] ||= model_path(model, :class => "lightbox") 
end 

à « memoize », et il suffit de garder les trois appels de fonction.

Answer 2

Je pense que l'utilisation de variables dans la vue est une bonne idée ici. Puisque ces appels de méthode sont exactement les mêmes. La solution telle que proposée par Matt je préfère dans certains cas, mais pas dans ce cas, parce que je trouve cela déroutant: le fait qu'il soit mis en cache dans la méthode n'est pas clair, et si je veux voir deux modèles différents dans une page je reçois toujours le premier lien en cache pour les deux modèles. Donc, dans ce cas, je choisirais l'approche un peu plus explicite et l'assignerais à une variable dans la vue.

Answer 3

Cela semble être un cas possible d'optimisation prématurée. Faire une fonction comme popup_model_path est une idée fantastiquement sèche. Surtout si ce morceau de code, aussi laconique soit-il à l'origine, va être utilisé fréquemment sur plusieurs vues. Cependant, s'inquiéter de l'impact sur les performances du calcul du chemin 3 fois dans une vue est, à mon avis, inutile. Sauf si nous parlons de quelque chose qui va être utilisé des dizaines ou des centaines de fois par vue, et vous attendez beaucoup d'utilisateurs simultanés, et l'application fonctionne sur un serveur partagé ou quelque chose que je ne vois vraiment pas ce que vous avoir actuellement un impact perceptible sur la performance.

En règle générale, je fais de mon mieux pour éviter les variables dans mon code de vue. Ils rendent la lecture plus difficile et, à quelques exceptions près (comme les variables directement liées aux boucles qui affichent des choses comme des listes), je pense qu'elles vont un peu à l'encontre du concept de MVC tel que je le comprends. Je pense par-dessus tout que vous devriez rechercher un code qui soit facilement lisible, compréhensible et maintenable; à la fois pour vous et pour les autres qui ne connaissaient pas votre projet. popup_model_path comme vous l'avez maintenant est assez simple pour quiconque sait qui Rails peut suivre ce que vous faites. Je ne vois aucun besoin de le rendre plus compliqué que cela, car ce n'est pas terriblement répétitif. J'aimerais pouvoir trouver cet excellent billet de blog dont je me souviens avoir lu il y a un moment qui disait que sécher votre code est génial, mais il a ses limites, et comme toutes les grandes choses, la loi des rendements décroissants finit par s'imposer.