Orme. Confortable et maladroit. Http, Task

Nous continuons de parler de l' orme 0,18 .

Orme. Confortable et maladroit
Orme. Confortable et maladroit. La composition
Orme. Confortable et maladroit. Json.Encoder et Json.Decoder

Dans cet article, nous examinons les problèmes d'interaction avec le côté serveur.

Exécution de requête

Des exemples de requêtes simples peuvent être trouvés dans la description du package Http .

Le type de demande est Http.Request a .
Le type de résultat de la requête est Result Http.Error a.
Les deux types sont paramétrés par le type d'utilisateur, dont le décodeur doit être spécifié lors de la génération de la requête.

Vous pouvez exécuter la demande à l'aide des fonctions:

1. Http.send;
2. Http.toTask.

Http.send vous permet d'exécuter la demande et à la fin, transmet le message à la fonction de mise à jour spécifiée dans le premier argument. Le message contient des données sur le résultat de la demande.

Http.toTask vous permet de créer une tâche à partir d'une demande que vous pouvez exécuter. À mon avis, l'utilisation de la fonction Http.toTask est la plus pratique, car les instances de tâche peuvent être combinées à l' aide de diverses fonctions , par exemple Task.map2 .

Regardons un exemple. Par exemple, pour enregistrer les données utilisateur, deux requêtes dépendantes consécutives doivent être exécutées. Que ce soit en créant un message de l'utilisateur et en lui enregistrant des photos (certains CDN sont utilisés).

Tout d'abord, considérez l'implémentation du cas Http.Send. Pour cela, nous avons besoin de deux fonctions:

save : UserData -> Request Http.Error UserData save userData = Http.post “/some/url” (Http.jsonBody (encodeUserData userData)) decodeUserData saveImages : Int -> Images -> Request Http.Error CDNData saveImages id images = Http.post (“/some/cdn/for/” ++ (toString id)) (imagesBody images) decodedCDNData 

Les types UserData et CDNData ne seront pas décrits; par exemple, ils ne sont pas importants. La fonction encodeUserData est un encodeur. saveImages accepte un identifiant de données utilisateur, qui est utilisé pour former l'adresse, et une liste de photos. La fonction imagesBody forme un corps de requête de type multipart / form-data . Les fonctions decodeUserData et decodedCDNData décodent la réponse du serveur pour les données utilisateur et le résultat de la demande au CDN, respectivement.

Ensuite, nous avons besoin de deux messages, les résultats de la requête:

 type Msg = DataSaved (Result Http.Error UserData) | ImagesSaved (Result Http.Error CDNData) 

Supposons que, quelque part dans l'implémentation de la fonction de mise à jour, il existe une section de code qui stocke les données. Par exemple, cela pourrait ressembler à ceci:

 update : Msg -> Model -> (Model, Cmd Msg) update msg model case Msg of ClickedSomething -> (model, Http.send DataSaved (save model.userData)) 

Dans ce cas, une requête est créée et marquée avec un message DataSaved. De plus, ce message est reçu:

 update : Msg -> Model -> (Model, Cmd Msg) update msg model case Msg of DataSaved (Ok userData) -> ( {model | userData = userData}, Http.send ImagesSaved (saveImages userData.id model.images)) DataSaved (Err reason) -> (model, Cmd.None) 

En cas de sauvegarde réussie, nous mettons à jour les données du modèle et appelons la demande de sauvegarde des photos où nous transférons l'identifiant de données utilisateur reçu. Le traitement du message ImagesSaved sera similaire à DataSaved, il sera nécessaire de gérer les cas réussis et ayant échoué.

Considérez maintenant l'option d'utiliser la fonction Http.toTask. En utilisant les fonctions décrites, nous définissons une nouvelle fonction:

 saveAll : UserData -> Images -> Task Http.Error (UserData, CDNData) saveAll : userData images = save model.userData |> Http.toTask |> Task.andThen (\newUserData -> saveImages usersData.id images |> Http.toTask |> Task.map (\newImages -> (userData, newImages) } ) 

Maintenant, en utilisant la possibilité de combiner des tâches, nous pouvons obtenir toutes les données dans un seul message:

 type Msg = Saved (Result Http.Error (UserData, CDNData)) update : Msg -> Model -> (Model, Cmd Msg) update msg model case Msg of ClickedSomething -> (model, Task.attempt Saved (saveAll model.userData model.images)) DataSaved (Ok (userData, images)) -> ( {model | userData = userData, images = images}, Cmd.none) DataSaved (Err reason) -> (model, Cmd.None) 

Pour exécuter les requêtes, nous utilisons la fonction Task.attempt , qui vous permet de terminer la tâche. À ne pas confondre avec la fonction Task.perform . Task.perform - vous permet d'effectuer des tâches qui ne peuvent pas échouer . Task.attempt - Effectue des tâches qui peuvent échouer .

Cette approche est plus compacte en termes de nombre de messages, de complexité de la fonction de mise à jour et permet de garder la logique plus locale.

Dans mes projets, applications et composants, je crée souvent le module Commands.elm, dans lequel je décris les fonctions d'interaction avec la partie serveur avec le type ... -> Task Http.Error a.

Demander le statut d'exécution

Dans le processus d'exécution des requêtes, l'interface doit souvent être bloquée en tout ou en partie, et également signaler les erreurs d'exécution des requêtes, le cas échéant. En général, l'état d'une demande peut être décrit comme:

1. la demande n'est pas terminée;
2. la demande est en cours;
3. La demande a été acceptée;
4. la demande a échoué.

Pour une telle description, il existe un package RemoteData . Au début, je l'ai utilisé activement, mais au fil du temps, la présence d'un type supplémentaire de WebData est devenue redondante, et travailler avec elle était fastidieux. Au lieu de ce package, les règles suivantes sont apparues:

1. déclarer toutes les données du serveur comme Peut-être. Dans ce cas, Nothing, indique l'absence de données;
2. déclarer un attribut de chargement de type Int dans le modèle d'application ou de composant. Le paramètre stocke le nombre de requêtes exécutées. Le seul inconvénient de cette approche est la nécessité d'incrémenter et de décrémenter l'attribut au début de la demande et à la fin, respectivement;
3. déclarer un attribut d'erreur de type List String dans le modèle d'application ou de composant. Cet attribut est utilisé pour stocker des données d'erreur.

Le schéma décrit n'est pas beaucoup mieux que l'option avec le package RemoteData, comme le montre la pratique. Si quelqu'un a d'autres options, partagez les commentaires.

Le statut d'exécution de la demande doit inclure la progression du téléchargement à partir du package Http.Progress .

Séquence de tâches

Considérez les options pour les séquences de tâches qui se trouvent souvent dans le développement:

1. tâches dépendantes séquentielles;
2. tâches indépendantes cohérentes;
3. tâches indépendantes parallèles.

Les tâches dépendantes successives ont déjà été examinées ci-dessus; je vais donner une description générale et des approches de mise en œuvre dans cette section.

La séquence de tâches est interrompue lors du premier échec et une erreur est renvoyée. En cas de succès, une combinaison de résultats est renvoyée:

 someTaskA |> Task.andThen (\resultA -> someTaskB |> Task.map (\resultB -> (resultA, resultB) ) ) 

Ce code crée une tâche de type Erreur de tâche (a, b), qui peut être effectuée ultérieurement.

La fonction Task.andThen vous permet de transférer une nouvelle tâche pour exécution si la précédente est terminée avec succès. La fonction Task.map vous permet de convertir les résultats d'exécution du melon en cas de succès.

Il existe des options lorsque la réussite de la tâche ne sera pas suffisante et que vous devez vérifier la cohérence des données. Supposons que les ID utilisateur correspondent:

 someTaskA |> Task.andThen (\resultA -> someTaskB |> Task.andThen (\resultB -> case resultA.userId == resultB.userId of True -> Task.succeed (resultA, resultB) False -> Task.fail “User is not the same” ) ) 

Il convient de noter qu'au lieu de la fonction Task.map, la fonction Task.andThen est utilisée et le succès de la deuxième tâche est déterminé indépendamment à l'aide des fonctions Task.succeed et Task.fail .

Si l'une des tâches peut échouer et que cela est acceptable, vous devez utiliser la fonction Task.onError pour indiquer la valeur en cas d'erreur:

 someTaskA |> Task.onError (\msg -> Task,succeed defaultValue) |> Task.andThen (\resultA -> someTaskB |> Task.map (\resultB -> (resultA, resultB) ) ) 

L'appel à la fonction Task.onError doit être déclaré immédiatement après la déclaration de la tâche.

Des requêtes indépendantes successives peuvent être effectuées à l'aide des fonctions Task.mapN. Ce qui vous permet de combiner plusieurs résultats de tâche en un seul. La première tâche interrompue interrompt l'exécution de la chaîne entière, utilisez donc la fonction Task.onError pour les valeurs par défaut. Consultez également la fonction Task.sequence , elle vous permet d'effectuer une série de tâches similaires.

Les tâches parallèles dans l'implémentation actuelle du langage ne sont pas décrites. Leur implémentation est possible au niveau de l'application ou du composant grâce au traitement des événements dans la fonction de mise à jour. Toute logique reste sur les épaules du développeur.