It goes without saying, but I'm going to say it anyway. Our modern web applications rely upon client-server communication. I said it goes without saying, and most of the time we are more concerned with the client-to-server communication because our clients request data from the server, which responds with the data that we requested. But a lot of times the server responds with data that the client needs to respond to. You know, we can think of this like a server-sent event, and HTMX has the ability to essentially do that, send events that would be handled on the client.

and HTMX has the ability to essentially do that, send events that would be handled on the client. We would call this a trigger. Now, before we begin, let me first of all say the code that we are going to have here is going to work. It's going to be fine. The example will leave a lot to be desired because I don't really have a good reason to use this particular feature, at least as far as what we currently have. If we expanded upon this application and just built it out, there's plenty of places where we could do that. Not so much here.

If we expanded upon this application and just built it out, there's plenty of places where we could do that. Not so much here. So just bear with me. The example is going to be eh, but the code is going to work fine. So essentially what I want to do is whenever we return an HTMX response, I also want to be able to add a trigger. Now a trigger is just a name. So we're going to have the name of something special. I said, it's going to be eh. So this is the trigger that we want to essentially execute on the client.

it's going to be eh. So this is the trigger that we want to essentially execute on the client. So we need to include this trigger with the response. So we do so with a header called HX-Trigger. So let's define that addTrigger method. We will have the name of the trigger that we want. And we also want to keep track of this kind of like what we did with fragments. So let's do this. We will have a protected string value called trigger and we will initialize it as an empty string so that inside of addTrigger,

We will have a protected string value called trigger and we will initialize it as an empty string so that inside of addTrigger, we could say this trigger equals the name of the trigger that we provided. And then we will return this so that whenever we prepare the response, we will call the header method. We will set HX-Trigger to whatever our trigger is. So pretty simple and straightforward. Let's go ahead and just refresh the page. Everything should work anyway, but let's refresh. Let's pull up the developer tools. Let's go to Network and let's make a request.

but let's refresh. Let's pull up the developer tools. Let's go to network and let's make a request. So here we have our request for the open endpoint. Let's take a look at the headers. So our response headers, there it is. We have HX-Trigger and then the value is something special. So this means that on the client we can listen for that event. So I'm going to open up list.js. This is where we defined that InvoiceList Alpine component. And we are going to listen for that event using document.addEventListener,

This is where we defined that invoice list Alpine component. And we are going to listen for that event using document.addEventListener, something special. And then we just need our handler, which I said, it's meh. We're just going to alert. We received something special. So with that in place, we can go to the browser. We can make a request here and we're going to see our alert box. Say we received something special not to prove that this didn't happen just because let's listen for something else, something special too. And if we make a request, we can see that the request is made, but of course that alert box doesn't show up. So yes, of course,

And if we make a request, we can see that the request is made, but of course that alert box doesn't show up. So yes, of course, because the HX trigger header included that value of something special that triggered that event here in the browser so that we can listen for it and we could do something whenever that happened. And that's great. But most of the time we want extra data to go along with that event. Yes, there are times when all we care about, did this event occur? Then fine. But most of the time we want some extra data and we can provide that extra data with our HX trigger. In fact, we can have multiple triggers in that response. The only thing is that the header needs to return a JSON structure that has all

with our HX trigger. In fact, we can have multiple triggers in that response. The only thing is that the header needs to return a JSON structure that has all of those events that we essentially want to listen for. So that means we're going to need to change this implementation so that first of all, our trigger property is actually triggers and it's an array which we will initialize here. And then inside of the addTrigger method, we still need the name because that is the name of the trigger that we are going to listen for. But then we might have an array of data, but let's initialize this as null because not every trigger is going to have data.

going to listen for. But then we might have an array of data, but let's initialize this as false because not every trigger is going to have data so that we can now add our trigger with the provided data and that's going to be just fine. So that's inside of the prepare method. Whenever we set this HX trigger header, we will then json_encode this triggers so we can go back to our InvoiceController and let's add another trigger. But in this case, we're going to have some extra information. Like let's say that we have not a message, but something else and the data for this trigger is going to have a message

Like let's say that we have not a message, but something else and the data for this trigger is going to have a message property to where we would say something else happened. And if we needed to include anything else like for whatever reason, an ID, we could do that. So now let's go back to the browser. Let's pull up the developer tools and let's make a request. So let's inspect this so that we can see the response. We can see now our HX trigger header is now a JSON structure, but it is an object. And that is important here. If you want to send multiple triggers,

but it is an object. And that is important here. If you want to send multiple triggers, it needs to be a JSON structure of an object, not of an array. So just keep that in mind because it is going to look at the keys of this object and any one of those keys are going to be the events that are going to fire inside of the browser. So we have something special, which we are already listening for, but now we also have something else to listen for as well. And since we already had the event listener set up for something special, we still see that message, but let's do this.

And since we already had the event listener set up for something special, we still see that message, but let's do this. Let's go back to our JavaScript and let's listen for the somethingElse event. I'm really sorry. I really had no good idea to use here. So we're going to listen for somethingElse and we want that data to work with. So what we can do is alert. You'll use the event object. It's going to have a detail property. And then I think we can just use message here. We might not. We'll see here in a second. So let's go back to the browser. Let's make our request. We see that message.

We'll see here in a second. So let's go back to the browser. Let's make our request. We see that message. So let's go back to the browser. Let's make our request. We see that we received something special and then we see something else happened. So yes, I was correct. So the data from the something else trigger is from inside of the detail property. So that means we can also check the ID here. So if we make another request, we see the ID of one. So that's great. It's really a simple concept. We just need to have a really good reason to use it. Um, you know what?

It's really a simple concept. We just need to have a really good reason to use it. Um, you know what? Let's do this. Let's open up the list view because we can use this to dynamically load content. I mean, before we used an out of band update, which worked just fine, but we can also use a trigger in that particular case. The only thing is I don't know what I want to change here and really it might make sense to do something inside of the layout, something that is completely out of band. So I guess right here inside of main,

something that is completely out of band. So I guess right here inside of main, let's add a div with an ID of changeContent. We'll add that closing tag so that now whenever we receive this event, we can do this. We'll say document.getElementById('changeContent') and we will set the innerHTML to EdetailMessage. So I have no idea where this is going to appear. So we're just going to keep this here. We will make our request. Yes, of course we received something special and now we see something else happened. So there are many reasons why you would want to use server triggers.

of course we received something special and now we see something else happened. So there are many reasons why you would want to use server triggers. Maybe you want to update content. Maybe you want to take that information and store it in sessionStorage or localStorage. I mean, the possibilities are endless as to why you would want to do so. I just couldn't think of a really good reason for it in this particular case. But anyway, it's very easy to implement and use. So if you need server triggers, that's how you do it.

So if you need server triggers, that's how you do it.