At the surface level, Laravel feels like magic. But if you're curious enough, you will start to wonder why things work the way they do.
Dig a little deeper and you'll find that there is a lot going on that makes that magical feeling so... magical.
One thing that really grated on me was this little use statement I'm supposed to add to my controllers.
use Illuminate\Http\Request;
Worse still in PHP Storm it was often greyed out implying I didn't need it at all. 🫤
In concept I know what a use statement does, allows me to access the contents of another class. naturally I've been writing use statements too.
use App\Models\Category;
And it occurred to me that something like the above is accessible to me, it can see it and I can interact with it. It's right there in my App\Models directory.
But Illuminate is not even a directory so how can I find this 'magical' functionality and figure out why I need it?
Finding the answer led me to understand more about the Laravel framework architecture and what I can do with it.
The role of the vendor directory
I always knew the Vendor directory existed, mainly because one of my first mentor sessions saw me installing packages with Composer. I believe it was Laravel Flash as a demo.
And that was where I thought the role of the Vendor directory ended. Installing External Packages.
I didn't question it at the time, but upon installing Laravel, there is a ton of external packages brought in.
In fact, Composer itself is included.
What I didn't know is that the basis of the Laravel Framework itself is stored here too and that Laravel is smart enough to know when referencing from it's own functionality. Read that as another layer of magic. That functionality is wrapped up inside a Laravel directory within the Vendor Directory.
And there it is Illuminate\HTTP\Request
Is that a Potter reference? That has to be a Potter reference.
Putting request to good use
Assumption, this Request class must be pretty important to be so prevalent.
As it turns out my assumption is correct.
Validation is one such example. A clean way of validating is by creating a new request class in the App\Http\Requests Directory.
Here I am utilising FormRequest which itself uses a request when you dig a little deeper.
<?php
namespace App\Http\Requests;
use Illuminate\Foundation\Http\FormRequest;
class CategoryRequest extends FormRequest
{
/**
* Determine if the user is authorized to make this request.
*/
public function authorize(): bool
{
return true;
}
/**
* Get the validation rules that apply to the request.
*
* @return array<string, \Illuminate\Contracts\Validation\ValidationRule|array<mixed>|string>
*/
public function rules(): array
{
return [
'title' => [
'string',
'required',
'unique:categories,title'
]
];
}
}
It turns out this particular use statement was only greyed out as I had not got to validation yet - or any of the other possibilities for usage.
Validation is a very interesting topic in itself and learning how to format unique parameters required usage of a cool new Laravel artisan command.
a docs unique
Which took me and my mentor straight to the Laravel docs, not the exact page we needed but close enough.
Once used here is the method where request was put to use direct as well as the initial method we used to demonstrate additional functionality. (commented out).
It is in fact the commented-out section that made direct use of the Request use statement.
public function store(CategoryRequest $request)
{
$data = $request->validated();
Category::create($data);
return redirect(route('categories.index'));
}
// public function store(Request $request)
// {
// $request->validate([
// 'title' => 'string|required'
// 'title' => [
// 'string',
// 'required'
// ]
// ]);
// }
In PHPStorm it is also possible to find the path of any future mysterious use statements directly by inspecting (hovering over). Then with the shortcut Cmd + B I can jumpto the file directly.
That's it for now, but there is much more Laravel magic to share.