1
votes

Quelle syntaxe recommandera entre try et &. quand nous avons affaire à une valeur nulle dans Ruby on Rails?

Comme le titre, à partir de la version 2.3.0 ruby. Nous pouvons utiliser Safe Navigation Operator (&.) Au lieu d'essayer de traiter une valeur nulle dans Rails. Mais lorsque j'utilise la nouvelle syntaxe, mon réviseur m'a dit que ce n'était pas bon pour le réviseur ou pour quelqu'un d'autre sur la signification de mon code. J'aimerais donc savoir quelle syntaxe dois-je utiliser lorsque je travaille avec une valeur nulle?

nil.try(:method)
nil&.method

ruby ruby-on-rails

1 commentaires

Vous devez utiliser la syntaxe que votre réviseur vous conseille d'utiliser. Peu importe ce que nous disons si vous ne faites jamais accepter votre code, car votre réviseur le rejette toujours.

3 Réponses :

3
votes

&. fonctionne comme #try! , pas comme #try . documentation
#try n'est pas natif dans ruby mais il est fourni par des rails.
La navigation sécurisée # &. est presque 3 à 4 fois plus rapide que l'utilisation du #try

      1.210000   0.000000   1.210000 (  1.211835)
      0.360000   0.000000   0.360000 (  0.363127)

Sortie

require 'active_support/all'
require 'benchmark'

foo = nil

puts Benchmark.measure { 10_000_000.times { foo.try(:boo) } }
puts Benchmark.measure { 10_000_000.times { foo&.boo } }

1 commentaires

Merci pour le détail des performances de la méthode de navigation sûre.

1
votes

try est une méthode fournie par Support actif de Rails

L'opérateur de navigation sécurisée est fourni par Ruby lui-même (depuis la version 2.3).

Si vous deviez ouvrir une console Ruby (pas Rails), et définir une méthode foo :

>> nil.try(:foo)
Traceback (most recent call last):
        4: from /Users/dinjas/.rbenv/versions/2.6.1/bin/irb:23:in `<main>'
        3: from /Users/dinjas/.rbenv/versions/2.6.1/bin/irb:23:in `load'
        2: from /Users/dinjas/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `<top (required)>'
        1: from (irb):7
NoMethodError (undefined method `try' for nil:NilClass)
>> nil&.foo
=> nil

Vous pourriez voir quelque chose comme ce qui suit:

def foo
  :bar
end

IMHO, je préfère en utilisant les méthodes Ruby plutôt que les méthodes Rails car elles sont utilisables en dehors du contexte de Rails.

Cela dit, je pense aussi que quoi que vous utilisiez, il devrait être utilisé avec parcimonie. D'après mon expérience, c'est un symptôme de l'écriture de code timide (voir le livre d'Avdi Grimm, Confident Ruby ). P >

0 commentaires

2
votes

Comme mentionné dans la réponse de @ dinjas, .try est une méthode fournie par Rails, alors que &. est une méthode qui est fournie par Ruby lui-même, et par conséquent, sera être également utilisable en dehors des applications Rails.

De plus, les deux opérateurs ne fonctionnent PAS EXACTEMENT de la même manière. L'opérateur de navigation sécurisée empêche NoMethodErrors uniquement dans les cas où il est appelé sur une valeur qui est nil . Par exemple:

a = nil
a&.do_something # Result: nil
a = false
a&.do_something # Result: NoMethodError: undefined method `asd' for false:FalseClass

a.try(:do_something) # Result: nil

Comme vu ci-dessus, tandis que .try gère également les fausses valeurs et renvoie nil comme réponse lorsqu'une méthode est appelée sur un objet qui ne la prend pas en charge. Cependant, &. ne gère pas cela et invoque également des méthodes sur false . Il en va de même pour les chaînes vides.

En ce qui concerne ce que vous devez utiliser, je pense que cette décision doit être prise en discutant avec votre équipe. Je pense qu'aucune des méthodes n'est incorrecte et que l'une ou l'autre peut être utilisée. Cependant, je recommanderais fortement de ne pas utiliser les DEUX try et &. dans toute la base de code car cela pourrait entraîner des effets inattendus si la base de code s'agrandit.

Ce blog de Georgi Mitrev décrit la navigation en toute sécurité l'opérateur plus en profondeur et je recommanderais de le lire une fois.

0 commentaires