obv i can resolve this

but if this is a bug and not my misunderstanding, then it is somewhat serious

in general I think its very surprising htmx swaps on the wrong element, as opposed tofailing the swap and doing nothing

the latter would be preferable.

it gets wierder, htmx seems tp pick up the hx-target from the body tag, despite the fact that i am invoking the api with an expicit target.

ok I can confirm that if you call the api with an invalid target then htmx defaults to the elements (or parents) target, of the invoking objet)? .. this feels very wrong to me

id expect an invalid target to do no swap and write and error in the console.

humm, it seems related to the second request getting 'queued' while the first request is in flight

am I doing something wrong with this code const settings = { group: 'todo', animation: 150, sort: false, onAdd: function (evt) { htmx.ajax('POST', '/task/update/' + evt.item.id, { target: '#task-stats', values: { status: evt.to.id } }); }, } const sort1 = new Sortable(document.getElementById("notStarted"), settings); const sort2 = new Sortable(document.getElementById("inProgress"), settings); const sort3 = new Sortable(document.getElementById("deferred"), settings); const sort4 = new Sortable(document.getElementById("completed"), settings);

if I move two cards quickly then the second htmx request doesn't even have the values, but the url is correct..

does htmx.ajax return a Promise?

ya I think so

maybe have a loading variable to check if POST in flight

I feel like im just misunderstanding something fundamental

why is the second request getting queued and why is the values and target blank / default

maybe something to do with htmx internals?

ok so the bug seems to be calling htmx.ajax() while the previous call is in flight, the 'context' element gets ignored.

Looks like htmx isn't too shabby for SEO & a11y.

That's funny. I came to the a related idea some days ago too: Why not update only via oob? The browser is like a thin-client in this case. Like a canvas which the server paints on. The client sends an event to the server, and the server decides which parts to update. But up to now this is just an idea in my head. I have no real world experience with this the oob-only way. Except one simple example: the users clicks a "+" button and the current row gets updated, and a total count at the bottom of the table.

I think that's how streams work in the hotwire/turbo library. You return a turbo stream with a specific DOM target (or multiple streams) in the HTTP response or websocket.

where as the turbo drive (the old turbolinks) component just does full page renders with diffing on the body (pretty much like hx-boost)

so a response can update multiple parts of the site in cases where you don't want the full page re-render

I haven't tried it, but my assumtion with hx-swap-oob is that you can do the same thing: server could return a response consisting of concatenated HTML fragments each with their own ID and each one marked hx-swap-oob="true".

This would work well if your server framework can do streamed responses (e.g. Django's HttpStreamingResponse)

so I might have my main chunk of content plus a snippet containing my toast/flash notifications

For me normal stateless http is enough (no need for streaming or websocket at the moment). The server reacts if the client does something. But the oob thing has an issue up to now.

<div>oob1</div> <tr>oob2</tr>

will fail. See: https://github.com/bigskysoftware/htmx/issues/469

Yeah the way turbo-streams does it is with a wrapper like ...

the disadvantage here would be that your server responses would need to be modified to support that (turbo has a Rails gem & other framework packages)

Just thinking about when you want to use hx-push-url for page navigation returning page fragments, but you want to include a change

i.e. instead of whole page swaps/selects