Laravel Form Request: Store/Update - Same or Separate Class?

sometimes|required_without:id

I know that maybe my question is not related to the video, but I would like to ask you a question.
If I have a settings table for my site, and in this table I have added the maximum characters to username field for example.
can i use the settings model in my form request validation like this..
public function rules(): array
{
$maxUserName = Setting::where('key', 'max_username')->value('value');

return [
'name' => [
'required',
'string',
'max:' . $maxUserName,
'unique:users,name'
],
}
does it allowed or it is safe to use this way ?

I need help. The Update Form Rquest Class, since it's the PUT-magic and model bound, how do I call the instance of that model inside the Update Request Class? Help.

Could always use a Service to call the same service under the store & update functions

Great, exactly what I searched!

Can I set a flash session message in FormRequest?

UpdateRequest extends StoreRequest

Diferent, most of the times they are diferent, sometimes they start the same and end diferent, so I just make two

currently I am facing an issue.
while updating a record in api, I need to skip unique check from current row..
for example
1- name:Dary
2- name:Junaid

if I update 2 with Junaid again it should be okay, but when I try to update Junaid on 1 it show throw duplicate name error.. how should I write my custom for request for that?

What is two type of request in laravel?

I use to prepare merging validation, but now that I am looking to generate documentation automatically, its best to keep separate

Hi Man, I can try image file upload with ajax to Laravel Controller, and with controller another project I wanna post that file for save to api but i can't do that, How can I write?

While working with ajax how can i use form request ? I noticed $request->validated() doesn't work with ajax.

Hi. I really like your videos. You discuss topics that are actually practical and useful! I am currently trying to find out how to access the validation errors. The docs say that they are flashed to the session, but I don't know how to access them.

Is it possible to pass an id manually in the requests class when we use that requests class in the middle part of the controller?

I prefer to use one request for store and update (It is easy if controllers are 10 or 20, but if they are 200?). In most cases. But, insteat of checking request()->routeIs(...) I'm using $this->route('user') !== null (if is used Route model binding). This prevent for errors if we change the route for some reason (even the route is changed, url must contain {user}). And I have custom stub for those kind of request, where just throw model in artisan command. And I think $this->route('admin') is little better than $this->admin :)

A) I don't think you understand what Single Responsibility means. It does not mean one method per class, lol. If that is the definition, then your controller is violating it too ;)
B) Removing the password field/property from the request defeats the whole point of using the 'sometimes' rule. Just don't use it, lol. If it's not 'required' (or 'sometimes') it can be present in the request, or not, or it can be present and set to null. This seems to be the functionality you're looking for on update. No extra/different rule necessary...unless I'm missing something.
C) You look like Sergio Perez's father! Awesome! He's my favorite Formula 1 driver.
D) Thanks for all the great videos!

I use first approach, but if I have the same rules or similar I extend FormRequest one from another or from base one

I like the first example, but have one question
What about the next apis? How to create one request class for them:
POST /api/reservation/
{
reservation_id: string,
request params ....
}
and
PUT /api/reservation/[reservation_id]
{
request params ....
}

What if there's is no model route binding, how can you do the update with unique rule?

hi
could you please tell me what's the difference between thus files and the below code in the controller :
$validatedData = $request->validate([
'am_txt1' => 'required',
'am_txt2' => 'required',
'am_txt3' => 'required',
'am_txt4' => 'required',
'am_txt5' => 'required',
]);
best regards

Different Store & Update with different requests

What about using Auth::id() for getting the logged user id inside form request ? I use it and it works

Never call $this->admin->id, instead of that use $this->route('admin')->id, imagine you have input with the name "admin" then you have a problem.

Separate validators for store and update. Then you can easily apply different permission checks; such as can create, but not update.

You could argue that you can use an if-statement here, but then you introduce more cognitive complexity, as developers have to understand the if-statement — for lesser experienced/junior developers this could be more tedious.

It's just more straightforward IMO to separate them, plus for the cases you mentioned about having different fields

If there is less conditions in the form requests class, this will be a best choice, otherwise two different class much more beneficial.

Woow, i didn't know that we can access the controller's variables inside the form request, this piece of information is very useful, thank you💙

I mostly put all requests into the same class say UserRequest and have the logic base of the request method with a switch case which cases are request methods. this->method() would return the request type if you follow good standards like a post to create, put to update, etc. Delete and Update always return an empty array are grouped. Put and patch are also grouped as they perform almost the same thing.

Code below:

$rules = [];

switch($this->method()) {
case ‘GET’:
case ‘DELETE’: {
return $rules;
}
case ‘POST’: {
// rules here
}
case ‘PUT’:
case ‘PATCH’: {
// rules here
}

return $rules;
}

I personally like to use switch case on the basis of method for each different action.

how do u reconcile the whole KISS with what may happen in future? theres a mantra that says dont worry about future? so if create/update are same now they shud be one Request, if there is a difference in 'future' (which may or may not happen) u can deal with it later

what theme do you use and font for phpstorm ? Thank you.

I prefer to separate them which gives our maximum flexibility, you never know what weird requirements your client wants in the future 😂

I prefer to use the last method, I mean , the same request for the two methods I think it's more simple! But every option is valid

any reason why you used request() instead of $this ? you're inside a Request class after all.

Not sure if it's mentioned, but I think that with the classes that share the same implementation, it seems reasonable to use separate classes, but have them both subclass from a common parent class so as to cut down on the duplication.

Checking for the route name / method in the request classes seems like an anti-pattern to me. It entagles the request object, with the particular route or method that it may be used in - when I think it's better to keep those concerns separated.

Instead of $this->admin->id, I use auth()->id()

First.

Chief thank you for the dark theme as well.

I can use both, And I have used them in different project.

As I follow you and you are my idle. I want to know that which one you have used. I will use that.
Thank you sir😍

Using OOP extends magic, to inherit store class info and modify or use switch/case approach, usually what I've seen in Laravel forums.

For me, I prefer the use one class with a method switch inside rules method:
EX. switch ($this->method()) {
case 'POST':
{
return [
'password'' => ['required']
];
}
case 'PUT':
case 'PATCH':
{
return [
'password' => ['optional']
]
}
default: break;

Trying to make it as efficient as possible (with multiple conditionals) is just making it harder and harder to read. Do this instead: define validation rule sets for each route that hits that validator. For each route define the route name as the key to which the values are the validation array you would put normally. Then, by using this in a look-up table manner, you can easily provide the validation rule set you need (by passing in route name as a key to the look-up table of rule sets).
Although there will be duplicates in rules, it does change 2 things - now the logic is more readable for multiple route support and rules are in one place, desatured of conditionals in order to make it as easily updateable as possible.

Guys, look-up tables are damn powerful. Use them. Or match expression, it's powerful also.

I create two classes, store and update. The update class extends the store class. This way the update class will be empty until the rules need to be different.

Even though i can follow the argumentation of single responsibility, I would prefer one single class for the same model, if the structure would allow it. If I would follow the same idea by structuring the request classes in folders, I could as well follow the strategy to have only one method per controller, create multiple controllers, organize them in different folders and thus separate everything. That would end up too atomic....

thanks very interesting