در حال بارگذاری ...

Creating Tasks Backend0:00

Let's now take what we've learned and make it just a little more real world, a bit more visual. So at the moment, I have absolutely nothing on the home page, as you see right here. Let's just display a public task list, the most basic possible task list we can think of. So let's do this. php artisan, make me a migration for a tasks table. And we'll switch over there. And like I said, as simple as we can. So we're just going to say, a long text field for the body of the task. That's it, nothing else. So I will migrate my database. We're just using an SQLite database here. Next, ah, you know what, we need a model. php artisan, make me a model for a Task. Next, let's set up a few endpoints. From my routes/web.php file. So let's set up a route to fetch all of the tasks. In here, we'll just say Task::orderBy('created_at', 'desc')->get(); to get them in descending order. I don't even need the full

From my routes/web.php file. So let's set up a route to fetch all of the tasks. In here, we'll just say Task, get them in descending order. I don't even need the full task. So let's, like I said, as simple as we can possibly make it. Just give me an array of the body for every task that we have in that table. Okay, let's do another one. If you submit a POST request to /tasks, then of course, we need to persist the task. We could say Task::create, or we don't have guarding turned on, so let's just force it. And we'll say request['body']. All right, so we're going to create a new task with the key body and the value equal to whatever was sent through in the request. In real life, we probably want some sanitizing, some validation. Let's keep it simple though. All right, so does that all make sense? So we have a migration for tasks. We have a tasks table. We have a Task model. We have two routes to fetch the tasks.

Building TaskList Component1:36

Let's keep it simple though. All right, so does that all make sense? So we have a migration for tasks. We have a tasks table. We have a Task model. We have two routes to fetch the tasks and to create a new one. So the next step is, let's create a view component to display the Task. In resources, assets.js, why don't we override ExampleComponent? We'll call it TaskList. Right here, get rid of all this. We'll have a div. Within it, a simple unordered list, where we will filter through all of the tasks and for each one, just spit it out. Next, we can say data. Well, of course, we need to read these tasks. Next, we'll say when the component is created, let's make an axios call to fetch all of the tasks. And then when we get a response, we will update tasks to response.data. Okay, does that all make sense? So when the component is created, we're going to jump in the database, fetch all of the tasks. At the moment,

response, we will update tasks to response.data. Okay, does that all make sense? So when the component is created, we're going to jump in the database, fetch all of the tasks. At the moment, we have zero, so we return an empty array. Then up here, this will render each of those tasks as a list item. So now, if we go to app.js, here we're registering that example component that's included with Laravel. I'm not going to do taskList. We'll just make it global, no problem there. Finally, in our main view, we're going to load or reference that component taskList. Okay, so let's go ahead and give this a compile. I'm just going to boot up our watcher. And now, if we switch over to Chrome, give it a refresh, we don't see anything, but we would expect as much. So right here, we fetched all the tasks and exactly zero were returned. So if we give that another run, here's our XHR request that returns an empty array.

Adding New Task Input3:23

but we would expect as much. So right here, we fetched all the tasks and exactly zero were returned. So if we give that another run, here's our XHR request that returns an empty array. Why don't we add an input to create a new task? And once again, as simple as we can make it here, we'll just have an input. We'll bind it to newTask, maybe that. Next, we could add a button, let's just say. When you blur, let's add a new task there. So we need a method for that methods, addTask. And what should we do there? Well, we're going to submit a POST request to tasks. And specifically, I want to give it the body. And that should be equal to whatever the user typed into newTask. Like so. Next, though, I want to append that newTask to the list. So maybe here we could say after that this.tasks.push(newTask). Finally, let's clear out that input for the next one.

I want to append that new task to the list. So maybe here we could say after that this tasks.push the new task. Finally, let's clear out that input for the next one. This newTask is an empty string. All right, give that a hard refresh. We'll say go to the store. I'll hit tab to make a blur event. And here we go. So in this case, we made a POST request to /tasks. That endpoint isn't returning anything other than a 200 response. And then finally, we did append to that list and cleared the input. So now if I give it a refresh, that should be persisted because we did save it to the database. So now what I want to do, let's say get groceries. And actually, before I blur, let's give that a refresh. Okay. Well, actually, that caused a blur event. But something else, what I want to do now is when I tab away here to append the item, I want something else to show up on this other user's browser. That way,

Broadcasting TaskCreated Event5:09

actually, that caused a blur event. But something else, what I want to do now is when I tab away here to append the item, I want something else to show up on this other user's browser. That way, maybe you're collaborating with your spouse on things that you need to get done. And if I add a new task, and she's looking at it at the same time, I want her to see that immediately. Again, this is an example where something like Pusher is perfect for that. Let's see how. The first step is we need to broadcast an event, right? We've already learned that within a new terminal here. Let's make an event. And we'll call it TaskCreated. Okay, let's view the event. Now OrderStatusUpdated. That's actually from a previous exercise. So we'll delete that. Anyways, right now we're going to broadcast it on still a standard public channel. And we'll call it tasks. Alright, so once again, do note that we imported Channel at the top. Next, we need to send through the

we're going to broadcast it on still a standard public channel. And we'll call it tasks. Alright, so once again, do note that we imported Channel at the top. Next, we need to send through the Task that was created. So I will accept that, assign it, and then declare it as public up here. Finally, we should be specific and say that this event implements the ShouldBroadcast contract. Again, that's our way of telling Laravel, I expect you to broadcast this event to the client side or send it up to Pusher. With that finished, we'll come back to route /web. And I'm just going to do it in line here. When you hit this endpoint, yes, we'll create a new Task. But then we will fire an event that the Task was in fact created. So we'll import that at the top. We will send through the Task that was created. Like so. Let's work through it again one more time really quickly. You hit this endpoint. Yes, we take what the user typed into that input and we throw it.

send through the task that was created. Like so. Let's work through it again one more time really quickly. You hit this endpoint. Yes, we take what the user typed into that input and we throw it into the database. But then we dispatch this event called TaskCreated. Now if we look at TaskCreated, immediately we can see, oh, this event should broadcast to the client side. And specifically, I want to broadcast it on the task channel. Let's give it a shot. We're going to go back to Chrome, give it a refresh, and we'll say, well actually before we do that, let me switch to Pusher. All right, let's go into my app, debug console, and yeah, now let's give it a shot. Do new thing, tab, and if we switch over, we can see that we sent this up to Pusher, right? So now we're going to use Laravel Echo to say, well listen on that tasks channel. And if we pick up on a TaskCreated message, well I need to update that list. Let's come back to code and we'll say right here. Let's

Listening with Laravel Echo7:38

to use Laravel Echo to say, well listen on that tasks channel. And if we pick up on a task created message, well I need to update that list. Let's come back to code and we'll say right here. Let's go to taskList. We can do it here to start and we could say window.Echo on the channel called tasks. Now again, if you ever forget where's this key coming from, it's coming from the event. We specifically said this is the channel. Think of it like this is the frequency that we're broadcasting on. So I need to make sure that with Echo we specify, well what frequency are we turning to to listen? Turn to that frequency and then listen for somebody to say that a task was created. When that comes through, well what should we do? We'll push to this array. We'll say this.tasks.push a new one, e.task. Now if we switch back, you'll see this basically represents the event or the message that came through. And if we want to grab the task, I could say message or

Preventing Duplicate Broadcasts10:17

request to add that task to the database. And then we push that task onto the list. So that represents the first addition here, right? But then we'll think about it. When we saved it to the database, we also fired an event. For that event, we specifically said broadcast that using pusher. So now pusher received the message. And if we switch back here, we said, well, if pusher receives a message and we hear it, well, once again, we're going to take the body of that message and we're going to throw it onto the list. That represents the second time. One thing. And it shows up two times. So it sounds like we need to say, well, broadcast this to everyone except me. I don't need to be notified of the thing I just did. So, so make it available. Make an announcement to everybody except me, the person who created it. Let's see how. If we go back to our event, you'll see that the event uses this trait called InteractsWithSockets. And if we scroll down,

everybody except me, the person who created it. Let's see how. If we go back to our event, you'll see that the event uses this trait called InteractsWithSockets. And if we scroll down, don't broadcast to the current user. It sounds like that's almost exactly what we want, doesn't it? Let's give it a shot. We can do this either within the event itself, you could do it in the constructor, or you can do it as part of your dispatch. So for example, I could say here, like this, I could say, create a new event, but don't broadcast it to the current user. Okay, so let's give that one a shot. We'll give both of these a refresh. So now John will create a task. And if we did everything correctly, when we submit this, or blur away, he will only see it once. And he does. So now Linda will see it. Linda responds with her own task. She only sees it once. And of course, John sees it. So all of this is available because of

So we'll try again. For John, it only shows up once. And Linda sees it immediately. So yeah, hopefully you're seeing it's just not that hard. This is one of the nice things about Laravel's broadcasting setup, as well as Laravel Echo on the client end. Both of those work together seamlessly. It hides away some of the more confusing parts to make it as simple as possible.

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