Check out a free preview of the full Introduction to Elm, v2 course

The "Result" Lesson is part of the full, Introduction to Elm, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Result has failure case includes a value that provides more detail on what went wrong. Richard points out how JavaScript and TypeScript fail in this regard. - couldn't find the cut :-/


Transcript from the "Result" Lesson

>> Richard Feldman: So whereas maybe had this shape, it was just val was one of the variants, and then nothing was the other one. Result looks like this, it's got an okay value and an error value, so it actually has two type variables, two different ones. And Ok holds onto an Ok value and an error holds onto an error value.

So, we can also have some more complex JSON here, such as this JSON string which has user_id which is a number, first_name and last_name which are both strings. And we might wanna say, yeah, I actually want to decode this thing. Now this is significantly more complex than just an integer, but there's actually the same API.

We can use the same decode string on this. We're just going to pass it different Decoders, that will specify how to decode this more complex structure. So in JavaScript, the way that we would do this, is we would essentially say, hey give me that thing, I'm just gonna turn it from JSON into a JavaScript object.

I'm gonna assume that that worked, and then I'm just gonna say Just assume that it worked, and then I can access this like id field from there. What's gonna give me back undefined because there is no id field here. There's user_id but there's no actual id field.

So, we're gonna receive that this is a source of potential problem. Because, as we all know, if you've got undefined, that can also snake it's way through your programs and eventually cause one time exceptions, even worse stuff than not a number. So in type script, by the way, this is also basically the same thing.

They don't really do anything differently in this regard. They will assume if you decodes some Json, that It's just got the shape that you say it is, and that may cause problems, that may cause run time exceptions. But, it's up to you to sort of get it right and not to make mistakes like this, when dealing with data that may or may not actually have the shape that you think it does.

Also, you can add an int annotation in type script saying, I promise that ID is an int, which can also just be wrong. [LAUGH] Type script will accept that and say, from now on I'm going to assume as I'm type checking your program, that id is an int, well in in fact it turns out it's not.

So, sometimes people say that typescript's type system is unsound which is like an academic term. That's what they mean by this. They means that basically, like you can say things that are wrong, that will have impact throughout you're code base no matter how big it is. Okay, but in ELM we don't want to do this, we're going to do something else to avoid these problems.

To make it so that, as you're decoding this JSON. We're going to either have,OK, which case it succeeded and we definitely know what it's shape is, and it's definitely going to work the way we expect it to. Or we're gonna have an error, in which case decoding did not succeed.

It was not in the shape that we expected, and we have to handle that some other way.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now