Support for trigger name in `@HxRequest`

[odrotbohm]

When you have a UI that consists of several fragments, that could each trigger an HTMX request, it would be nice if there was a way to disambiguate which element triggered the request without having to resort to additional URIs:

<div>
  <div hx-get="/" name="foo" th:fragment="foo"></div>
  <div hx-get="/" name="bar" th:fragment="bar"></div>
</div>

Let's say I have a controller and would like to handle these requests in separate controller methods, the only way would be to change the template to issue the request to different URIs that pollute the URI space. Alternatively, one would have to manually declare a header condition to the request mapping

@HxRequest
@GetRequest(path = "/", headers="HX-Trigger-Name=foo")
…

However, HTMX sends HX-Trigger-Name headers containing the element triggering the request with it. It would be nice if I could use that name in @HxRequest to constrain the mapping like this:

@Controller
class MyController {

  @HxRequest("foo") // Alternatively @HxRequest(trigger = "foo") or @HxRequest(triggerName = "foo")
  String foo() { … }

  @HxRequest("bar")
  String bar() { … }
}

As the trigger name is pretty core to identifying an HTMX request, I think it's reasonable to default the (still untaken) value attribute to it.

[checketts]

I like this idea a lot!

[wimdeblauwe]

Very nice idea indeed. I also had this issue and I solved it by injecting the HtmxRequest into my controller method:

    @DeleteMapping("/{id}")
    public HtmxResponse deleteContact(@PathVariable("id") long id,
                                      RedirectAttributes redirectAttributes,
                                      HtmxRequest htmxRequest) {
        service.deleteContact(new ContactId(id));

        if ("delete-button".equals(htmxRequest.getTriggerId())) {
        }
        else if(....) {

}
    }

The difference is that I used the id attribute on the <button> element, not the name. This makes me hesitant to use the value attribute on the @HxRequest annotation. I believe it will be clearer to use @HxRequest(triggerName="foo") and @HxRequest(triggerId="delete-button") to support both cases.

[xhaggi]

Good idea. I have created a pull request with the necessary changes.

[odrotbohm]

I am aware I can inject HtmxRequest into the method. That however, then needs all requests to a particular URI be handled by one method. I'd much rather align methods with the individual page elements, potentially even having a controller per element:

// Handles all HTMX request associated with the foo element
@HxRequest("foo")
@Controller
class MyComponentController { … }

What makes this trigger thing odd to me is that there is hx-trigger in the template that defines under what condition a request is issued (the event, basically). The HX-Trigger attribute, however, seems to carry the element's id.

I guess for the server-side implementation, we have to make up our minds at some point how to deal with the fact that HTMX has request and response triggers. The current @HxTrigger seems to cater to the latter, which, I think, is a bit odd as controller method annotations are primarily metadata to map the incoming request.

That said, I wonder if the following approach to attribute aliasing would work:

• triggerId -> HX-Trigger
• triggerName -> HX-Trigger-Name
• value -> HX-Trigger first, HX-Trigger-Name second

WDYT?

[xhaggi]

I guess for the server-side implementation, we have to make up our minds at some point how to deal with the fact that HTMX has request and response triggers. The current @HxTrigger seems to cater to the latter, which, I think, is a bit odd as controller method annotations are primarily metadata to map the incoming request.

You are right. An exception would be @ResponseBody. We could think about prefixing all response-related annotations with Response, e.g. @ResponseHxTrigger, @ResponseHxRefresh or we could drop the annotation support to set the htmx response headers. Then you have to do everything via the return type HtmxResponse, which is the better approach anyway, if you ask me.

That said, I wonder if the following approach to attribute aliasing would work

It should work and I'm fine with it.

@wimdeblauwe any opinion on this?

[xhaggi]

Another approach, which is much better than prefixing the annotation with Response IMO, would be a @HxResponse annotation that contains all the response header options. This is aligned with the existing @HxRequest annotation.

@HxResponse(
  refresh = <true/false>,
  triggers = { @HxTrigger("event1"), @HxTrigger("event2") },
  triggersAfterSettle = @HxTrigger("event3"),
  triggersAfterSwap = @HxTrigger("event4"),
  redirect = "<URL>",
  ...
)

[wimdeblauwe]

I have created https://github.com/wimdeblauwe/htmx-spring-boot/issues/81 to discuss the response headers separately from this request from @odrotbohm . Because I think we can implement support for the trigger name/id without a breaking change so it could be added to the 3.1.0. For the other discussion, please add your thoughts to the linked issue.

[wimdeblauwe]

@odrotbohm For:

value -> HX-Trigger first, HX-Trigger-Name second

Any idea how that can be implemented? The linked PR currently does not support it, so if you could add it, that would be great.

[xhaggi]

I updated the PR to support it.