Decoding Review & Q&A

[00:00:00]
>> Richard Feldman: Yeah.
>> Speaker 2: Kind of a general question as far as succeed and user. So because user is a record, if I guess just in general in Elm or Apple if I say user is that a function?
>> Richard Feldman: Yes that would be a function from Int to String to String to user.

[00:00:16]
>> Speaker 2: So the ordering of how you defined each item in the record is important and that's what's used for each item in the pipeline.
>> Richard Feldman: Exactly right yeah. So the order in which you defined these corresponds to the argument order of in the function. Yeah?
>> Speaker 3: So how do you stumble upon like this is gonna be a nullable string.

[00:00:39]
You just have to know your data really well?
>> Richard Feldman: Yeah, for sure. So the question was, how do you know that something is or is not going to be nullable? There's two possible approaches there. One is to know your data really well. So to have a schema from the backend and be like, okay, I know this one can be null or it can not be null, for sure.

[00:00:58]
Another possibility is to be pessimistic and to say you know what? I don't really know if the person who implemented this is gonna be good about null or not, so I'm just going to handle that. I'm gonna make all of these nullable. And then I'm going to decode them into, usually if you're doing something like that, you're gonna make an intermediate data structure.

[00:01:17]
So I might call it like JSON user, or something like that, where everything's maybe. And then, as a followup step, after decoding into that intermediate representation, I'd say, okay. I'm gonna go through and resolve all these maybes and be like, okay, if this one's none, how do I wanna handle that or nothing?

[00:01:33]
How do I wanna handle that if this one is? How do I wanna handle that? Some cases you may not be able to handle it and so maybe you have to fail decoding in that case. But, the point is it's also possible to just be pessimistic and assume that it always potentially could be null and figure out some reasonable default or error to show.

[00:01:54]
Great questions. Fun fact, we actually took the former approach where we were very strict about this. And if decoding would ever fail when we got data back from the server, we would log it as an error. And we actually ended up discovering bugs in our Ruby code, where we thought that we were not possibly sending null but accidentally we were sometimes.

[00:02:12]
And because the decoder would fail then we would get an error message about it oops, go fix that
>> Richard Feldman: It's the only time I've heard of frontend discovering bugs in the backend.
>> Speaker 3: [LAUGH]
>> Richard Feldman: Okay, so to recap we talked about decoding as a general concept. So decodeString int 5.

[00:02:31]
That will result in either giving us back Ok, in which case we have the number five, or error in which case it'll explain why the string that we gave didn't work out. Those are examples of the two variants in result. So result has two type variables. One is the error type and the other is the Ok type and two variants each of which uses each of those.

[00:02:55]
We talked about pipeline decoding, which is using the pipeline that we learned from the previous section, in the context of specifying sort of the schema for how we expect our JSON to look. And how we're going to translate that schema, translate that JSON into our particular Elm type, assuming everything actually lines up, and it works out in practice.

[00:03:16]
And finally, we talked about optional and nullable, which are ways to deal with the possibility that we either got null when we weren't expecting it. Or we got a missing field that we thought was there but which we want to be resilient to. We want for it to be okay for that field to be missing.