Dynamically change hx-trigger="every <x>s"

[elfjes]

I have a page with autoreload enabled: every x seconds it reloads parts of the page using hx-trigger="every {{ auto_reload_interval }}s" in my backend template. Now I'm trying to have the user modify this autoreload behaviour and set a different interval. This swaps out the element with a new hx-trigger="every {{ new_autoreload_interval }}s". Users may also disable the autoreload, which swaps out the element without the every trigger. The issue I'm facing is that it appears that htmx/js still keeps the previous setTimeout running, which means that there will be an additional reload. This can lead to unexpected behaviour. It may even break the page if it results in two swaps happening at the same time.

Is there any way to access the current timers and/or have htmx clear pending ones?

[Telroshan]

Hey, that doesn't sound normal at all indeed, as htmx is supposed to avoid firing events for an element that has been removed from the DOM in the meantime, see

htmx/src/htmx.js

Lines 2321 to 2323 in 6dbf554

	nodeData.timeout = getWindow().setTimeout(function() {
	if (bodyContains(elt) && nodeData.cancelled !== true) {
	if (!maybeFilterEvent(spec, elt, makeEvent('hx:poll:trigger', {

Could you try adding logs inside a say a document.body.addEventListener("hx:poll:trigger" listener (or a document.body.addEventListener("htmx:configRequest" one) to log the whole event object, just to see what element is firing the unintended periodic request? To confirm whether it's indeed the old, replaced node that still fires requests while it shouldn't, or maybe another node in the DOM that you might have forgotten about?

Hope this helps!

[elfjes]

Thanks, I'll have a look :)

[elfjes]

Alright, after investigation I found the following:

There apparently is a race condition. I have the following setup:

• I have an element (ie the div) that has an hx-trigger="every 5s"
• I have an input element (ie the select) that fires a request to change said trigger to a different value (or disable altogether). The response swaps out the div with a different hx-trigger

Now consider the following:

1. I change the refresh interval using the select
   • Depending on the network, this request might take a while
2. While this request is in flight, the div triggers and fires a request
3. Request (1) returns and swaps out the div. So far so good.
4. Request (2) returns, tries to swap out, but the original div no longer exist.
   We get a swapError parentNode is null inside handleAjaxResponse.doswap, caught here:

htmx/src/htmx.js

Lines 4862 to 4865 in 6dbf554

	} catch (e) {
	triggerErrorEvent(elt, 'htmx:swapError', responseInfo)
	maybeCall(settleReject)
	throw e

This is not handled properly, and certain things may break, such as failure to remove any htmx-request classes, which cause my loading spinners to stay in place.

[Telroshan]

Ok I see the issue!

I would say this works as intended (regarding throwing an error in this case).
What you'll want to do in this exact situation, is likely to use hx-sync to synchronize those 2 requests on the same element, and make it that your select's request should abort any ongoing request triggered from the every spec.
In other terms, you'll want to avoid the requests from happening simultaneously at all, rather than fixing it at the error-catching level.

Didn't test it, but I think you could for example set a hx-sync="#parent:replace" on your select (using a parent element here that won't be swapped so the syncing properly works on the same element - note that you could also sync on the select itself if it doesn't get swapped, it's up to you here!), and a hx-sync="#parent:abort" on the div that defines the every trigger

Hope this helps!

[elfjes]

Thanks, I'll have a look at that :)