however, i allow the users to add notes to their responses, and these notes are all edited with a single modal dialog div that i overlay on the page while they are editing it.

to get this to function correctly, on that modal div, I do a "modalForm.setAttribute('hx-target' and 'hx-select' in the modal dialog's show eventlistener

in a standard flow, it works great.

however, i have discovered that if the user brings up the modal dialog again for a different div id, while the original one is still htmx processing, it somewhat silently breaks the htmx response.

in the normal flow, after the final "beforeCleanupElement" event, i get an afterSwap.

in the simultaneous flow, it jumps to the afterRequest, and somehow the hx-target and hx-select are already updated to the new IDs.

is htmx actually processing the post to the form by still reading the document's form? All of those values that are submitted in the post are not "locked" during the duration of the post?

actually looking closer at the logs, i can even see when the form changes during the xhr:progress duration.

at one point the hx-target is "#response_185", and then the next progress event it is "#response_192"...

Could you keep the modal on screen until the htmx request has completed? I've got some events on my modals that submit forms where the buttons in the footer are disabled when a request is inflight and only if it's completed successfully does the modal close, that way I can rerender the form with any errors returned from the server, or if its a network error, reenable the button with a toast that something unexpected went wrong and to retry in a moment. That way I can be sure that if something goes wrong the user doesn't lose their form input.

This is the way. Just set up your server to include an

HX-Trigger

response header that tells htmx to close the modal once the round trip is complete. Works marvelously.

that would work, but i was hoping to allow faster queueing of requests and not wait on the response...

well, i found a solution. i'm not sure if it is a "bug" in htmx or rather just a "thing to be aware of"...

hx-target does appear to be baked into the post, however hx-select gets pulled at swap time. so i removed my hx-select since my swapped html was already optimized down to the proper content. and now it works, even though the form gets tweaked mid-replacement.

Another option is to clone the modal before editing the hx- attributes and opening it (since you're already in JS land, not a huge lift), and delete each clone after swap. Well nevermind, you got a solution that works for you

yeah cloning and orphaning would do it too. good idea! 🙂

has anyone built a hx-twillio extension yet?

feels like their lib + the client side template lib could automate most of real time chat setup through them

~~Without knowing the specifics… could the web sockets/SSE capabilities cover this? https://htmx.org/docs/#websockets-and-sse ~~

Well I created an issue in github related to my hx-select issue... I think they could make a nice easy fix that would cover the majority of cases that hit this issue. At minimum documentation of it would be helpful. 🙂 https://github.com/bigskysoftware/htmx/issues/990

How to define custom elements with htmx when we load partials ? 🥺

thanks. i fixed it by adding CORS header on server side.

hi htmx folks! I am new here and currently using htmx and it works almost like a charm. I like it so much, because i don't need a big SPA, but just render all serverside (in rust) and then add some additional things with htmx and alpine.js. However I have a "flickering" UI issue and usually work on the backend side so please forgive me the "lower" level of question: I have a table at the end of a page and a pager at the bottom of the table. Clicking on a different page in the pager, loads the respective newly rendered table from the backend and uses hx-swap="outerHTML show:top". This leads to the issue, that (since the whole table is replaced), I have a scrolling behaviour happening after each page load which looks weird. Is there anything, htmx can do to that or do I have to use some "hacky css method" to keep a container around my swapped one with a somehow fixed size (the table entries are not always of the same height). Any hint or remark on how to generally tackle such an issue would be awesome!

what are you trying to do with that show:top?

the show:top is not really needed, it was my first try to achieve something. If you like, I can do a short screen recording to show the behaviour with show:top and without

By default, htmx shouldn't scroll anything

it should just swap the new content into the dom

jep, but due to the replacing of the table, on small screens i have this scroll / content jumping effect

without show:top i have to scroll down myself