In this episode, we're going to look at refactoring the code that deals with the delivery of our real-time messages. That's because in Laravel 11.5.0, anonymous broadcasting was added. Now, anonymous broadcasting allows us to broadcast a message from the backend to the frontend without having to create an event class to handle that for us. Anonymous events are handy, particularly if we need to hook into that event in other ways with listeners, but if we just want to broadcast our event directly to the frontend, we may not actually need to create an event class at all. Using this syntax, broadcastOn, we can instantly send a message from the backend to our frontend. The place in our existing codebase where we want to refactor to use anonymous broadcasting.

Using this syntax, broadcastOn, we can instantly send a message from the backend to our frontend. The place in our existing codebase where we want to refactor to use anonymous broadcasting is the send method on our Channel model. This is the method which takes the message from a User, stores it in the database against the channel, and dispatches the event to all connected users to deliver that message in real-time. Right at the very bottom of this method is where we dispatch our event. We're not actually using this event in any other way in our application. We have no listeners hooking into this event and carrying out any further actions. We're only using it to broadcast messages to users on the frontend.

We have no listeners hooking into this event and carrying out any further actions. We're only using it to broadcast messages to users on the frontend. To refactor this event into anonymous broadcasting, we're going to want to use the broadcast facade. The broadcast facade gives us a private event, and all we need to do is provide our channel name, which in this case is channels. and the ID of the channel. When using anonymous broadcasting, we could dispatch this exactly as it is now, but the event name Laravel would use is anonymousEvent. The frontend of our application is listening for an event called messageSent. To ensure that continues to work correctly, we can define the name of our event using the as method.

To ensure that continues to work correctly, we can define the name of our event using the as method. Now, Echo on the frontend is listening for events on the appEvents namespace because that's typically where our events are stored in our Laravel application. We're going to go ahead and type that, appEvents, and then provide our actual event name, which is messageSent. The frontend is also expecting some data to be broadcast with this, so in order to do that, we can use the with method, and the with method accepts an array. Now, our event dispatches this using a property called message, which is our Message model. We can pass that through using the key of message, passing through our newly stored

Now, our event dispatches this using a property called message, which is our Message model. We can pass that through using the key of message, passing through our newly stored Message model, and we're going to go ahead and load the User who sent that message. And finally, to dispatch this event to the frontend, we're going to chain the send method. With that change to our code base, we can go ahead and delete this line where we dispatched the event. We can actually go one better than that, and we can go ahead and delete the event entirely. Back in our browser, you can see we're logged in side by side as two different Users. Just to prove we haven't broken anything with this refactor, let's just make sure our messages are still being delivered.

Just to prove we haven't broken anything with this refactor, let's just make sure our messages are still being delivered. So I can go ahead here and say, hey, and that message is delivered to other users. And if the other users want to reply and say, what's up? That message is also delivered, as we would expect.