Quand utiliser l'alias de type par rapport type union-valeur unique dans Elm

Question

J'ai lu sur Richard Feldman's Elm SPA app example, et je vois un certain nombre de examples des choses comme ceci:

type Username 
    = Username String 

et je suis ne sais pas quand il est logique d'utiliser quelque chose comme ça, un type d'union à valeur unique, par rapport à seulement un alias de type comme ceci:

type alias Username 
    = String 

quand est-il approprié d'utiliser un type d'union à valeur unique par rapport à seulement en utilisant un alias de type?

Answer 1

Il n'y a pas de règle absolue pour quand c'est approprié, mais j'ai tendance à suivre quelques règles empiriques. Utilisons un exemple de fonction d'authentification qui prend un nom d'utilisateur et un mot de passe, les deux étant des valeurs de chaîne.

Au strict minimum, sans aucun alias supplémentaire ou types, l'annotation pourrait être ceci:

authenticate : String -> String -> Bool 

Étant donné que l'annotation, on ne sait pas quel paramètre est le nom d'utilisateur et le mot de passe qui est . Nous pouvons améliorer la lisibilité en utilisant des alias de type:

type alias Username = String 
type alias Password = String 

authenticate : Username -> Password -> Bool 

Cela vaut mieux pour les consommateurs de mon package mais de type alias vous ne rejettera pas d'échange accidentellement les paramètres en appelant le code. Par exemple, cette fonction problématique compilerait:

login : Username -> Password -> Bool 
login username password = 
    if authenticate password username then ... 

Si vous voulez aller plus loin et forcer la déclaration explicite du type chaque fois que vous utilisez, vous pouvez éviter ce type d'erreur, car le compilateur attraper mixups:

type Username = Username String 
type Password = Password String 

Avec cette définition, vous devez maintenant déballer explicitement et emballer les chaînes dans soit un constructeur Nom d'utilisateur ou mot de passe chaque fois que vous l'utilisez. Comme vous pouvez le voir dans l'exemple de Richard, suivre la route d'un constructeur de type et de type complet signifie que vous aurez besoin de fonctions standard séparées pour le décodage de JSON. Ceci est particulièrement utile pour les unités de mesure. , encodage, etc, ce qui peut devenir fastidieux. Vous devrez trouver le bon équilibre pour votre équipe et vos projets.