تماشای این درس نیاز به اشتراک حرفه‌ای دارد.

Applying Tailwind Layout0:00

Let's finish up by making the modal a bit more dynamic. First, let's make this a little more pretty. I'm going to open up Tailwind UI, and why don't we grab one of the free components. I'll start with... Well, why don't we start... Yeah, let's do this real quick. So I will go to my layout file, and this is just a grid with a single slot. So as long as we add a new slot, I can get rid of all of that, I think? I don't know. Let's have a look.

So let's copy that, and then, let's see, dashboard replaced with your content here. Let's spit out our slot there, and then when we go to our welcome view... Hello world. Yeah, there we go. So let's now add our table there. Reformat, which PHPStorm's struggling on, that's okay. Yeah. Okay, so what do we need? How about just the name? No title, no status, no role.

How about just the name? No title, no status, no role. So give me a minute to look over this. No title, no status, no role, just an option to delete. And then we have Jane. So get rid of that one, status, role, is that it? Have a look. That's good to me, which means if I get rid of all of this, we would... Sorry, give me just a second to clean this up. Okay, so it sounds like we're going to have a User record for each table row.

Seeding and Listing Users2:15

We just have that homepage. Why don't we send through users, and we're just going to assume all the proper permissions because we don't really have any website here. Hunt down all users. And then behind the scenes, I have a simple SQLite database. So why don't we migrate it, and then boot up php artisan tinker, and we'll say, app\Models\User::factory()->times(5)->create(); Okay, so now I have five users in our system that will then be passed to the welcome view. The welcome view will iterate over those users, and for each one, render a table row. So if I come back and give this a refresh, we see Jane Cooper five times.

The welcome view will iterate over those users, and for each one, render a table row. So if I come back and give this a refresh, we see Jane Cooper five times. So now we can just swap this out with the user's name, and then the user's email. And then we have this edit link that we're going to change to delete. So if we come on back, this is what we get. I don't have an avatar here, in fact. That's distracting. Why don't we get rid of that? And then remove the margin left. All right, come on back.

And then remove the margin left. All right, come on back. Yeah, that's fine. So now we're ready to go. When I click on this delete link, I want to open up the modal. However, at this point, we had a delete User Livewire component, right? But this is no longer quite right. So why don't we do this? I'll show you a little tip. Livewire.

Renaming Livewire Component3:39

I'll show you a little tip. Livewire. Let's grab Livewire. They have something called Livewire move. So this is a way to easily rename an existing Livewire component and the associated view for it. So if I were to say Livewire move deleteUser to, I don't know, manageUsers. There you go. So notice it renamed this, like so, and then updated deleteUser to manageUsers. Okay, so if we have a look, we had the exact same thing, but the naming is a little better.

So notice it renamed this, like so, and then updated deleteUser to manageUsers. Okay, so if we have a look, we had the exact same thing, but the naming is a little better. Next, while we're here, I'm going to make this a little more readable. How about deleteUserModal is set to false. And then handle, we'll call that deleteUser, and that will accept the user. Something like this, where we would ultimately user->delete(). You get the idea. Okay. So now, if we come back to our welcome view, this whole thing basically, let's see, I think this whole thing could go into manageUsers.

Moving Table into Livewire4:35

So now, if we come back to our welcome view, this whole thing basically, let's see, I think this whole thing could go into ManageUsers. So again, I could do Livewire like this, or I can do Livewire ManageUsers. And if I click through there, let's comment all of that out, paste this in, and see how we're doing. Okay. Undefined variable users. That's because we need to either pass it through, or fetch the users on the Livewire component side. So if I come back to routes, let's return this to a simple welcome view, and then our

component side. So if I come back to routes, let's return this to a simple welcome view, and then our Livewire component will be responsible for grabbing those users. And why don't we just start with this? User::all(). Remember in real life, you want to paginate these, but I don't want to introduce so many topics that extend far beyond working with modals. But just keep in mind, with Livewire, you could use, what is it called? With pagination? Yeah, you could pull in that trait, call the paginate method, and you're basically good.

With pagination? Yeah, you could pull in that trait, call the paginate method, and you're basically good to go. Let's have a look. Come back, give it a refresh, and now we're getting the same thing, but this is all isolated within a Livewire component. So now, we're finally getting somewhere. Little bit of prep work, but that's okay. So now, all I really need, I think, is this section here. So let's cut all of that out.

So now, all I really need, I think, is this section here. So let's cut all of that out. I no longer need this. And then, hmm, can I put it down here? Let's add our confirmation there. The model changed to show, what did we call it? DeleteUserModal, or modal. But notice that's not quite right, is it? showDeleteUserModal is really what it should be. Like so, and then update this.

Show deleteUserModal is really what it should be. Like so, and then update this. Okay, so now if we scroll on up, when we click on delete, why don't we, and anchor's fine, but why don't we make this a button instead? Does that look okay? Refresh. It's fine. So now, I could say wire:click, and then we'll just do it once again, showDeleteUserModal, and change that to true, or toggle it. Now, if I run it, I click delete, and it pops up.

Confirm Delete and Track User6:48

and change that to true, or toggle it. Now, if I run it, I click delete, and it pops up. This is what we want, and it'll work for any of them. But again, now we need to update the modal to reflect information about the current User who was selected. So it sounds like, as part of this, we need to give Livewire some information about who we are deleting, right? So why don't we change this? Let's call a method, and we'll call, well, we're going to, hmm, do we want to delete, or confirmDelete?

Let's call a method, and we'll call, well, we're going to, hmm, do we want to delete, or confirmDelete? Something like that. Manage users. So let's add our method delete here. And yeah, I need some way to access the User, so I'm not even sure if we're going to keep this yet. But I need some way to access the User. So what we can do, so have a look here, I'm going to dd the User, and then we're going to pass the User as part of this.

So what we can do, so have a look here, I'm going to dd the User, and then we're going to pass the User as part of this. So with Livewire, we can just say, well, we have this User record here, right? So why don't we pass through the user's ID? And now that number will be sent through to this delete method, and then Livewire can use the automatic resolution based upon the key, in the same way you're used to with Laravel. So let's give this a shot. We're going to try to delete Katty Moore, and let's have a look at the attributes. There you go, Katty Moore. Let's do Imogene, is that right?

There you go, Katty Moore. Let's do Imogene, is that right? There we go. And now we're able to control which User we are deleting. So if we come on back, let's keep track of it. Maybe public currentUser, maybe, or the User we're deleting, maybe. I'm not sure, but this will be a User. So we could then say $this->currentUser equals $user. Okay, so here's what I'm thinking. Why don't we change this to confirmDelete?

Okay, so here's what I'm thinking. Why don't we change this to confirm delete? I don't know, naming is kind of hard. So when you click on this, I'm not deleting it yet. I want to confirm that we're going to delete this User. As part of that, we will track which User we're working with, and then we will update showDeleteUserModal to true. So if we did everything correctly, when I click on this, we're now showing the modal, but I also have some reference to which User I'm interested in, which means if we come on back to manageUsers, right down here, we could say delete currentUserName.

but I also have some reference to which User I'm interested in, which means if we come on back to manage users, right down here, we could say delete currentUser name. And let's just see if that alone would do the trick. Trying to get property name of non-object. currentUser. So currentUser is null at the point this runs. Oh, yeah, of course, of course. So we're not setting currentUser to anything until you click on that link. So before then, let's see. Let's set currentUser.

So before then, let's see. Let's set currentUser. Could I just initialize it to a new User? I don't know. I'm doing this on the fly. Give me just a second. Yeah, I guess that works. Delete KatieMoore. Delete Rosario. This is working.

Delete Rosario. This is working. So notice now the modal is dynamic based upon some kind of field from your Livewire component. Then down here, if we come on back, if I call continue, what did we change that to? Delete. Maybe just delete. Confirm delete. Delete or delete User, whatever you want. Do we pass the User ID through here to make it more flexible, or do we always assume if you're going to delete, you will then go this current User or delete?

Do we pass the user ID through here to make it more flexible, or do we always assume if you're going to delete, you will then go this current user or delete? I'm not sure. But anyways, this is kind of the general flow. We're doing this on the fly here, so you might change it up. But this is the general flow you might take. So let's have a look here. What happens if I delete Katie? Yeah, so notice behind the scenes, Livewire is cool. You've got to be honest.

Yeah, so notice behind the scenes, Livewire is cool. You've got to be honest. Livewire is pretty cool. Behind the scenes, this will update. And in fact, if we check out models User count, there should now only be four, because remember we started with five. But notice I still see the modal here, so we just need to hide that. So when you're done, this showDeleteUserModal is false. Or you could add a trait for helper methods when working with the modal, so it's consistent from Livewire component to Livewire component, like cancel or hideModal.

Or you could add a trait for helper methods when working with the modal, so it's consistent from Livewire component to Livewire component, like cancel or hide modal. And then you basically contain these Boolean toggles. All right, let's give it another shot. We're going to delete Rosario. Delete. We see our confirmation. If I click cancel, she remains. But now if we delete Dr. Rosario, it works. Back to PHPStorm, run it again, and now we only have three.

But now if we delete Dr. Rosario, it works. Back to PHPStorm, run it again, and now we only have three. Okay. And that's the nuts and bolts of it. You just need some way to track what piece of data or what user or what model you're working with. And you can do that as part of preparing your modal. So where you would normally toggle the modal, that's also where you can set, all right, this is the user I'm working with, or this is the record I am updating. Then within your modal, you can reference any of that data.

Submitting Delete via Form12:14

this is the User I'm working with, or this is the record I am updating. Then within your modal, you can reference any of that data. And this can be a form that you could submit or a button you could click. So if it's a form, you could, what are you doing here? I guess you'd have to do it, excuse me, you would wrap this within a form and then listen for submit. And then you would say wire:submit, then delete, or do a click event. The benefit to doing it as a form is it's more appropriate for what you're actually doing. It'll respond, let's just do it, to the enter key.

doing. It'll respond, let's just do it, to the inner key. So paste that in there. And then wire, submit, prevent the default action, call delete, and then this can return like so. Now let's have a look at this component we made here. We have it set to a type of button. In this case, I would want to change that back to a type of submit so that this does behave as the submit button for the form. All right, let's have a look.

دوست دارید گاهی خبرهای Laracasts را ایمیل کنیم؟