Logique booléenne avec les variables ENV de Rails

Question

Comme les variables ENV de Rails ne doivent avoir que des valeurs de type chaîne de caractères, il peut être difficile de décider comment utiliser les variables ENV pour les cas d'utilisation qui nécessitent une logique booléenne. Par exemple, étant donné que la variable ENV a une valeur de chaîne de caractères et qu'elle sera toujours vraie, il ne serait pas très agréable de faire quelque chose comme ça :

if ENV['MY_VARIABLE']
  # do something
else
  # do something else
end

Il y a donc au moins deux façons d'accomplir ce genre de choses :

Initialiser une variable avec une valeur particulière et la vérifier

if ENV['MY_VARIABLE'] == 'some string'
  # do something
elsif ENV['MY_VARIABLE'] == 'some other string'
  # do something else
end

Ou simplement initialiser la variable avec une valeur quelconque et vérifier si elle a été initialisée (le code pourrait être exactement comme nous le souhaitons).

if ENV['MY_VARIABLE']
  # do something
else
  # do something else
end

La question est de savoir quelle est l'option préférée et quels sont les avantages et les inconvénients de chacune d'entre elles.

Answer 1

Variables d'environnement comme leur nom l'indique, sont des variables dépendantes de l'environnement qui stockent des valeurs différentes pour les mêmes clés en fonction de l'environnement (production, staging, développement) dans lequel vous travaillez.

Par exemple, il détient un Clé d'accès pour certaines api qui ont un mode sandbox et un mode production. Ainsi, pour rendre votre code DRY et efficace, vous définissez une variable d'environnement pour obtenir la clé d'accès du mode sandbox pour le développement/staging et la clé live pour la production.

Ce que vous essayez de faire, c'est de les utiliser contrairement à la raison pour laquelle ils ont été définis, et il ne fait aucun doute qu'ils peuvent être utilisés de cette manière. Puisque ce sont des constantes, je vous recommande de faire ce qui suit.

créer un constants.rb dans vos initialisateurs contenant

class Constant
  BOOL_CONSTANT = ENV['MY_VARIABLE'].present?
  # OR
  BOOL_CONSTANT = ENV['MY_VARIABLE'] == 'true'
end

vous pouvez alors l'utiliser partout où vous le souhaitez. De cette façon, vous pouvez réaliser ce que vous voulez, mais sous le capot ;)

Answer 2

Vous devriez probablement remanier votre code et utiliser une classe personnalisée, de manière à ce qu'il soit plus facile à maintenir et à modifier :

class MyEnv
  TRUTHY_VALUES = %w(t true yes y).freeze
  FALSEY_VALUES = %w(f false n no).freeze

  attr_reader :value

  def initialize(name)
    @value = ENV[name].to_s.downcase
  end

  def to_boolean
    return true if TRUTHY_VALUES.includes?(value.to_s)
    return false if FALSEY_VALUES.includes?(value.to_s)
    # You can even raise an exception if there's an invalid value
    raise "Invalid value '#{value}' for boolean casting"
  end
end

# Usage example:
MyEnv.new("MY_VARIABLE").to_boolean

Je pense que, pour les variables d'environnement booléennes, il est plus convivial d'avoir des valeurs comme yes , true , no ... au lieu de variables présentes ou non présentes.

Le seul inconvénient que je vois ici est la performance, car vous passez de la vérification de nil (facile) à une comparaison de chaînes de caractères (un peu plus complexe). Compte tenu de la puissance des ordinateurs de nos jours, si la performance n'est pas un problème pour vous, ce ne sera pas un problème pour vous.

En conclusion, les contrôles de chaînes sont plus conviviaux et plus lents, les contrôles de présence sont plus rapides mais plus obscurs.