Bird
Raised Fist0
Laravelframework~3 mins

Why Form request classes in Laravel? - Purpose & Use Cases

Choose your learning style10 modes available
The Big Idea

Discover how to keep your code neat and error-free by moving validation out of controllers!

The Scenario

Imagine building a web form where users submit data, and you manually check each input for errors in your controller code.

You write many lines to validate data, handle mistakes, and keep your controller messy.

The Problem

Manual validation clutters your controller, making it hard to read and maintain.

It's easy to forget checks or repeat code, causing bugs and security risks.

Fixing or updating validation means hunting through scattered code.

The Solution

Form request classes let you move validation logic into a dedicated place.

This keeps controllers clean and validation reusable.

Laravel automatically runs these checks before your controller code, so you only handle valid data.

Before vs After
✗ Before
public function store(Request $request) { if (!$request->has('email') || !filter_var($request->email, FILTER_VALIDATE_EMAIL)) { return back()->withErrors(['email' => 'Invalid email']); } // save data }
✓ After
public function store(UserRequest $request) { // data is already validated here // save data }
What It Enables

You can write cleaner, safer, and more organized code that scales well as your app grows.

Real Life Example

When building a signup form, form request classes ensure emails, passwords, and names meet rules without cluttering your main logic.

Key Takeaways

Manual validation clutters and complicates controllers.

Form request classes centralize and automate validation.

This leads to cleaner, safer, and easier-to-maintain code.

Practice

(1/5)
1. What is the main purpose of a Form Request class in Laravel?
easy
A. To define routes for the application
B. To create database migrations automatically
C. To manage user authentication sessions
D. To organize and handle validation rules separately from controllers

Solution

  1. Step 1: Understand the role of Form Request classes

    Form Request classes are designed to keep validation rules and authorization logic separate from controller code.
  2. Step 2: Identify the main benefit

    This separation helps keep controllers clean and improves code organization and security.
  3. Final Answer:

    To organize and handle validation rules separately from controllers -> Option D
  4. Quick Check:

    Form Request = Validation organization [OK]
Hint: Form Requests separate validation from controllers [OK]
Common Mistakes:
  • Confusing Form Requests with database migrations
  • Thinking Form Requests handle authentication
  • Assuming Form Requests define routes
2. Which of the following is the correct way to create a Form Request class using Artisan CLI?
easy
A. php artisan create:request UserRequest
B. php artisan make:formrequest UserRequest
C. php artisan make:request UserRequest
D. php artisan generate:form UserRequest

Solution

  1. Step 1: Recall the Artisan command for Form Requests

    The correct Artisan command to create a Form Request class is make:request.
  2. Step 2: Match the command with the options

    php artisan make:request UserRequest uses php artisan make:request UserRequest, which is the correct syntax.
  3. Final Answer:

    php artisan make:request UserRequest -> Option C
  4. Quick Check:

    Artisan command for Form Request = make:request [OK]
Hint: Use 'make:request' to create Form Requests [OK]
Common Mistakes:
  • Using 'make:formrequest' instead of 'make:request'
  • Using 'create:request' which is invalid
  • Using 'generate:form' which does not exist
3. Given this Form Request class snippet, what will $request->validated() return if the input is ['name' => 'John', 'age' => 20]?
class UserRequest extends FormRequest {
    public function rules() {
        return [
            'name' => 'required|string',
            'age' => 'required|integer|min:18'
        ];
    }
}
medium
A. {'name' => 'John', 'age' => 20}
B. {'name' => 'John'}
C. ValidationException error
D. Empty array []

Solution

  1. Step 1: Check validation rules against input

    The rules require 'name' as a string and 'age' as an integer >= 18. Input has 'name' = 'John' (string) and 'age' = 20 (integer, >=18), so validation passes.
  2. Step 2: Understand what validated() returns

    The validated() method returns all input fields that passed validation, so it returns the full input array.
  3. Final Answer:

    {'name' => 'John', 'age' => 20} -> Option A
  4. Quick Check:

    Valid input returns full validated data [OK]
Hint: Validated returns all fields passing rules [OK]
Common Mistakes:
  • Assuming partial data is returned
  • Expecting an error when input is valid
  • Confusing validated() with all() method
4. Identify the error in this Form Request class that causes validation to always pass even with invalid input:
class ProductRequest extends FormRequest {
    public function rules() {
        return [
            'price' => 'required|numeric|min:0'
        ];
    }

    public function authorize() {
        return false;
    }
}
medium
A. The authorize method returns false, blocking validation
B. The rules method is missing required fields
C. The min:0 rule is invalid for numeric fields
D. The class name should be ProductFormRequest

Solution

  1. Step 1: Understand the authorize() method role

    The authorize() method controls if the request is allowed. Returning false denies the request before validation.
  2. Step 2: Effect of returning false in authorize()

    When authorize() returns false, Laravel automatically denies the request, so validation rules are not applied and the request fails authorization.
  3. Final Answer:

    The authorize method returns false, blocking validation -> Option A
  4. Quick Check:

    authorize() false blocks request [OK]
Hint: authorize() must return true to run validation [OK]
Common Mistakes:
  • Ignoring authorize() method effect
  • Thinking min:0 is invalid for numeric
  • Believing class name affects validation
5. You want to create a Form Request that validates an optional email field but only if it is present, and it must be a valid email format. Which rule should you use in the rules() method?
hard
A. 'email' => 'nullable|email'
B. 'email' => 'sometimes|email'
C. 'email' => 'required|email'
D. 'email' => 'present|email'

Solution

  1. Step 1: Understand optional validation rules

    To validate a field only if it is present in the input, Laravel uses the sometimes rule.
  2. Step 2: Compare rules for optional email

    nullable allows null values and skips subsequent rules if null; present requires the field to exist even if empty; sometimes applies validation only if the field is sent.
  3. Final Answer:

    'email' => 'sometimes|email' -> Option B
  4. Quick Check:

    Use sometimes for optional fields [OK]
Hint: Use sometimes to validate only if field exists [OK]
Common Mistakes:
  • Using required which forces presence
  • Using nullable which requires field present but can be null
  • Using present which requires field always present
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard