Now that we understand how to push messages up to Pusher, I now want to switch over to the client side. Using JavaScript and Laravel Echo, and of course Pusher.js, we're now going to listen for these messages on the given channel, and then update the UI or log something to the console, just something to make clear that we have heard that event. Let's go to code, and we're now going to pull in some client-side dependencies we need. Of course, Laravel Echo. Now, like many things with Laravel, Echo is not bound to any specific implementation. So, by default, we're going to use Pusher, and that's probably the most common, but you could set up any kind of broadcaster that you want. There we go. And also, I'm going to boot up my watcher, since we're now going to switch over to our JavaScript. Okay, we'll go into Resources, Assets.js, and if we go to Bootstrap, yeah, here's the default stuff you get with Laravel. We pull in some dependencies,

over to our JavaScript. Okay, we'll go into resources, assets.js, and if we go to bootstrap, yeah, here's the default stuff you get with Laravel. We pull in some dependencies, but then at the bottom, you'll see the section for Echo that you can comment out if you need to. Let's see what's happening. We're importing Pusher.js. You can use the import syntax as well. I think Taylor's just doing that so that you can immediately assign the results to Pusher, but you probably should switch over to import. Finally, we're creating this new object on window. window.echo equals a new instance of Echo. We're specifying the broadcaster as Pusher. Think of that sort of like the driver. We need our key. Okay, now there are ways with Laravel Mix, which is what we're going to use to compile this, to read our .env file, but let's just keep it simple just in case you're not using that. So, I will hard code that. This

Minx, which is what we're going to use to compile this, to read our .env file, but let's just keep it simple just in case you're not using that. So, I will hard code that. This is a public key. There's nothing dangerous about it. The cluster is still MT1. That's east coast US. You would, of course, use something else. So, anyways, if I save that, it's going to compile down. The next step is within our project. So, again, I'm just using a default install where we get that welcome page. That's okay for now. Let's pull it in. JS app.js. So, we've compiled all of our JavaScript down to the public directory, and I'm now going to load that file. Next, we need something that will dispatch an event. We're going to simulate something taking place that the user is not aware of. So, why don't we add a new route here, and we'll say if update, you know, some kind of route just to give us a location to dispatch this event,

place that the user is not aware of. So, why don't we add a new route here, and we'll say if update, you know, some kind of route just to give us a location to dispatch this event, and we'll grab that and paste it in. All right, does that make sense? So, now when you load the home page, we'll give that a refresh. We're not really doing anything at the moment, but we are loading our JavaScript, and we have pulled in echo, our wrapper. We've pulled in pusher, and then we've created a new instance of echo. So, if we were to say window.echo, we can see that there. But, actually, real quick, one thing that we will need and that Laravel Echo will expect is access to the CSRF token, and it will do this by looking for a meta tag. So, let's go here. Now, traditionally, this will probably end up being your layout file, but for now, we're just going to hard code it here. So, we'll say <meta name="csrf-token" content="{{ csrf_token() }}">.

traditionally, this will probably end up being your layout file, but for now, we're just going to hard code it here. So, we'll say meta name equals CSRF token, and the content is CSRF token. So, we're just giving Laravel Echo a way to track down our CSRF token. So, if we come back and give this a refresh, we should no longer see it. We'll just see the standard views trying to bind to an element called app, but it can't find it. Why don't we just do that here? Refresh. There we go. Anyways, though, at this point, nothing has been dispatched. So, if I come back to Safari and to pusher, we're going to clear that out, and as many times as I refresh this, nothing's happening. You can see connections being made, but no messages are coming in because we haven't dispatched or broadcast an event. That's our next step. In a new tab, we'll visit that update endpoint. So, now, it did dispatch an event to pusher, and we can see that right here.

haven't dispatched or broadcast an event. That's our next step. In a new tab, we'll visit that update endpoint. So, now, it did dispatch an event to pusher, and we can see that right here. The order with an ID of 5 was updated behind the scenes. So, now, let's think about it. On this side, we just need some way to show that we have received that event. We have heard it. So, let's come back to code. In the bootstrap, we'll start right here, and again, we'll slowly expand things out to a bit more real world of an approach. window.Echo. Now, what channel are we going to listen on? Well, you'll remember in orderStatusUpdated that, a bit naively again, we're just broadcasting publicly. So, the channel name is called orders, and I say a bit naively because, remember, if this is related to a user's order status, why are we broadcasting it to the world? That's really a private channel. That should be a walkie-talkie communication, right?

because, remember, if this is related to a user's order status, why are we broadcasting it to the world? That's really a private channel. That should be a walkie-talkie communication, right? And that's why we still have this section down here. We're going to review that very shortly, but for now, it's still public. Okay. So, the channel is called orders, and we're going to listen for an event. And in this case, it's called, by convention, it's going to use the name of the event. So, we can say, listen for OrderStatusUpdated. Now, it's actually going to use the full class path. So, App\Events\OrderStatusUpdated. But one of the conveniences that Laravel Echo provides is it will assume that namespace of App\Events. You can change it if you want to use something else entirely, but in this case, this is perfect. So, now, what should happen when that event comes through? Well, to start, we just want a proof of concept. So, I will say,

use something else entirely, but in this case, this is perfect. So, now, what should happen when that event comes through? Well, to start, we just want a proof of concept. So, I will say, orderStatus has been updated behind the scenes, and then we will also log the event. All right. So, some reformatting, and I'll let you take a look at that. Instantiate Echo. Listen on the orders channel, which is the only channel that we are broadcasting on at the moment. And specifically, if a new orderStatus update comes through, we're just going to log something to the console. Okay. So, that should be compiled down. Let's start from scratch again. So, I'm going to clear this, give it a refresh, and now we have our connection. Let's next hit an endpoint that will trigger some kind of behind-the-scenes broadcast. There we go. So, if we come back, we fired this event. So, now, if we come back to the original tab, there you go. orderStatus has

will trigger some kind of behind-the-scenes broadcast. There we go. So, if we come back, we fired this event. So, now, if we come back to the original tab, there you go. Order status has been updated behind the scenes, and you'll see that the event data contains the order. So, that means here I could say the order status with an ID of, just use basic string concatenation here, e.order.id has been updated behind the scenes. Okay. So, let's do it one more time, but I'm going to do these side by side so you can see it. Okay. So, once again, we'll refresh. We're now going to hit an endpoint that triggers an update, and immediately back on this tab, this user, who could be anywhere in the world, immediately receives an update that the order with an ID of five has changed. Now, again, in this case, we're just logging it to a console, but in real life, you're probably updating the UI in some way. Maybe you're appending to an order

with an ID of five has changed. Now, again, in this case, we're just logging it to a console, but in real life, you're probably updating the UI in some way. Maybe you're appending to an order state table or something like that. You're going to append a new item there that says the order is currently pending. And, of course, you would fetch that state off of whatever order object you were broadcasting there. All right. So, I hope you're starting to get a little more comfortable here. We're keeping it as basic as we can, baby steps, so that we can work our way up. But now, we're using Laravel Events, along with the server side Pusher SDK, to broadcast these events all the way up to Pusher. Then, on our client side, we're also pulling in a Pusher client side library, and then Laravel Echo, which just wraps around it and gives us this nice API that we can use. That way, we can say, here's the channel, here's the event I want to listen to,

client side library, and then Laravel Echo, which just wraps around it and gives us this nice API that we can use. That way, we can say, here's the channel, here's the event I want to listen to, and when it comes in, here's how I want to respond. So, you can imagine if you have a view component, well, there, maybe you would append to some items within your view component, something like that. And we'll review a lot of examples just like that to make you as comfortable as possible. So, stay tuned.