Okay, we can now move on with persisting our Card model to the database. Now, I like to use actions in order to achieve this. If you've used Jetstream before, you're probably familiar with how this works. Basically, you have a dedicated class for action that you want to do, and an action is basically some sort of logic, like creating a User, deleting a User, or in this case, storing our Card to the database. So let's create a new subdirectory inside our actions directory, and let's call it webshop. Now, the convention with actions is to describe exactly what you're doing. In this case, we'll name our class AddProductVariantToCard.

Now, the convention with actions is to describe exactly what you're doing. In this case, we'll name our class AddProductVariantToCard. Let's implement a new method and call this method add, and let's add a die-and-dump message so we can verify that this is working. If we switch back to our product component, we can use the dependency injection to automatically resolve this action and make sure that we can call it. Now here, we can simply say AddProductVariantToCard, and now we can simply call card add. So now when we click the Add To Card button,

and now we can simply call cardAdd. So now when we click the Add To Card button, we should get our die-and-dump message. There you go, adding a variant to card. Now we have abstracted away this logic to an action class where we can put all the logic that we need in order to add our product variant to our card. Let's add a named argument called variantId, and we'll pass it the variantId that is provided by the select box inside our component.

and we'll pass it the variantId that is provided by the select box inside our component. This argument doesn't exist yet, so let's move over to our AddProductVariantToCard action and make sure that we add this property. So now we can start implementing the logic to add our variant to our card. Now there are two scenarios. A User could be logged in, or a User is not logged in. Depending on this, we want to make sure and check

A User could be logged in, or a User is not logged in. Depending on this, we want to make sure and check whether this User has a Card or not. But first, we want to check whether our User is logged in or not. We can use the auth helper for this, and call the guest method. Alternatively, we have the option that, in this case, the User is logged in. But first, we want to resolve whether we have a Card or not. We can say card and get our Card model.

But first, we want to resolve whether we have a Card or not. We can say Card and get our Card model. We can say first or create. So as you might recall, when we check our Card model, we can see that we have both a sessionId and a userId. So in this case, we're going to say sessionId, and we're going to reference the sessionId that is assigned to our visitor. Next, we can implement the same logic on our Guest model.

Next, we can implement the same logic on our Guest model. And we can implement the same logic on our User. So if the User has a Card, we'll return it. Otherwise, we'll simply create one. Let's make sure that we have this relationship set up. Let's define a new method called card, and let's make sure that it returns a hasOne relationship. Next, we'll reference our Card model, because this is the relationship that we want to return.

Next, we'll reference our Card model, because this is the relationship that we want to return. Let's switch back. And let's make sure that we assign this to the card variable as well instead of returning a value. And finally, let's die in the right part to see whether our model has been created or not. Let's switch back to our browser, and let's click Add to Card.

Let's switch back to our browser, and let's click Add to Card. And now you can see that we currently get an error saying that we're trying to build a property which is not allowed due to the mass assignment rules. So I always prefer to turn this off entirely. So let's head over to our AppServiceProvider. And in our boot method, let's add model and call unguard. So now if we try again,

and call unguard. So now if we try again, you can see that our card has been created and that it has been assigned the session ID of our User. Now let's verify that this also works when we are logged in. Let's visit the login route. And let's make sure, of course, that we also have a User. So if we switch back to our editor and go back to our database here, we can call the UserFactory

and go back to our database here, we can call the UserFactory and create a User. Now if you take a look at the UserFactory, you can see that it's generating a unique name, email, and that the password is going to be equal to the password. In this case, we want to make sure that we set our own email address. So I'm going to overrule the email address that is generated by our faker and set it manually. So in this case, I'm going to change it into philo.laracast.com.

that is generated by our faker and set it manually. So in this case, I'm going to change it into philo.laracast.com. Let's refresh our database, see that again. There we go. Let's switch back to the browser and let's log in. That's going to be redirecting to our dashboard route that doesn't exist. We'll fix it later on. If we go back to our store

We'll fix it later on. If we go back to our store and click Add to Cart, you can see that our cart was created, but this time it was assigned to our user ID. So now that our cart is created, we can move on and add the actual variant to our cart.