When events are queued, when do values get computed?

[michalc]

When events are queued, when do the values that are sent along with the corresponding requests get computed? When the event (e.g. an "input") is fired, when the event gets to the front of the queue, something else/it depends?

The reason I'm asking is that I'm dealing with a bit of on odd problem. When clicking on a checkbox twice in quick succession, a checkbox that itself gets replaced by the server's response, the second click gets undone in the UI and looking in the network tab the requests made to the server are identical. This is consistent with the form being serialised at the point in time it got to the front of the queue, rather than on the actual click event. Not quite sure what I should do about this if anything, but wanting to at least understand the request/data lifecycle a bit more

I'm on HTMX 2.0.10

[hippi345]

When the request actually goes out, not when the event fires. A queued trigger just stores a closure that calls issueAjaxRequest later, and the form gets serialized inside that call, which runs after the in-flight request's response has been swapped in.

So in your case: click 1 sends A (checked), click 2 is queued (default is queue last), A's response swaps in a fresh checkbox in the server state (checked), then the queued request serializes that and sends the same thing as A. Second click lost.

Simplest fix for a toggle is hx-sync="this:drop" (or hx-disabled-elt="this") plus having the server toggle based on its own state, so two requests means two toggles. Not replacing the checkbox on every response also helps.

[VitorRodi]

This looks like a possible request queueing and DOM replacement race condition.

Since the checkbox is being replaced by the server response, I'd first try using hx-sync="this:replace" to abort the previous in-flight request when a new change occurs.

For example:

<input
  type="checkbox"
  name="enabled"
  hx-post="/update"
  hx-trigger="change"
  hx-sync="this:replace"
  hx-target="#checkbox-container"
/>

This should help prevent an older response from overwriting a newer checkbox state.

I'd also check the request parameters with htmx:configRequest to see whether the checkbox value is captured when the event fires or when the queued request actually starts.

If the problem persists, could you share a minimal HTML example? It would help distinguish request queueing from DOM replacement behavior.