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

hello guys today i want to talk about quite an old topic but from different angles so let's talk about form requests and specifically for store and update methods should the form request class be same different how do they get their differences and stuff like that and i have four examples for you and if i missed something shoot in the comments below with your own example maybe i didn't think of some case but step by step from the simple example to more complicated with ignoring the id for update and stuff like that the first simple example is if the validation rules in the requests are the same but for some reason you want to have separate form request classes and you want to have store task request and update task request so store task request has these validation rules and update task request has the same validation rules but you separate them just for the sake of separate structure and then in your app http requests you have two classes for every eloquent model which is fine and i personally prefer that even if the rules are identical you never know what happens in the future and some people argue that then there are too many classes in the requests folder but i'm fine with too many classes it's not like we're trying to save kilobytes of data or something like that if you want more structure you can create subfolders in the request classes and that would be if you want more structure you can create subfolders in the request folder and solve the problem this way to me it seems like following the separation of concerns and single responsibility principle that this class is responsible for storing the task this class is responsible for updating the tasks which may be identical now but different in the future let's go to example number two the same situation identical situation is just in a different controller project controller and instead of having two different classes you decide to have it in one request class just to have fewer smaller amounts of classes in general so you know that the rules are identical for store and update for projects and you just put it all in one form request class and one set of rules and you use that in both store and update this is also fine it's mostly your personal choice and depending on the future that you think what would change if the rules will be likely to change or not this is also a normal approach and actually all of those approaches mentioned in this video are mostly personal preference now let's get a bit deeper what if the validation rules are not identical but they are slightly different with one or two field difference and then you would probably use separate form request files but what if you want to use one user request for example class and inside of that form request class has some logic to define whether it's store method or update method let's take a look at what we can do inside of the form request class so here's a number of ways that we can use here so for example a typical example is password so password is required in the create form but not required in the update form so if in the update form the password field remains empty it means that user does not want to change the password so this is what you can do so password rule may be a dynamic rule depending on the request and where it comes from and there are two methods to typical methods there may be more to check the request this is method one so if the route name is user store then password rule is required otherwise if it's user update then the rule is sometimes by the way did you know the rule sometimes sometimes means if that field is present then it's required so if it comes within the request then it's required if it doesn't then it's not required and with that sometimes we need to actually remove that password field if it is empty and for that we can use a method inside of the form request class called prepare for validation prepare for validation changes the requests manipulates the request before actually calling the validate method so here we can check if the password is null or empty we can remove it from the request then in here when it comes to here password rule is sometimes and then it passes as a valid request another way of checking if it's store or update method you can do it by route names or method two is i've seen people do that you can check the method the post method is used for store and the put or patch method is used for update so this is how you can define whether it's create or update form so basically you form your password rule based on the request and then you add that in the password rule here now there is the third method so instead of dynamically do that before the return array since laravel 8.55 from what i remember there is a new thing called rule 1 so this rule1 condition you can do request is method or request name as here route is and you define your rule dynamically whether it's required or optional with rule 1 but it's available as i said in the latest laravel versions and finally let's talk about ignore rule for unique fields for store and update and this is a topic i've seen online very confusing since almost level four from what i remember so how to ignore the current email or current record for the update so here's the scenario the form for adding admins and if we try to use the same email in the create form so i use fake filler chrome extension but choose the email of already existing email i create and the email has been already taken validation so in the create form that validation should exist but when you go to the edit form it should allow to use the same email address because it belongs to the current record that you're editing which is fine basically you want to edit just the name but not the email you update and the validation should not fire with one condition in the storeform request and unique with another condition in update forum request but let's take a look an example with the same form request class which is admin request and it is almost identical to the one that i've shown you before with user store and update but we are interested in this specific line email is required and unique within table users but we can ignore the current record and in the official laravel documentation that unique validation rule if we scroll down a bit there's a section called forcing unique rule to ignore given id and you can ignore it by specifying the id of the record or specifying the whole record which is then ignored by the id of that record by default and what that documentation doesn't say is how to use that in the form request class where you don't have the variable of user actually you can access all the variables from the request by doing this so this admin corresponds to the controllers admin variable here in the update if you use route model binding so you can access this admin or you can even do this admin id and then the email unique validation for the current admin record will be ignored also as the comment above states you can do that simply with unique user's email and using this admin what you should not be doing however and this is really important for security reasons and laravel validation documentation says that you should not put anything from request here in the ignore section if you do something like request for example segment 1 which is the url the part of the url it is a security issue because malicious people can use the request and kinda break your application with sql injection as it is said in the official validation documentation so what do you think about all those cases do you use the same form request for store and update or different ones and why and maybe you have some different solution for the unique rule and ignoring share all your opinions in the comments down below and if you want more videos like this one of course subscribe to the channel to get daily videos on laravel and relate to topics and also you can support my channel by purchasing one of the three products that you can see on the screen now my admin panel generator set off livewire components at live market or one of my 20 courses now on teachable platform see you guys in other videos

Channel: Laravel Daily

Views: 14,367

Keywords:

Id: YK8GZmuf8_0

Length: 8min 28sec (508 seconds)

Published: Sat Sep 04 2021