One Reason to ALWAYS use Form Requests for Validation 

Some design principles contradicts each other.

Don't agree with YAGNI here. YAGNI is more about for example adding method of rclass that is never used(or only in tests), or adding some column and saving some information on table that is never used and stuff like this.

I agree.

I am a fan of sacrificing a little KISS for the sake of easier maintainability in the future. The fewer lines added to my team's PRs the better and anticipating future modification can be a big help in that. Consistent use of FormRequests even for just 1 field is a good example of this

@@max7579 yeah, true. But that comes with proper planning.

Thanks for this additional very valuable comment.

Glad you like them!

Yes for more complicated cases it happens. But then you have prepareForValidation() method. Can you give an example case, and I will shoot a separate video for you.

@@LaravelDaily Yes you are right, the prepareForValidation() function is great for merging values before validation, that I am using as well. To be honest I haven't found a good example because - after your comment - I realized that some controllers could be enhanced by moving a lot more stuff to the preparation function.. will give that a try and let you know if I encounter something that would be an example for keeping it in the controller.

Hello friend. The way I see it, you use a resource to "serialize" your model data. For example, maybe for a given model you're never interested in returning the id field, or created_at and updated_at fields, or you even maybe have to change some field in some way; the place where you can't put this logic is in a Resource (or a Resource Collection if you give a Collection to the constructor of the resource).

For consistency if I need to reuse that Resource somewhere else.

Will shoot a video about it

Phpstorm theme Material darker

Just reuse your own validators, nothing wrong with that.

Yes, usually I separate them, but it's a personal choice and depends on the situation. Planned to shoot a separate video.

You can get the rules from FormRequest and reuse them from wherever, something like: $rules = (new App\Http\Requests\StoreUserRequest)->rules();

Yes, that's a good point, I don't like that either.

It depends on the situation, it's your choice. Will shoot a video about it, added to the to-do list.

@@LaravelDaily Thank you! Looking forward to it

It depends on the structure, so hard to comment, maybe provide a specific example, but generally you can pass all of that into the rules, like 'products.*' => 'required' or something like that.

Yes, Controller code is executed only if validation passes. I will shoot a separate video on how to separate html and api.

@@LaravelDaily thank for your time

I personally create a different form request for update. But it's your choice. I will shoot a separate video on how to use the same form request file for create/update.

@@LaravelDaily Thanks!

You can globally override validationexception, like I did in this video with another exception: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-SlBJrLnyoMk.html

What about it?

if you mean return costume message, you can use this $messages = [ 'old_password.required' => __('api.old_password_req'), 'new_password.required' => __('api.new_password_req'), 'old_password.min' => __('api.old_password_min'), 'new_password.min' => __('api.new_password_min'), ]; //validation $validator = Validator::make($request->all(), [ 'old_password' => ['required', 'string', 'min:8'], 'new_password' => ['required', 'string', 'min:8'], ], $messages);

If you use a Form Request object, you can add a messages() method to it that returns an array with inputs and rules that you want to have a custom message, like that: [ 'email.required' => 'Please enter your e-mail address', ... ];

Unfortunately not.

Unfortunately not

I see thanks!

Possible rubber duck moment, will test when I get home. :D

Locale should be set not in the controller, but somewhere much earlier, like global Middleware or something.

Thank you so much! :) The best thing I came up with was a (very) hacky way of adding initialize method to my form request, setting locale there based on php $_POST and then calling the parent initialize. Even though I was content with finding a way, I was sure someone would point me to the proper way. I did it with middleware this morning. :D

It's a personal preference. I would create a Policy for that.

@@LaravelDaily Cool, I put it in a middleware at first, but my senior collegues said a middleware should be more generic to be applied to more routes, instead of very specific to one route. I have to study Policies then, thanks for the reply! >D

Probably watch this video: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-kZOgH3-0Bko.html

@@LaravelDaily ended up creating a Policy haha

Yes, in theory you're right. A common practice is also DTOs or Value Objects if you want to systematize it. But in practice, it's often "whatever works don't touch it" :)

I will shoot a separate video about it, I see many people asking for it, so need a video :)

Looking forward to this. Thank you!

It might work if your app is mostly made of simple and straightforward CRUD operations, and if you stay consistent with this approach (i.e. not switching between inline validation and Form Request from controller to controller). But if there is a lot of complex logic that needs to validate relationship association etc., you would go mad cramming it all into controllers. That's exactly when the issue arises: you have some simple stuff validated right on the controller, and then you have this complex validation in some other place moved to a Form Request object with Rule classes and stuff. In practice, it quickly turns development into nightmare in any relatively big or complex project as you add a reduntant cognitive pattern of making decision of "Where did I put that shit 6 months ago?! Ah, yes...".

I agree, but then it complicates the learning process for new people and they get conflicting advice - in this case do X, in that case do Y, etc. I think it's better to adapt one strategy and just keep creating form request classes and stick to it. Or, validate everything in controllers and stick to it. So I've stated my position in this video, with arguments. Sure, it's not the sacred rule, but one fewer question to ask yourself "where to put X" and move on to more important questions.

@@LaravelDaily yeah, the consistency is important too. But there's one other point that i, for instance, have to consider: who you expect to be mending for this code (besides yourself). In my practice, it is more often a person with a general php knowledge, than someone, who knows it all about your framework of choice. (Offtop) it is very interesting, though: Google trends clearly show that Laravel is very popular, but in my country it's easier to find someone with Yii expertise than with Laravel... But sure how come...(/offtop) And, speaking of "general php code": it is not intuitive (without decent Laravel background) that a class, typehinted on the controller method's argument, actually does something like validation or authorization. `$request->validate(...)` is way more intuitive for a 'proficient in php, but not too much into Laravel specifically' dev, who you invite to your project.

That's a very VERY good point - will even post it on Twitter. Now I clearly see the difference in comments - from people who come to Laravel after a long experience with plain PHP or other framework like Yii, vs people who started with Laravel and never knew any other. So yes, then opinions are very different, and audience is different. On this channel, I'm not teaching PHP and not trying to do it the PHP way. I'm trying to explain how to use the framework that we all love to its fullest potential. The channel is "Laravel Daily", not "PHP Daily" :)

I guess I need to shoot a separate video for it, at least a few people ask the same thing

@@LaravelDaily thank you I appreciate it

Well, yes, model is responsible for CREATING the product but not VALIDATING INPUT. Technically you may be right, but it's not typical practical thinking in Laravel.

@@LaravelDaily Yes, I agree with using FormRequests. I meant there's no need to create a separate Action/Service for creating the Model after the input is validated.

The docs: laravel.com/docs/9.x/validation#customizing-the-error-messages

@@LaravelDaily thanks

Of course, it depends. In some cases, you do need separate form request classes, or you could have the same form request class and rules() should be dynamic with if statement if request comes from API. There's no one rule, it's all personal preference.

One way to keep things clean and consistent in these cases while still using the Form Request objects, would be to add another level of abstraction in the same manner that we use the Repository pattern along with our models. Let's say you have two endpoints for external and internal API feeding from the same logic domain. You can add a separate class that holds validation rules (and even messages, if needed) for these endpoints as separate methods, and then you call these methods inside the Form Request object dynamically depending on the request being sateteful or stateless ($this->wantsJson()). It helps to avoid creating a lot of spaghetti in both Form Request and Controller while keeping the necessary logic and static properties close to its domain.

I personally always name [Store|Update][ModelName][Request], like StoreUserRequest or UpdateUserRequest

Form validation lets you construct good response if some fields do not pass validation

In my opinion, it's about habits. So just get used to use form requests and then you don't need to think how to do it each time differently.

Yeah, makes sense

I will shoot a video soon where you can use the same form request for store and update, even if the rules are different.

Why not possible? $request->validated() + ['user_id' => $whatever]

@@LaravelDaily I mean in Form Request class not in Controller

You can use prepareForValidation maybe? dev.to/arielmejiadev/prepareforvalidation-method-in-laravel-form-requests-29ao

@@LaravelDaily I have to deal with projects where there are FormRequests with 3-4 levels of inheritance passed around in the application, where each one of them adds its own garbage via methods like prepareForValidation(). Truly nothing makes me more mad than this.

It's an imaginary solution to an imaginary problem. You can just use a function if you wanna reuse a piece of code. And in fact functions are much more reusable (in more places) than these weird FormRequests that interact with global state in order to be constructed. It's extremely annoying how they are sold as some superior thing when they really just mix the worst practices of OOP and procedural programming into one giant mess.

You can't

@@LaravelDaily thanks

@@LaravelDaily Does we have any ways?

Next time please google and read the official docs. I googled "Livewire form requests", quote from the official docs. Due to the nature of Livewire, hooking into the http request wouldn't make sense. For now, this functionality is not possible or recommended.

@@LaravelDaily ok, thank so much

I solved this issue by using laravel module package. Works like a charm.

You can simply segregate those classes by directories inside the app/Http/Requests directory, like: app/Http/Requests/Checkout or app/Http/Requests/User, etc. Just set the correct namespace, or generate them via artisan command, specifying the folder, and then Artisan will set the correct namespace for you. It really helps to keep things organized, especially if you prefer to work with a mouse and a sidebar in the IDE instead of IDE's quick search.

@@UnknownUser-ud1es As the doc says : "This package is supported and tested in Laravel 5", far away from 8.x isn't it ?

@@user-si3nz1dd9w Yes this is some clean option, you still have a lot of subfolders instead of a lot of files, but this is the way i prefer

Personally, I prefer dirty Requests folder (which can be cleaned up with subfolders) than dirty controllers.

You have the right to not agree, that's the beauty of what we all do here. But I don't really understand the argument - how API validation is different from Web? Why form requests for API and not Web?

It's a matter of habit. If you do it automatically for any project, small or big, then you have one fewer question on how to do it in the future, and focus on other more important questions.

@@LaravelDaily Yes you have point But don’t forget about simplicity and lesser abstraction easier to read. There are cases that inline might be suitable. for me “Would you use washing machine to wash a single shirt? it’s better to wash it by hand so it’s easier rather than putting extra effort” 🙂