Extra Credit Refactor Idea 0:00Okay, I have some extra credit for those of you who want it. If you don't care, if you want to get back into learning about Laravel, skip to the next episode. I promise you will have not missed anything overly important. But if you're interested, let's take a few moments and return to this line from the previous episode. You may have noticed it still feels a little off. Not too bad, but we're still fetching a value from the request, and based upon that value, we are calling two different methods. Now as it turns out, there's one alternative you might consider, and I often reach for Create Dedicated Controller 0:31we are calling two different methods. Now as it turns out, there's one alternative you might consider, and I often reach for this approach. And the recommendation is this, when in doubt, create a new controller. So rather than grabbing this value from the request, what if instead we had a new controller called Completed Tasks? And if we had this controller, and we followed basic RESTful practices, we could have one endpoint to store a new Completed Task, and another endpoint to destroy or delete that Completed Task. Let's just brainstorm.Completed Task. Let's just brainstorm. Let's try it out. We can always revert if we don't like what we get. Alright, so I will make a new controller, and this will be a resource for Completed Tasks. Again, when in doubt, create a new controller, and return to REST. So here, I said we would have two different endpoints. One to store a new Completed Task, so we would accept that, and then another one to destroy or delete a Completed Task, or basically mark it as incomplete.One to store a new Completed Task, so we would accept that, and then another one to destroy or delete a Completed Task, or basically mark it as incomplete. Okay, so that means here, we could simply say Task Complete, and then return back. And this other one would say Task Incomplete, and return back. Notice when we separate this into two methods, it ends up being really, really simple. We're not digging into the request, we're not calculating a method and then calling it dynamically. We're keeping it fairly simple here. Okay, so let's see if we can get this to work. If we have a new controller, I need to go to my route slash web file. Define RESTful Routes 1:57Okay, so let's see if we can get this to work. If we have a new controller, I need to go to my route slash web file. Let's figure out what the endpoint should be. We know if we're going to store a new Completed Task, that will be a POST request to, how about something like Completed Tasks? And then we'll accept the task here. So notice it's its own resource. All right, let's give that a shot. So we'll go to Completed Tasks Controller at Store, and then we'll have another one that submits a DELETE request to that resource, and that will hit a destroy method. Update Form Submissions 2:21So we'll go to Completed Tasks Controller at Store, and then we'll have another one that submits a DELETE request to that resource, and that will hit a destroy method. The next step is, within our resources directory, let's go find the project slash show view. And here's where we filter through and display each task. And you'll notice every task is wrapped within a form. So I need to update this. We'll take it in two steps. First, let's imagine the task is incomplete and we want to mark it as complete. Okay, this would submit a POST request to Completed Tasks slash the task ID. That would then hit this route.Okay, this would submit a POST request to Completed Tasks slash the task ID. That would then hit this route. That would load the Completed Tasks Controller, which would then complete the task and return back. So let's give it a shot. If I switch back, let's complete this one here. And whoops, it looks like we forgot to import the task model. We'll do that here. All right, come back, give it a refresh, and there we go. We've now completed the task using a different approach.All right, come back, give it a refresh, and there we go. We've now completed the task using a different approach. But now I want to mark it as incomplete, but I can't, and that's because we hardcoded this. So why don't we say, if task is completed, then let's spit out a method field of DELETE, like so. Okay, so now if we give it a refresh, we check it, it works. So if we switch back in our Project Tasks Controller, well at the moment, this update method was only responsible for toggling that Boolean. So I could remove that, and then in my routes file, get rid of this, and then we end up with something like this. Remove Old Toggle Logic 3:53So I could remove that, and then in my routes file, get rid of this, and then we end up with something like this. So now you have a dedicated controller for handling and managing the state of a completed task. So depending upon your current skill level, this might be a little bit above what you're comfortable with, but nonetheless, this is meant to show you that you have a lot of flexibility here. So once again, when in doubt, if you find yourself abandoning REST, if you find yourself using a bit of trickery, a lot of checks to determine what methods to call, like we had earlier, that might be a sign to simply create a new controller, and then return to the seven Evaluate Tradeoffs and Wrap-Up 4:22using a bit of trickery, a lot of checks to determine what methods to call, like we had earlier, that might be a sign to simply create a new controller, and then return to the seven RESTful methods, as we've done here. So now, as developers, we have to decide, well given the project, given this context, is this an improvement? In some ways it is. It does complicate the code a little bit. We have to do a couple more things. We need to register another resource. So that does add a little bit of complexity, but it does make the methods incredibly simple.We need to register another resource. So that does add a little bit of complexity, but it does make the methods incredibly simple. There's no more conditionals, and things like that. So again, as a developer, you have to decide, does this represent an improvement, or was it perfectly fine just calling an update method on project tasks controller? I'm going to leave that one up to you. But the main thing I want to instill here is, both approaches have their uses. It's never one or the other. Sometimes you'll reach for the more basic option, and other times you'll realize, well, if I create a brand new controller, this actually simplifies the code, versus what we had before.Sometimes you'll reach for the more basic option, and other times you'll realize, well, if I create a brand new controller, this actually simplifies the code, versus what we had before. It's all a give and take. Alright, so that's your extra credit. In the next episode, let's get back to learning Laravel.
