This Lesson is for Members

Subscribe today and get access to all lessons! Plus direct HD download for offline use, enhances transcripts, member comment forums, and iTunes "podcast" RSS feed. Level up your skills now!

Unlock This Lesson

Already subscribed? Sign In

Autoplay

    Use Elm's Unit Type to Disregard the Body of an HTTP Response

    Enrico BuonannoEnrico Buonanno

    We improve on the previous code by acknowledging the fact that we're disregarding the payload of the HTTP response. This sounds easy, but is actually a bit of a pain point, given the design of the current APIs for Http and Json.Decode

    Code

    Code

    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson
    Transcript

    Transcript

    Instructor: 00:00 If I go back to the elm code, there is only one thing that I don't really like about this code which is that, if you look at our messages in submit response we're saying, in case of an error, we get an HTTP error, and in case of success, we get a string.

    00:15 In reality, we don't really expect to receive any string data. We're assuming that, if we get the status code of 200, then that indicates success and we don't need any additional data. The type here, rather than string should really be unit, which is an empty tool port, essentially a structure that contains no data tool.

    00:33 If I save this, I have a type mismatch. It's because here, I'm using json.string to decode the response. Instead, what I want is to provide a decoder that will essentially ignore the response completely. This is not as trivial as it sounds, but essentially what we can do is to declare a decoder that is based on json.string. We can use json.map to create a decoder that will do something to this string.

    01:04 What do we want to do with the string? Well, whenever we get the string, we essentially want to ignore it and always return unit, and just for readability, when you have such a function that ignores a input, you can just type always.

    01:18 This decoder is now a decoder that will take a string and will always return unit, and the type this request will not be a request typed on unit. Now this type-checks, I can also get rid of this type declaration here. I think we now gain some clarity in that.

    01:36 Although we have to write a bit more code, the payload of our message type more accurately represents the data that has been returned from server. Just to ensure that everything works as expected, let me go down to our handle to response.

    01:52 Here, I'll see our result. I would like to print this result out to the console. I can use Debug.Log, saying that it will print is the result and pass in the result. You need to assign this to a variable. Let me say, let underscore equals the result of this expression in my return value, and list us this out.

    02:27 Now we have a little bit surprising situation, because we get a response with the status code of 200, but the result is an error. If we look at the details of the error, we see that it has to do with parsing the JSON in response.

    02:41 That's because, if we look at the response we see that we get the string "OK." That's not the valid JSON value, because strings in JSON need to be enclosed in double quotes. To handle this problem purely in elm, we would probably use a custom request.

    02:56 Instead of the post function which expects a decoder that receives some JSON, we could use the request function and specify that we expect a string response, rather than a JSON response. However, this is submit for both. For the sake of this demo, I will just change to server to return some JSON.

    03:15 Here is my server, and instead of send status, I'm just going to return JSON and the string "OK". Let me restart my server. Let me try resubmitting my form. You can see that now the request were successful, and also that the result is "OK" of unit.

    03:35 On the other hand, if I stop the server and just submitting the form now, then we get an error and the result is an error with network error as the specific error that occurred. Finally, I can go back and clean up my code, removing the code to Debug.Log

    Discuss

    Discuss