Make your Laravel controller THINNER using FormRequest

Image for post
Image for post

Refactoring is always a tough job to do. It gets even worst if they are not in the proper format and things are not in the right place. When working with my teams I often found codes that are messy and not properly organized. The main reason behind it not to think before you write them up.

When building software most of us take the help of a framework. Nothing wrong with that. A framework helps us to build faster and guide us to put the code where it belongs. But again, it will not restrict you from writing bad code. I am personally a big fan of Laravel. It is more structured and great for faster developments. Today we will focus on organizing a Laravel controller or writing a thinner controller as the title say.

What is a Controller?

When building a web application it’s very common to take input from a user and take action against that and return feedback to the user. So will you store the inputs without sanitizing them? Of course, not, there is a high chance to get injected, right? So what you do? You sanitize them and return error responses in case the input does not meet your criteria. A controller is a place where you can make a decision whether to forward them to the database or tell the user to provide proper data or making decisions whom to forward. Controllers act as an interface between Model and View components to process all the business logic and incoming requests, manipulate data using the Model component, and interact with the Views to render the final output. So how a controller looks like in Laravel?

This is how a typical controller looks like in Laravel. You can generate a fresh new controller by hitting the command below:

It’s a good practice to keep the Controller word at the end of your controller name. But it is optional. You can name it as you like. So as you can see, the controller holds a method named show() which returning a view with the profile for the id passed in the parameter. Pretty simple right? But in our development, the taste is not always as sweet as you expected. You have to deal with a lot of logic and corner cases that the controller gets too messy. And whenever a client comes up with a change you keep adding logics and checks to the controller. End of the day your controller gets big and hard to refactor. After a few months when you come back to look at your own code you end up saying something like “Really? I wrote this code!!”.

Don’t worry, you are not alone. But you can be different. Before we dive deep let’s see an example of a messy controller with having only two(so that we can discuss much keeping the area small) methods on it.

As you can see the controller has only two methods. The first one(showCheckoutForm()) is responsible for showing products that are added to the cart by a user and then simply return the view with the data. No problem with that. It’s a perfect case to write in that way. But look at the second one (handCheckOut()), do all the code belongs to that method?

First of all, the second method is breaking the first rule of the SOLID principle. Single Responsibility. Meaning that a class should be responsible for only one task. If we quote like Uncle Bob the originator of the term “A class should have only one reason to change”. But look at our code. It has a lot of things to do in it. What are they?

  1. Apply/Check validation rules for the inputs
  2. Customize the error messages
  3. Register/Save the user
  4. Calculate the total amount
  5. Check if coupon applied and apply on the total amount
  6. Place the order
  7. Send an email to the user with the invoice
  8. Generate flash message and redirect the user to the home page

Oooo!! Lots of things to do. But we can’t compromise them right? As they are important and need to store for further process. Yes, you’re absolutely right. We don’t need to pick some from them and trough them out thinking it is making the code longer. But what we can do, we can extract some part of it and put it somewhere else. But where to put?

FormRequest is your friend

Yes, in this scenario the FormRequest classes of Laravel is your friend. FormRequest is a special type of class that is created for handling form requests. It has some awesome methods that help you sanitize user data, check authorization, and much more. It acts as the regular Illuminate\Http\Request class but with more power in it. But how to make them or where should I place them? Don’t worry, Laravel will help you out. There is a command for making them and a namespace is generated by default for them.

With the help of the above command, you will see a class that has been created under your App\Http\Requests namespace. Go to the app directory, followed by Http folder. There you will see a new folder has been created named Requests. Under that folder, your FormRequest classes will be generated. So you will find the CheckoutRequest class there. It inherits the FormRequest class so that you can use all the awesome methods of it. By default, the following code is generated for a newly created FormRequest class.

Here, the first method checks whether you have access to this class or not. If not, the rest of the code will be not executed and you will be shown an unauthorized error. This is a good place for checking your user’s accessing criteria and applying rules to check if he is eligible or not. This method returns a boolean value. If you don’t want to check anything you may simply return true. Or you can add your custom logic there(like checking if the user is logged in or not). But don’t return false as it will always trough an unauthorized error.

Another default method that is generated after firing the command is the rules() method. This method returns an array. An array that holds the validation rules for your inputs. Here you can apply rules for your form data. So what can we do now, we can move all our validation rules out from the controller class and put it here in the rules method array.

By putting it there in the rules method, your controller is a bit thinner than the previous. But wait? Where are the awesome methods I mentioned earlier? The class has only two methods. Don’t worry we will get there soon. Your generated CheckoutRequest class extends the core FormRequest class. The FormRequest class holds the methods. So whenever, you need any method from that just override it in your CheckoutRequest class. Let’s start by overriding the messages() method of the base class.

Like rules() method messages() method also returns an array. But this array acts differently. What it does, it allows you to override the default error messages thrown during validation. If you want to write your own custom error message just write the attribute name you used in the form and followed by your custom message. Note that you don’t need to write all error messages, only them whom you want to write in your way. The rest of the error messages will be generated by default. So let’s move our second array from the $request->validate() method and put it in our CheckoutFormRequest class by overriding the messages() of the FormRequest class.

Ok, done with moving. But wait a minute. How can our controller know how/when to apply these rules and messages? We didn’t tell it to do so. Very good point. Moving the code has nothing to do until or unless you call them up. So we need to call/inject the CheckoutRequest class in our controller. Simply replace the default Illuminate\Http\Request by App\Http\Requests\CheckoutRequest class. And Laravel will automatically map the class and get the job done for you. Let’s look at our previously written code with the new changes applied.

As you can see, our method is much cleaner and our controller is thinner than before now. By reaching this line below, your validation rules are applied and custom error messages are thrown with default errors if any validation fails.

So we are done with the first two tasks that we did in our controller. They still exist but in a different place.

  1. A̶p̶p̶l̶y̶/̶C̶h̶e̶c̶k̶ ̶v̶a̶l̶i̶d̶a̶t̶i̶o̶n̶ ̶r̶u̶l̶e̶s̶ ̶f̶o̶r̶ ̶t̶h̶e̶ ̶i̶n̶p̶u̶t̶s̶
  2. C̶u̶s̶t̶o̶m̶i̶z̶e̶ ̶t̶h̶e̶ ̶e̶r̶r̶o̶r̶ ̶m̶e̶s̶s̶a̶g̶e̶s̶
  3. Register/Save the user
  4. Calculate the total amount
  5. Check if coupon applied and apply on the total amount
  6. Place the order
  7. Send an email to the user with the invoice
  8. Generate flash message and redirect the user to the home page

Let’s go for the third task, registering the user. But is the CheckoutController responsible for registering users? Of course not, CheckoutController is responsible for handling checkout kinds of stuff. So we need to move that part of code somewhere else. But where? You can come out with a lot of solutions at this point. But wait, we have recently created a FormRequest class. Can we use that? Of course, you can and this is not a bad idea at all.

Let’s create a method to register/save the user in the CheckoutRequest class. You can use any of the access modifiers(public/protected/private) for the method but I would use protected or private as I don’t want to call this method outside the class or only can be accessed by classes that inherit it. But let’s use the public for now. And previously we accessed the methods of the Illuminate\Http\Request class by an object of it. As we are now in the dedicated FormRequest class we can use them directly by using $this keyword.

Ok, let’s create the registerUser() method.

Ok, but will this part of code will be called automatically like the previous? A big NO my friend. Validation is handled by default and the methods you override from FormRequest class to CheckoutRequest class will be called internally by Laravel, but your custom methods will not be called. You need to call it yourself. So what can we do, we can call this registerUser() method from our controller.

By extracting that code, our controller is again a bit thinner and we are done with the third task(3.R̶e̶g̶i̶s̶t̶e̶r̶/̶S̶a̶v̶e̶ ̶t̶h̶e̶ ̶u̶s̶e̶r̶) of our list. Let’s see how our controller method looks like now.

Now, focus on the next three tasks we have to work with.

4. Calculate the total amount

5. Check if coupon applied and apply on the total amount

6. Place the order

Like before we did for registering users, we can do this kind of stuff in our FormRequest class. You can move the code somewhere else, but again this is not a bad choice at all to put is here in the CheckoutRequest class as it is a part of the checkout process. So make methods to handle them in the CheckoutRequest class.

Again, these all are custom methods. You need to call them manually in your controller. But as you called the registerUser(), getTotalAfterCouponDiscount(), getActualTotalAmount() internally in the placeOrder() method they are already called. No need to call them again. Just call the placeOrder() method in the controller and you can now remove the call of registerUser() method in your controller as you called it internally.

As you can see we have reduced 50(+-) line from our controller method and the controller is now more readable, cleaner, and of course more THINNER. And here how your controller looks now.

And let’ check our task list again.

  1. A̶p̶p̶l̶y̶/̶C̶h̶e̶c̶k̶ ̶v̶a̶l̶i̶d̶a̶t̶i̶o̶n̶ ̶r̶u̶l̶e̶s̶ ̶f̶o̶r̶ ̶t̶h̶e̶ ̶i̶n̶p̶u̶t̶s̶
  2. C̶u̶s̶t̶o̶m̶i̶z̶e̶ ̶t̶h̶e̶ ̶e̶r̶r̶o̶r̶ ̶m̶e̶s̶s̶a̶g̶e̶s̶
  3. R̶e̶g̶i̶s̶t̶e̶r̶/̶S̶a̶v̶e̶ ̶t̶h̶e̶ ̶u̶s̶e̶r̶
  4. C̶a̶l̶c̶u̶l̶a̶t̶e̶ ̶t̶h̶e̶ ̶t̶o̶t̶a̶l̶ ̶a̶m̶o̶u̶n̶t̶
  5. C̶h̶e̶c̶k̶ ̶i̶f̶ ̶c̶o̶u̶p̶o̶n̶ ̶a̶p̶p̶l̶i̶e̶d̶ ̶a̶n̶d̶ ̶a̶p̶p̶l̶y̶ ̶o̶n̶ ̶t̶h̶e̶ ̶t̶o̶t̶a̶l̶ ̶a̶m̶o̶u̶n̶t̶
  6. P̶l̶a̶c̶e̶ ̶t̶h̶e̶ ̶o̶r̶d̶e̶r̶
  7. Send an email to the user with the invoice
  8. Generate flash message and redirect the user to the home page

As you can see out of 8, six tasks are done. Now with the last two, I think there is no harm to keep them where they are and they have some valid point to stay there. Though if you want you can generate the flash message during order placement in the placeOrder() method in the CheckoutRequest class. But I am good with that, no big deal. So now, what your controller’s handleCheckOut() method saying is, place the order, send an invoice to the user and redirect back to the home page with a success message. Pretty straight forward. And all the other parts are moved away from the controller and have given a dedicated class to manage stuff there. So here what your CheckoutRequest class looks like.

So now you learned to make your controller THINNER with the help of FormRequest class. Keep going and hit claps for me if you like it.

Written by

A software engineer from Bangladesh.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store