Custom Types in Case Expressions

[00:00:00]
>> Richard Feldman: So Bool has two variants, Tab has three variants. We could make others that have four plus variants, however many we want. Again Bool is the custom type here and the variants are True and False. Okay, so how can we apply this to our Tab bar here? Well, we can do it like this.

[00:00:20]
Case model.tab of, and now we can say, quite directly, YourFeed ->, GlobalFeed ->, TagFeed ->. Notice by the way that here we did not include the underscore. We didn't have a default branch, why is that? Well the purpose of the default branch is to say, yeah, you have to account for all the possibilities.

[00:00:40]
This is a case expression, it has to evaluate to a value just like an if expression. The thing is, we have accounted for all the possibilities. In this custom type, there are only three possibilities in the entire universe. There's YourFeed, GloablFeed, and TagFeed and that's it. Strings, there's an infinite number of theoretical possible strings.

[00:01:00]
Granted you're gonna run out of memory before [LAUGH] representing some of them. But here there's just these three. So if we enumerate these three, that'll work. No matter what the Elm program is going to be able to execute this and it's always going to be able to take one of these three branches.

[00:01:15]
Because we've defined that that's all there is in this world. Also worth noting that it's not just that this is one way to do it but, actually, if I were to try and add an underscore branch, that would not compile because that would be unreachable code. The compiler would say, hey this branch that you've written here cannot possibly get run because all of these above it already completely specify all the possibilities.

[00:01:40]
So you should delete that code because it's not going to do anything and if you think it is you gotta bug somewhere. Also, we can't repeat any of these. I can't say YourFeed twice in there. It's gonna say, that's already been covered by a previous case. Also, I can't just leave TagFeed off and only specify YourFeed and GlobalFeed.

[00:01:57]
If I do that, it's gonna say, nope. You've not accounted for the possibility of a TagFeed. You need to incorporate that too. So working with custom types is pretty nice and reliable, when it comes to how we can deal with them in terms of case expressions. It's pretty hard to mess this up as long as you don't use the underscore, you just say, YourFeed, GlobalFeed, TagFeed.

[00:02:15]
If I leave one off, if I specify more than I should, if I specify cases that can't be reached, in all those cases, Elm is gonna give me an error at compile time so I can't mess that up. Cool, so having no default case is actually a good thing, it lets the compiler help us out more.

[00:02:31]
Sometimes it's the right tool for the job. Sometimes you wanna have a default case because maybe you have 20 different variants and you only care about one of them, you don't wanna specify 19 if you don't have to. But usually when you have multiple different ones and you actually do wanna do something different, it's best to use it this way and not use a default case.

[00:02:48]
That's different than in JavaScript where usually the best practice is is to always have a default case. In Elm, it's actually better not to, if you can get away with it.