How to use response HX-Trigger to trigger the event on a sibling element?

[renannprado]

I'm trying to send an HX-Trigger and HX-Retarget together to trigger the event in a sibling element.

I know I can annotate an element with hx-trigger="myEvent from:body", however in this case I need hx-on instead, because I need to use javascript in my use case. I've tried to annotate with hx-on:open-on-dialog="alert('asd')", hx-on:from:body:open-on-dialog="alert('asd')" and hx-on::open-on-dialog="alert('asd')", but none of these worked.

The only thing that worked was to annotate a parent element.

So how can I do it? Is there a way to use hx-on with HX-Trigger response header regardless of where the element is.

[Telroshan]

Hey, hx-on is equivalent to calling addEventListener on the element that you put the attribute on, so it cannot be listening "outside" as hx-trigger does. In this case you indeed want to put the listener on the element that will receive the event, be it the body if you need a from:body equivalent.
When your client logic gets specific enough, it may be worth considering using a simple script of your own and calling addEventListener in it!

And if you really want to stick to hx-on, I imagine a dirty trick could be declaring a hx-on on the parent (that receives the trigger header), that queries all of its children and fires another custom event of yours on them, which would then be listened on by these children using also hx-on but with this other custom event... dirty as I said

[renannprado]

I see what you mean, I think I still lack some knowledge on how the events are propagated, but it makes sense.

I went with putting the listener on a parent element, which works just fine.

But I'm wondering, when you have HX-Trigger + HX-Retarget in the response, would it be fair to expect HTMX to:

document.querySelector("<HX-Retarget value>").dispatchEvent(<HX-Trigger>)

What do you think?

[Telroshan]

Given that HX-Trigger is meant to trigger an action on the target element, I would indeed expect the HX-Retarget to take precedence over HX-Trigger and have the latter fire after the first one...
This would cause retro-compatibility issues if it were to change now though 🤔 we'd have to implement another header for that I'm afraid

[renannprado]

I can understand.

Does HTMX have a strategy for breaking changes? I mean, nobody wants to have breaking changes, right? But sometimes it is necessary. Does HTMX use semantic versioning or (as an idea), can we have a new configuration flag, that would serve a smooth path to opt in for new behavior until the old behavior can be removed? Like "mark" this behavior to be changed permanently from version x.y.z...?

[Telroshan]

The only breaking changes occured with htmx 2, that changed some defaults (and we made a retro compatibility extension that reverts those defaults for an upgrade as smooth as possible).
It's very unlikely at this point that there will be any htmx 3 in the future as we'd like to make no more breaking changes anymore (but you never know ofc)
An opt-in option also make sense of course! The idea to keep in mind is simply that the update shouldn't break any existing setup, so either a new Header or an opt-in configuration property that changes the behavior is fine. It's really up to the functional needs of this feature, if it's very unlikely that someone would want both behaviors in a same app (in some places, apply the trigger before retarget while it should apply after in other places), then an opt-in option to change the behavior probably makes more sense than a separate header indeed.