Support for trigger name in `@HxRequest` about htmx-spring-boot HOT 9 CLOSED

I updated the PR to support it.

from htmx-spring-boot.

I like this idea a lot!

from htmx-spring-boot.

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.

from htmx-spring-boot.

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

from htmx-spring-boot.

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?

from htmx-spring-boot.

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?

from htmx-spring-boot.

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>",
  ...
)

from htmx-spring-boot.

I have created #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.

from htmx-spring-boot.

@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.

from htmx-spring-boot.