2017-10-20 10 views
0

J'essaie d'utiliser graphql avec Elm 0.18. Les bibliothèques que j'ai trouvées en ligne ne semblent pas fonctionner avec 0.18, donc je roule la mienne.Gestion des erreurs graphql dans Elm (0.18)

Disons que j'ai une requête imbriquée. La fonction qui fait l'appel de requête et http ressemble à quelque chose comme ceci:

import Http 
import HttpBuilder exposing (..) 
import Json.Decode as Decode exposing (..) 
import Json.Encode as Encode exposing (..) 
import Json.Decode.Pipeline as Pipeline exposing (decode, required) 

fetchPosts : Model -> Cmd Msg 
fetchPosts model = 
    let 
    graphiql = 
     """ 
     query { 
      postById(id: 1) { 
      id 
      author { 
       id 
       name 
      } 
      content 
      comments { 
       date 
       author { 
       id 
       name 
       } 
       content 
      } 
      } 
     } 
     """ 

    localUserDecoder = 
     Pipeline.decode User 
     |> Pipeline.required "id" Decode.int 
     |> Pipeline.required "name" Decode.string 

    localCommentDecoder = 
     Pipeline.decode Comment 
     |> Pipeline.required "date" Decode.string 
     |> Pipeline.required "author" localUserDecoder 
     |> Pipeline.required "string" Decode.string 

    localPostDecoder = 
     Pipeline.decode Post 
     |> Pipeline.required "id" Decode.int 
     |> Pipeline.required "author" localUserDecoder 
     |> Pipeline.required "content" Decode.string 
     |> Pipeline.required "comments" (Decode.list localCommentDecoder) 

    localDecoder = 
     Decode.at [ "data", "postById" ] <| 
      localPostDecoder 
    in 
     HttpBuilder.post ("http://myserver/api") 
      |> HttpBuilder.withStringBody "text/plain" graphiql 
      |> HttpBuilder.withExpect (Http.expectJson localDecoder) 
      |> HttpBuilder.send GetPostCompleted 

Quand il traverse et passe le long du retour de type Post à GetPostCompleted, tout va bien. Mais supposons que quelque chose soit éteint. Quelque part, ou author comme user, ou les champs sont hors service dans le décodeur. Le compilateur ne me dira pas où j'ai fait l'erreur, à la place je verrai juste une requête correcte dans la table de réseau, mais une erreur de non-descript lancée de mon code d'orme.

Y a-t-il un moyen de structurer cela de telle sorte que, s'il y a un problème avec l'un des décodeurs, je puisse voir une erreur lancée sur la console ou quelque chose comme ça? Actuellement, je dois tout déballer et tout assembler pièce par pièce, ce qui est très difficile et non-orme.

Répondre

2

Je ne suis pas sûr que vous ayez raison à propos des bibliothèques graphql ne supportant pas 0.18.

La plus grande question est pourquoi il n'est pas possible de passer d'une structure de données dactylographiée elm à une requête graphql (effectivement) typée, et aux décodeurs correspondants. Mais cela nécessite bien sûr une analyse des types, ce qui semble être au-dessus de ce que le compilateur veut faire. (Voir https://www.youtube.com/watch?v=sh4H8yzXnvw pour savoir comment cela peut être fait dans Haskell en utilisant Generics)

Par conséquent, même les bibliothèques existantes nécessitent plus de plaques de chaudière que vous ne le souhaiteriez. Je ne vois pas un moyen de contourner cela.

Vous pouvez générer la requête plus directement si vous pouvez itérer des champs d'un type d'enregistrement Elm, mais même avec cela vous ne pourriez pas obtenir des décodeurs générés automatiquement ... Je pense.

Ce que je ne suis pas sûr est de savoir si vous pouvez analyser les définitions graphql de JSON et d'en tirer des décodeurs ormes de cette

+0

Je suis encore nouveau à Elm, mais j'ai entendu des plaintes au sujet du système de type. Est-ce la principale chose que les gens se plaignent? –

+1

Non, les plaintes - telles qu'elles sont - concernent des classes de type, et se résument à des plaques chauffantes supplémentaires. Il faudrait un système de type beaucoup plus avancé ici, je pense (pensez Haskell ou au-delà) –