Subscribe
Share
Share
Embed
Join me while I learn HTMX and talk at you about it
Twitter: @htmxlabs
So the next request header we're gonna do here is h x trigger, and I'm also gonna include h x trigger name because they're basically the same thing. And they're it's a header that is automatically sent by HTMLX with your request. And it's not sent every time, because hx trigger and h x trigger name, they are only sent if your, element that triggered the request has an ID or a name. So all of these request headers are, you know, they're sent automatically and they're meant to provide context to your server, to your back end code. So you don't need to look at them if you don't want to, but there there may be cases where you do want to.
Lazarus:So the last one we looked at was that h x request, and that was just either set to true or it didn't exist. And that is whether or not the request is an h tmx request or not. So that's sort of the first layer of, you know, checking on something. So you might want to use that as we mentioned to return a partial HTML snippet or to return the full page based on whether it's an HTML request. That's fine, but what if you want to go a little deeper?
Lazarus:So if you really want to know where the request is coming from, specifically which element is triggering this request, that's when you use hx trigger. So an example of that would be like a search or a lookup that filters along a long list of items. So let's say you just have you have a page, you have one route for the page, and you go to the page and it's a long list of items, it has a little filter input at the top so you can sort of find something, But by default you go to the page, it shows everything, loads the full page. Now that's fine. Now what if you want to have it so that as you type it updates which items in the list it's showing?
Lazarus:That's a pretty standard use case. The default way to do it might be to set up a new route that returns a snippet. So you can have, that's probably the first thing I would reach for. It's pretty straightforward to set up a new route and, you know, just return the part of the html that you want to. But for various reasons, you know, you might not want to set up a new route, you might just want to use the same route, you might want to, you might not even be able to set up a new route depending on what your access to the application is.
Lazarus:So another way to do it would be to, okay, you can just check like we did before, is h x request equals true. And if it is, then, you know, this is an HTML request, so it must be that filtering, and so then you just return the rows you want to, or you just return the snippet you want to. That could work fine, but what if, you know, if that's the only thing on the page that's doing this, but what if you want to have multiple places on the page that return different snippets from the same route? So if you're using HX request and just checking if it's an h tmx request, you don't really know which type of request it is. So that's where a checks trigger lets you check which ID the request came from.
Lazarus:So it lets you know the element, with that the the request came from. And it's an id, so and just, you know, I think this can be a little bit of a gotcha, because we're used to seeing HX trigger as a value like click or mouse over or mouse enter or, you know, any number of different events. So this h x trigger, the request header, and eventually the response header, which we'll get to later, but the request header for h x trigger is not an event. It is an element, it is the ID of an element. So in this case, you could check and see, you know, you have this list of items, you're typing, and and as you as you type it's filtering the items.
Lazarus:When it goes to your server, you can see what the ID of that input is. And just because not everybody sets IDs on their inputs, there is also, you know, h t m x has the h x trigger name. So if you'd rather use the name than the ID, because that's sort of the standard for inputs, you can do either one, you know, hx trigger, hx trigger name, whichever one it has will be the one that it sends. So using that you can, branch in your code, so that if you want to say return just the results of that filtering, just your rows in your table, or something like that, you know, and and you want to sort of branch that in the code, and maybe you have other parts of your page and you just have that single route, but you want to check these different headers to see where these requests are coming from. That is a perfectly acceptable pattern.
Lazarus:Htmx, you know, lets you do that, lets you have the control over knowing what it is that triggered this. So, you know, your name for your input might be filter or search, and and you can just check if hx trig if request header h x trigger name equals filter, then, you know, return your response, your return your rows, return your snippet, return, you know, some smaller form, but, you know, you're using in the end, you're using your same route in there. And what that actually also might let you do is is if they refresh on that and you have a search value in there, it would not have that h x trigger or that h x trigger name, so it wouldn't just return, you know, just the rows by themselves, it would return the full page, because those hx trigger and hx trigger name, just like all these other request headers, are not sent, you know, if on a full page request. It's only sent when you're using h t m x for ajax. So, I mean, basically these allow you for branching your logic on your server side based on which specific element triggered the request.