Hello. Friends. Um in this lesson we're going to learn about using case to control the flow of our application. Um As you may know by now, you already know how to control the flow of your application using pattern matching. So what you can do, you can passing different um arguments to different functions and then execute different parts of the code. Let me go back and refer to, for example, this lesson right here, which is less than six. So we can control the flow of our application by calling this function and then altering the argument that this function takes and based on the arguments that you pass to this function, it will execute this one or this one or this one or that one. Um and that's exactly what control flow is all about. Um So you already again have done some parts of it and I intentionally deferred using case. So there's case, there's Kant and there's if and there's with there's four other ways that we could use to control the flow of our application that I will show you. But I intentionally showed you pattern magic first because you know, I will mention that if you're able to use pattern matching, just um prefer that over some of the other ones. Um unless it's it's more readable to use uh some of the techniques that I will show you using case. So huge case. Um We pass it a value or structure of sort and then we pattern match and uh so it's two to control the flow of the application. What do I mean by this? Well, I think the code will make it easy to read. Most languages have have some sort of case statement. Um what I like about the Elixir one is that it kind of is taken to the next level by adding pattern matching to it. So for example, here I could say, well case, you know, I'll just use the variable here, my variable, I'll just put something like one case my bar do and then and so you basically pass the structure or uh the value to your case statement and then you do basically different levels of pattern matching. So you can say if it is to then say It's the number two, you can also say hello, it's the string Hello. And then you can see if it's one, number one, I'm just showing you here because you basically check from top to bottom. So if it is too it's gonna match here, if it is one is gonna match here and so on. And then you could leave kind of a final catch all. So you put basically this underscore which will catch everything, you don't have to have that one. If you don't want any code to execute in this case statement, you can simply ignore this last one. Uh But if you want to catch all or what you might call an else in um other case statements, then you could use this underscore It's neither 1 2 or Hello. Okay, so let me take this code and I'll execute it. And I said you don't dismount surprisingly, it says it's the number one. If I make my variable, something like something that doesn't exist in those conditions here. So it's neither one hello or two, Then it says it's neither 1, 2 or Hello. So you get the point here. So basically we're taking this one and then we're comparing if it's this or this or this or something else. Now, what's interesting here is that we could use pattern matching in all of its funds. Okay, what do I mean by this? Well, we learned how we can pattern match, for example, I'm just going to copy the same one for simplicity. So if I say for example, it's hello world. I can say well If it's hello. And again remember with pattern matching for strings, I could do this, which is which can Captain eight strings. So I can say if it's hello and then it ends with anything, then I can say something like this. String starts with Hello. And then otherwise I can say this string does not start with Hello. Okay, I'll show you here. So this string starts with Hello. If I change it to something else. This string does not start with that. Do you could match on strings? We could match also on all kind of data structures and you will see this extremely common in um in elixir. So you will see this pattern a lot, which is usually in most libraries or a p I s you get a result that looks usually something like this. Okay. And then something like success or sometimes you get something like error and then some kind of an error message like this. So what you can do here, you can do case result do and then you could say well if the result starts with okay, maybe I don't care if you don't care about the particular pattern, which means that it's it's a two pole that has two elements. The first one has to be the okay, it doesn't matter what the second one is, I can say success and then here if it's error and then here let's say we care about the messaging here, we want to know, let's say for example, and I'll say something like invalid and but I can say here something like you get an error and then you can interpret the error here by putting the message in it and then otherwise you can say something like unrecognized result this pattern, you will see very common in elixir because we used to people's a lot to tell us what happened in a particular function, uh you know, after a long operation, did it succeed, did it fail and and so on. So I'll take this, face it in this case it's a success. If I could result. Yeah, you can't just went out let's say it's error invalid input. Um Sorry I have a typo here, you should say okay we've got an error, invalid input and then if I put result of something else like just a string then the case would be thank you. Unrecognized result. Mhm. Okay, by the way, if if you have a longer function you could simply just like, you know, if if you have something you know it's very long here, I'm keeping it in the same line just for because it's simple but you could just as easily I'll put those here even though it's more common if it's short enough to just keep it in the same line but just so you're used to both types of syntax, I will show it to you here that you could just have it indented after each one of these awesome. Um So any kind of pattern matching here will work. We could have maps you could have um um you know, even you can have guard clauses so maybe I'll show you you can also you can also use guards with this case, so remember was guards, we could have certain types of checks when um um um that you may not be able to easily capture in simple pattern matching. So I can something I can say something like um Number equals let's say 15 and then I can say something like case number do this by the way, this may not be the best optimal way to implement it in real life, but just more for illustration. So I can say if it's X when x is greater than 10, I could do something like the number is big X or you know, I want to avoid contributing. I'll say why When Y is greater than five. Okay, the number is medium. Otherwise we could say the number is small. So I'm using guards here with my pattern matching when it comes to elixir case. So as you might expect it here because it's 15, it says the number is big, I've commented out, Let's say I put something like five Does, the number is small because not greater than five is not greater than 10. So basically we could use guards, we could use pattern matching on couple's pattern matching on maps, pattern matching on strings, you name it. And this is why the case statement is is quite powerful and quite interesting one to to use. What's also interesting about the case statement is that you could also use it in a series of pipe operations. You could also use case in a series of operations. Remember by by I mean this wonderful pipe operator in elixir maybe let me see if I could see a good so string reverse here. Um It's trying to find one that might make sense for us to use like um I guess honestly all these don't make particular sense. It mostly mostly makes sense in a situation where um maybe maybe I'll use this contrived example, but hopefully you get the point. So usually what you do is you have death. Mhm. Mind you all my module and some function. It my function. And let's say this function again, we'll just make it very simple. It returns a okay success again, I'm showing this because it's it's a common pattern to do this in elixir. Uh Not that it's a useful example in this particular case, so let's see here, I do something like my module dot I call my function and then all I can do, I could pipe the output, which remember it comes to the same input. But interestingly you could actually have a case in these kids and you could say, well if it's okay then I can say operation is yes, otherwise we can say something like operation failed. Okay, so not just here, if you're passing a case to a pipe and by the way it's it's quite you can have it in the middle, it's usually common to put it at the very end. And um um you can have it in the middle as well. So uh but then if you pipe more stuff here, remember that you're getting a string in this particular case. So it's like, you know, you could do something like up case or something like that. Right? Just remember that with the pipe operator, the first argument of the function, you're calling in the pipe operator is the output from the previous operations. So let me just test this for you right here, make sure we haven't made a typo anywhere. So it seems like I did make it all. I I don't think I made a typo it's just because I exit doesn't like it with like I'll just have to make it in the same line like this. So it says operation is a success if I redefine this function, but then I make it return an error, let's say, based in the module code. Again, remember we get the warning, it's been redefined and then I call in this here, it says operation failed and this is again a very common pattern and it's really, it makes it makes reading the code easier if, you know, um call on a bunch of operations and at the end checks the output and do something depending on the output of the operations. Um You may be wondering, well, a lot of it I showed you so far is doable with pattern magic. So you could just simply define functions that take these different heads here. The different parameters like this one, you could use guards, you could use even this kind of matching pattern matching. So why would you use case? Well, I would say in most cases it's it comes down to readability. It's it's another option that you have and um you know, I would say probably it's more a matter of style and and you know um quoting style and readability than than anything else. Generally speaking, I would favor using pattern matching whenever possible. That said sometimes pattern matching is not as easy to read as a simple case statement. So in that case is I would prefer something like a statement. Also one thing to note if if what you're doing in the case statement is like say multi line of things, I would certainly favor functions in that case and pattern matching. If it's a simple output like this one then I would say I would favor something like a case, it makes it easier to read. So I would you know um I would leave it up to you here, I think you'll get a good sense once you work with a particular code base about the style and the usability of it. Um That said my general kind of um general generic advice I should say is always favor um pattern matching with functions when you can um and then revert to case statements. Um Otherwise uh that's what I wanted to cover for today, thank you for tuning in and I'll see you in the next lesson