Constructor Injecting User 0:00In the previous lesson, we took our first steps to validating a user. So you can see here in the store method, we wrote if the user is not valid, and then we provided the post data. In that case, we want to redirect back and provide the errors. Otherwise, we are good to create the new user, and finally redirect back to the user's collection. But now, I'd rather inject this user class through my controller's constructor. Let's go ahead and do that now. At the very top, we will do it right here. Now, I will specify that I expect a user instance. Once again, we could improve this further by instead coding to an interface, but we aren't quite to that level yet. So let's just request the Eloquent object, and then we will assign it, like so, and set the property. All right, so now here's the cool part. You might be thinking, all right, well that looks good, but I'm not in charge of instantiating my controllers. Laravel Automatic Resolution 0:46and set the property. All right, so now here's the cool part. You might be thinking, all right, well that looks good, but I'm not in charge of instantiating my controllers. So how could I even pass in this user object? Well, as it turns out, Laravel makes use of what we call automatic resolution. Now mostly, this is just a lot of jargon to refer to a simple thing. For your controller, Laravel is going to do its best to automatically inject your dependencies. For example, in this case, we've noted that we expect an instance of user in order for our user's controller class to function properly. Well, Laravel is going to encounter that and see, hmm, they want an instance of user. I will go ahead and pass that in for them so that we don't have to automatically do that. Now, this actually can get a little bit more complicated, and we can have a lot more flexibility over what is passed in. We could even type into an interface and then Refactoring Model Methods 1:31have to automatically do that. Now, this actually can get a little bit more complicated, and we can have a lot more flexibility over what is passed in. We could even type into an interface and then tell Laravel which implementation of that interface to use. There's really a huge amount of power there, but we aren't quite to that level. So for now, just accept that for your controller, Laravel will do its best to automatically inject the dependency. Anyhow, now we can update our code like so. So let's go ahead and do all of these together. This user, and now we come to the store method that we worked on in the previous lesson, and once again let's update that like so. However, now we are referencing these as public methods rather than static methods, so we need to fix that now. Let's reopen our user model. Now, if I scroll down, we just need to make a handful of changes. So right here, this needs to be a public method, and that'll make it a lot more testable Mass Assignment with Create 2:16that now. Let's reopen our user model. Now, if I scroll down, we just need to make a handful of changes. So right here, this needs to be a public method, and that'll make it a lot more testable as well. Next, similarly, the errors are going to be unique to the instance. So instead, I'm going to update this to this errors, like so. Now, I just need to return to the top and update the property as well. The only remaining thing to do is to update this static property as well to this user errors. Next, we could even clean up this section where we create our new user. Now, if I return to my user model, do you remember how we specified a fillable property? This is a way to protect ourselves against mass assignment vulnerabilities. It's just a way to say these are the only fields that may be mass assigned. So, because we have that protection in place, we could update all of this to this user create, and then we pass in the input, like so.these are the only fields that may be mass assigned. So, because we have that protection in place, we could update all of this to this user create, and then we pass in the input, like so. However, because we've already referenced it up here, why don't we assign that to a variable like so, and then we will simply update this to input. Now, that's a lot cleaner. And even if the user tries to manipulate the post data and pass through some fields that we didn't allow in our form, well, because we set that fillable property, they will simply be ignored. So, let's go ahead and try it out. If I click the button, sure enough, the validation is still working. But now, if we provide a dummy username and password and click create user, there we go. We're still getting the exact same thing. Now, if I return to my code, part of you might be thinking, well, I don't see the huge benefit to this. Why is it better to inject rather than referencing the class directly? And honestly, Why Dependency Injection Helps 3:51same thing. Now, if I return to my code, part of you might be thinking, well, I don't see the huge benefit to this. Why is it better to inject rather than referencing the class directly? And honestly, there's a number of reasons for this related to flexibility and swappability, but also testability. When we inject our dependencies into a class, it's then easier to test because we can then, if we code correctly, swap these dependencies out with mocked versions so that we can better test in isolation. Now, if that just did a quick flyby over your head, that's okay. You don't need to worry about it just yet, but still try to get into this habit. Now, to finish up, let's just make one final tweak. Here on line 34, you can see that we are saying if this user is valid, but we aren't actually checking the user object itself. We're simply passing in some data. So, we're just calling a helper method that accepts the data and compares that against some validation Validating Filled Model Instance 4:39but we aren't actually checking the user object itself. We're simply passing in some data. So, we're just calling a helper method that accepts the data and compares that against some validation rules. But even though that's perfectly fine and plenty of people do that, does that make 100% sense? If this user is valid, then do that. But that's not what we're doing. We're saying if this user, call a method called is valid, and then compare it against this data. So, why don't we do this? What if we instead said this user, and we are going to fill it up with the input that was provided, like so. Now, think of this as filling the attributes. So, for example, if I were to return this user to array, like so, and we try it out. I'll just use my name. Click create user. Now, we can see that we've populated that user object. Also, if you're wondering where the password is, Laravel is going to strip that out because when we return JSON, well, of course,user. Now, we can see that we've populated that user object. Also, if you're wondering where the password is, Laravel is going to strip that out because when we return JSON, well, of course, you would never actually want to return the password. Anyhow, now that we have this fill method, we could remove this entirely, like so. If we now switch back to our user model, we just have to make a couple tweaks. Now, rather than accepting the post data, it's going to compare it against its stored attributes. And we can do that by saying this attributes. So, hopefully, that makes sense. The only difference is rather than passing the post data directly to this method, we are instead assigning the attributes to the object, and then we are asking the object if it validates itself. Like I said, though, if you'd prefer to do it the way we did before, that's perfectly okay. It just comes down to how you would prefer to build and structure things. So,validates itself. Like I said, though, if you'd prefer to do it the way we did before, that's perfectly okay. It just comes down to how you would prefer to build and structure things. So, to make our final little tweaks here, why don't we do this? Let's assign the input to a variable, like so. And then we can even remove this because we can inline it. So, I could say if this user fill with the input, and if that user instance is not valid, then let's redirect back. Otherwise, we will simply save the user. And with that, although we could even make some further tweaks, we could even hook into model events and stuff like that. For where we are in our learning, I think this is a good stopping point. So, finally, just to make sure everything still works, let's do jobob, give it a password, create user. Everything is still working the way it did in the last lesson, but now this is a bit cleaner.let's do jobob, give it a password, create user. Everything is still working the way it did in the last lesson, but now this is a bit cleaner.
