An hx-event extension - does this even make sense?

[bennadel]

As I'm learning HTMX, I'm trying to find the "way" and the "rough edges" to build up a mental model for how HTMX works best. One thought that I recently had was to create an extension, hx-event, that would allow hx-trigger bindings to emit a synthetic event instead of triggering an AJAX request. An example of this might be to emit a close-modal event on the [x] button in a modal window (and then have some parent element listening for this event to handle the closing). This way, it could listen for both the click and perhaps a keydown[key === 'Escape'] event:

<button
    hx-event="closeModal"
    hx-trigger="
        click,
        keydown[key === 'Escape'] from:body
    ">
    Close Modal Window
</button>

Then, presumably, I might have a parent element that is listening for it:

<div
    hx-get="empty.cfm"
    hx-trigger="closeModal"
    hx-swap="delete"
    class="modal">

    <button>....</button>
</div>

This turned out to be harder than I expected because it looks like HTMX doesn't want to allow "naked triggers" on an element. When it encounters an hx-trigger in the DOM with no hx-get (for example), it binds a no-op event-handler, which in turn, seems to prevent any other hx-trigger from being bound to the same node (such as by my extension). So I had to jump through hoops to hide the hx-trigger before node-processing, then re-attach it. All of which makes me think that maybe this (my extension) is just a terrible idea to begin with :D

I know Carson Gross talks about how much the event-system in the browser is helpful, so I'm trying to bend my mind to think about event-based communication. But maybe this particular context is not the way.

The better way might be to just bind the hx-get to the close button and have it respond to both click and closeModalevents. Then, the server could always respond with anHX-Trigger: close-modal` HTTP response header.

Anyway, just thinking out loud and seeing if anyone has any thoughts on "there be dragons" and how to think about wiring up an HTMX application.

For what it's worth, here's my write-up of the extension: https://www.bennadel.com/blog/4803-creating-an-hx-event-extension-for-triggering-events-in-htmx.htm

[Telroshan]

Hey,

One thing to keep in mind is that htmx's core purpose is to handle communication with the server. As such, in a usecase like yours when you want pure client side logic still relying on some htmx syntax, an extension is indeed the right way to tackle this.

The internal API exposes getTriggerSpecs which lets you retrieve the parsed triggers for a given element.
If you look at the code, and you likely already did as you mentioned "naked" trigger, here's how htmx then uses this array, in the simplest way possible:

htmx/src/htmx.js

Lines 2908 to 2912 in 407408b

	triggerSpecs.forEach(function(triggerSpec) {
	// For "naked" triggers, don't do anything at all
	addTriggerHandler(elt, triggerSpec, nodeData, function() {
	})
	})

See how it simply calls addTriggerHandler that... is also exposed by the internal API!

So, you should be able to use both these functions to run your own event firing logic.
The no op handler will still be bound, but as it doesn't do anything anyway, I wouldn't care much about it.

This way, you'd use no magic trick, no workarounds, just 2 functions from the internal API.

Hope this helps!

[bennadel]

@Telroshan unfortunately, it turns out to not be quite that simple. If you look at the code here inside the addEventListener():

htmx/src/htmx.js

Lines 2496 to 2547 in 407408b

	if (eventData.handledFor.indexOf(elt) < 0) {
	eventData.handledFor.push(elt)
	if (triggerSpec.consume) {
	evt.stopPropagation()
	}
	if (triggerSpec.target && evt.target) {
	if (!matches(asElement(evt.target), triggerSpec.target)) {
	return
	}
	}
	if (triggerSpec.once) {
	if (elementData.triggeredOnce) {
	return
	} else {
	elementData.triggeredOnce = true
	}
	}
	if (triggerSpec.changed) {
	const node = event.target
	// @ts-ignore value will be undefined for non-input elements, which is fine
	const value = node.value
	const lastValue = elementData.lastValue.get(triggerSpec)
	if (lastValue.has(node) && lastValue.get(node) === value) {
	return
	}
	lastValue.set(node, value)
	}
	if (elementData.delayed) {
	clearTimeout(elementData.delayed)
	}
	if (elementData.throttle) {
	return
	}
	if (triggerSpec.throttle > 0) {
	if (!elementData.throttle) {
	triggerEvent(elt, 'htmx:trigger')
	handler(elt, evt)
	elementData.throttle = getWindow().setTimeout(function() {
	elementData.throttle = null
	}, triggerSpec.throttle)
	}
	} else if (triggerSpec.delay > 0) {
	elementData.delayed = getWindow().setTimeout(function() {
	triggerEvent(elt, 'htmx:trigger')
	handler(elt, evt)
	}, triggerSpec.delay)
	} else {
	triggerEvent(elt, 'htmx:trigger')
	handler(elt, evt)
	}
	}

Internally, the HTMX is checking to see if there's already an event-handler bound to the elt stored within the getInternalData(). And, if there is one, it skips-over the part where it invokes the handler(). Basically these two lines right here at the top of the highlighted link:

if (eventData.handledFor.indexOf(elt) < 0) {
    eventData.handledFor.push(elt)

If you were to comment-out the second line (where it .push()es the element into the internal data, my call to addTriggerHandler() would work without any shenanigans. But, HTMX does not want this to happen.

This is true even if I'm not trying to use the hx-trigger attribute. If I write an extension that just does this inside the htmx:afterProcessNode:

api.addTriggerHandler(
	node,
	{ trigger: "click" },
	api.getInternalData( node ),
	( node, event ) => {

		console.log( "FIRST Click" );

	}
);
api.addTriggerHandler(
	node,
	{ trigger: "click" },
	api.getInternalData( node ),
	( node, event ) => {

		console.log( "SECOND Click" );

	}
);

You'll find that the SECOND Click is never logged.

Of course, if I didn't want to use the hx-trigger attribute, I would just use the htmx.on() method :D The reason I was trying to piggy-back on the "trigger" concept was so that the dev could use things like from:body and keydown[filter].

But anyway, this we're getting mired in the weeds of how HTMX works internally.

To your other point, I think I'm just trying to figure out where the HTMX boundary is. And where I should just start using Alpine.js (or similar) to manage things. As always, thank you for letting me bounce ideas off of your deep experience.

[Telroshan]

Oh ok I see, thanks for the details @bennadel

To be honest, I looked into it and I'm wondering whether this handledFor thing makes sense at all or not.
Looking at the history, it seems that at the very early stage of htmx, there was a simple .handled check, introduced in 9f9dc5c
Unfortunately, that commit is named "lots of stuff" so it's hard to tell what exactly was the initial intent back then.
Then issues #390 and #392 were opened, and 835436a fixed them.

Though, I don't really know what this handledFor check might be useful for. If I comment out the eventData.handledFor.push(elt) line and run the test suite, nothing fails... So if it has a purpose, it's one that we never added a test case for.

So, just saying, this might totally be ok to remove this check, although I'm totally unsure about that.
If you would like to look into this, please feel free to do so! There's a possibility that we could simply get rid of this check if it doesn't provide anything useful, but that would require some investigations ofc.

[bennadel]

As always, the depth of your responses are exemplary! I don't know where you find the motivation, but I appreciate it.

To be honest, I'm not even sure that my original idea is any good. I think, a big part of me is trying to find a way to push as much of the website mechanics into HTMX as possible. When I was coming from Angular, the answer was always clear: do it in Angular. And, I think I keep trying to model HTMX in my head as the "monolithic solution". Going back to your original comment:

htmx's core purpose is to handle communication with the server

... I think maybe I just need to step more in this direction. Where HTMX is basically just a fancy wrapper around .fetch() (though I know it uses XHR under the hood). And then just use Alpine.js for essentially everything else.

In a broader sense, I'm just really struggling to understand where the "good boundaries" exist.

[iocouto]

…or you could simply use hyperscript.

[bennadel]

When possible, I try to learn one thing at a time. Since I'm still in the process of figuring out how to leverage HTMX, I'd prefer not to also learn a whole new scripting language on top of that. I figure once I understand how HTMX slots into a web application dev flow, I can consider learning another scripting syntax. Otherwise, it's just too much for my brain to sort through and model.

[iocouto]

I totally get it. The beauty of hyperscript, however, is that it’s so English-like, that the learning curve is laughable. For example, in hyperscript, supposing that I have a modal i want to close, which has id my-modal. I can just put a single line of code in a data-script attribute inside the tag of any element I want to use as a ‘close’ button, like this:

data-script=“on click hide #my-modal”

The code is almost self-commenting. You really should have a quick look at it…

[bennadel]

It is fascinating. In Gross' book, he talks a good deal about the capabilities. It's certainly on my list.