Let's move on to Model Factories, some big changes here. So to start, in version 7 of the framework, Database, Factories, here is the UserFactory that ships with it. And with this created, of course, I could say, boot up php artisan tinker, and maybe in a test file or something like that, I want a factory for a User. And there we go. All right. However, in version 8, the framework switches over to class-based factories. A little different here, but I actually like it a lot more. So notice our UserFactory is now a full PHP class.

A little different here, but I actually like it a lot more. So notice our UserFactory is now a full php class. All right, let's have a look. So we give it the name of the corresponding model, and then we provide the definition. So this is identical to the array that we had earlier. However, because this is a class, we end up with a lot more flexibility, as you're about to see. So let's switch back to Laravel 8, boot up php artisan tinker. And now, if I try to run factory again, that's not going to work. In fact, there is no factory function anymore.

And now, if I try to run factory again, that's not going to work. In fact, there is no factory function anymore. Now, again, don't worry if you're upgrading to Laravel 8. There is a legacy package you can pull in so that you don't have to rewrite all of your tests. That won't be a problem. But again, if you're starting anew, yep, no more factory function. Instead, have a look here. On your User model, you'll see a brand new trait here called HasFactory. This allows us to call a factory method directly off of the User model, like this.

On your User model, you'll see a brand new trait here called HasFactory. This allows us to call a factory method directly off of the User model, like this. App\Models\User::factory()->make(). And now we get that same thing. So I think you may find this has a more object-oriented feel. For example, in one of your tests, you will import your User, and then whenever you want to say, well, I want to factory maybe three of them, and again, I'll just call make. We're not going to persist it. So this will give me a collection of three Users. Now because, let me switch back here, because this is a class, we can easily modify the

So this will give me a collection of three Users. Now because, let me switch back here, because this is a class, we can easily modify the definition state by simply adding a new method. For example, if I added an admin method, I could then say this state, and let's set admin to true. Now I don't have an admin attribute here or on the table. So real quick on my users migration, let's just add one here. table boolean admin, and that will default to false. Okay, so now I'm going to refresh my database. And now if I switch back to UserFactory, maybe the normal state will be false.

Okay, so now I'm going to refresh my database. And now if I switch back to UserFactory, maybe the normal state will be false. However, if you call this method here, we will adjust the state of admin to true. All right, let's give it a shot. So one more time, boot up tinker, I will import the model, and yet again, if I were to say just make a User, there we go, admin is set to false. But now let's just add admin, or again, name it anything you want. So if you want isAdmin, that would be fine as well. And it failed. Oh, I'm sorry.

And it failed. Oh, I'm sorry. I forgot to return. Okay, one more time. Sorry about that. Now if I run it, notice we've created an Administrator. Let's do one more just so we're all on the same page. Maybe you have the concept of an active status. So again, this would be maybe a boolean for whether or not the User is subscribed or is active.

So again, this would be maybe a boolean for whether or not the User is subscribed or is active. And again, maybe that defaults to false. Okay, so now we have two different states a User can be in. They are in the active state or the subscribe state, whatever you want to call it. And then maybe they're in the guest state or inactive state. Now I can have an admin method here, and we'll do it one more here. Or again, whatever the actual concept is in your project. Maybe subscribed, that would be fine as well. So if we were to set that, we would set isActive to true, and again, maybe the initial isActive

Maybe subscribed, that would be fine as well. So if we were to set that, we would set isActive to true, and again, maybe the initial isActive would be false. All right, so yet again, we have a couple variants here. So I will import User. We'll say UserFactory::make(). Here's what you by default get, a standard User who is not an administrator who is not active. But if I were to make them an admin, now that's true. And I can even make them, what did we call it, subscribed.

But if I were to make them an Admin, now that's true. And I can even make them, what did we call it, subscribed. And that works as well. So what's nice is because these are standard methods, maybe it fits your brain a little better versus the way we would create model states as part of version 7. All right, so in the next episode, we're not done yet. We'll stick with model factories and talk a bit about relationships and how we can handle those.