Now that we have the ability to have those chats appear in real time, why don't we add emojis. So in this case, we can see them on our screen, but what does it look like to actually receive those events on other people's screens, people who are listening in, and broadcast them in at least a similar way. So why don't we create a new event and then we can start broadcasting that on our Laravel reverb server. So first we're going to say php artisan make:event, and we can call this the EmojiReactionEvent. And I'm just going to clear all this out, so that way we can start off fresh. We need it to implement the shouldBroadcast.

And I'm just going to clear all this out, so that way we can start off fresh. We need it to implement the shouldBroadcast. Now very similar to how we implemented the message, we're going to have again the listeningPartyId, we're going to have an emoji, and then we're also going to have a userId. Now we're going to do something interesting here, where we're going to be able to set a userId for those who are not logged in as well, because we only want to show the emojis to people who are not the person who is sending them. And we can do that by having a unique userId. So in our construct we have our emoji, and we also want to pass in the userId, and set that up here.

So in our construct we have our emoji, and we also want to pass in the userId, and set that up here. And now we can say public function broadcastOn, and what we want to do here is return a new Channel. And that channel we can call the listeningPartyChannel. So we're going to be broadcasting this on the same reverb channel that we used for our messages, and at least the same listeningPartyRoomChannel. And here is where the broadcastAs is important, because now we can set the specific name for this event that we are listening to on this channel. Now we're also going to broadcastWith, and this is just saying when we send the event.

this event that we are listening to on this channel. Now we're also going to broadcastWith, and this is just saying when we send the event back, when we event received and we send it again, this is going to have additional parameters attached to it. In this case, the emoji, because we need to know which emoji someone clicked, and then the userId. Because if you remember back in our MessageEvent, we didn't necessarily need to broadcastWith, because we were already creating the message and saving to the database, we just needed a way to refresh that message. And in this case, we probably didn't even need the message here.

needed a way to refresh that message. And in this case, we probably didn't even need the message here. Now in our show.blade.php, I know that this file has gotten a little bit big, and that's okay because when we start to build things out functionally, it's great to get it working first and then we can make it more beautiful. So there are ways that we could abstract a lot of this and put it into their own separate components, but this just goes to show how we can start with even just one or two files and get something workable up and running. I'm going to use the entangle function to link AlpineJS state, our client side state, with our Livewire state.

I'm going to use the entangle function to link AlpineJS state, our client side state, with our Livewire state. We're going to first initialize a new public userId and maybe some emojis. So what we can do is put those into an empty array for now. Now let's initialize this userId. So in our public function mount, what we can do is initialize an auth check. So we can say if there is no auth check, and in this case if no one has logged in, we want to see if there is a sessionId for this user because we want each user to have their unique sessionId so that we can send that for these emojis to know who is sending them, in this case to know who is not able to receive them.

session ID so that we can send that for these emojis to know who is sending them, in this case to know who is not able to receive them. So if no session exists, has perhaps the user ID is what we can call it, then why don't we set the user ID to a unique ID, and this is specific to php, so unique ID, and we'll set it to user_, and then we can put that into the session. Else, if there is a session that has a user ID already, we want to make sure we grab that user ID. This probably isn't going to happen because this component has already been loaded, but just in case it does, it's nice to have this second check, and then we can say else here we want to set the user ID if they are authenticated to their actual user ID, and we can actually

just in case it does, it's nice to have this second check, and then we can say else here we want to set the user ID if they are authenticated to their actual user ID, and we can actually use this as a shorthand, auth ID. So currently what I created was this emojis client-side array in our Alpine data state, and we're saying when we add an emoji, we're running this function again all within Alpine, but why don't we link this to our Livewire component. So emojis we want to perhaps entangle, and this is saying that the client-side state is going to be synced with the server-side state, and we want to link that to the emojis parameter that we set up here. And now when we add an emoji, we want to push that new emoji into this wire, this Livewire

parameter that we set up here. And now when we add an emoji, we want to push that new emoji into this wire, this Livewire state. So what we can do here, if we take a look at where this is being called down here, we have this addEmoji button. So what we can do here is we're going to add the emoji, we probably don't even need the client-side XY, instead we can just send an event. So now that we're accepting an event in this client-side function, why don't we create a new emoji to then push to this wire state. So we can say, maybe we'll initiate a new emoji, and this is where we can have those

a new emoji to then push to this wire state. So we can say, maybe we'll initiate a new emoji, and this is where we can have those variables because we need an ID for the emoji, and that's where we can set date.now just to be unique for each emoji that is being sent. Again, we have the userID to also help with that. We want to send the emoji, and we'll link that to the emoji that we're pushing in in that event state. And then we have the X event for clientY and clientX. So instead of destructuring it in the button here, now we are destructuring it in the code up here.

So instead of destructuring it in the button here, now we are destructuring it in the code up here. And now we can set this emojis.push to the new emoji and also initialize it in our Livewire component. So wire.we can call this sendEmoji, and we want to add that emoji. Again, we really only want to add the emoji itself. We don't necessarily need to add the event because we want to just be displayed somewhere on the page, and we don't necessarily need the full XY of where it's being initialized from because browser windows can be tricky if some are bigger than others. It's going to look a little weird.

from because browser windows can be tricky if some are bigger than others. It's going to look a little weird. Now, why don't we create this event, this wire:sendEmoji in our Livewire method? So we can set it maybe here, public function sendEmoji, and we do want to receive that emoji from the JavaScript itself. And we can set up a new emoji variable with, we'll say it's an array with the ID, and here's where we can just give it a unique ID. And of course, in our JavaScript, we're using the date, so we could do that here, but unique ID also works. emoji is what we're being received, and then we can set the XY here.

ID also works. Emoji is what we're being received, and then we can set the X Y here. Maybe just for fun case, we can set it to random, maybe like 100, 300, and we'll do the same thing for the Y parameter as well. Now that we have this new emoji initiated, we can send the event. So we can say newEmojiReactionEvent, and we're sending it to this listening party ID, so we're passing that in so we know which event to send it to and to listen from. Sending the emoji and the userID. Let's bring in this emojiReactionEvent, and now we can receive the emoji. And we're going to do this a little bit differently than we did here.

Let's bring in this emojiReactionEvent, and now we can receive the emoji. And we're going to do this a little bit differently than we did here. Of course, we could do this, but we also could use the attribute to listen for the emoji event and then run a function. In this case, why don't we create a new function that says public function, maybe like receiveEmoji, and here's where we can accept that payload from the event. And we just want to make sure that the payload has a userId because here is where we can check to see if it doesn't equal the userId that is on the page. We don't want to receive an event from one that we just sent. Then if that is the case, what we could do here is say this->emojis, and that's the variable,

We don't want to receive an event from one that we just sent. Then if that is the case, what we could do here is say this.emojis, and that's the variable, the array that we set up here, this.emojis, and we can go ahead and set it to the payload of emoji. So while we're listening to this public real-time event, we only want to accept this and add it to the server and entangled client-side state if it's one that someone else sent, one that's not equal to the userID on our page. So now we have this event listener that we can send here at on, and we can send echo listening party.listeningPartyID, and here's where we have that comma emoji reaction.

listening party dot listening party ID, and here's where we have that comma dot emoji reaction. And let's bring in this attribute up here. So use Livewire attributes on, and looks like we have a maybe a missing semicolon. So let's take a look here. And yes, and then I have a stray curly bracket there. All right. So why don't we bring up the page on both sides so that we can see how this new event for the emojis now works for across different browsers, across different client-side states. So we both have joined the listening party.

for the emojis now works for across different browsers, across different client-side states. So we both have joined the listening party. We're ready to go. And so if I was to send an emoji over here, and looks like something isn't set up properly, let's make sure we are broadcasting it effectively. So in our sendMessage, we have this sendEmoji. We have event NewEmojiReaction event, and we're not actually broadcasting the right variable here. So we have this newEmoji that we need to broadcast there. So now that we're broadcasting the proper emoji, and looks like we still have one more

So we have this new emoji that we need to broadcast there. So now that we're broadcasting the proper emoji, and looks like we still have one more typo undefined variable pay. And there we go. And one more time. There we go. So real-time broadcasting has been initiated for both chat as well as emojis, where even if you're logged in or not, you can go ahead and send an emoji that gets broadcast to the page. But we can also chat as well with other authenticated users.

But we can also chat as well with other authenticated users.