3 ms·

> The default queuing mode is bonkers > By default, Htmx will cancel requests that are in-flight if you trigger another request on the same queue (element). T

> The default queuing mode is bonkers > By default, Htmx will cancel requests that are in-flight if you trigger another request on the same queue (element). This seems like the only default that's reasonable to me don't know if the author has a specific example in mind, but if a user submits an input, changes that input mid-request and submits again the request needs to be cancelled, otherwise the UI will be inconsistent by showing a response to an outdated input Just processing one response after the other won't be possible if a response swaps out content with different IDs, so a second response won't be able to be swapped out in the same way

naasking 2y ago
> don't know if the author has a specific example in mind, but if a user submits an input, changes that input mid-request and submits again the request needs to be cancelled, otherwise the UI will be inconsistent by showing a response to an outdated input If you queue them and process responses in order, that would also be correct. Probably has fewer failure modes. Some indicator that an element is still being processed would help to prevent user confusion though.
- sauercrowd 2y ago
  This won't work if a response is meant to swap out a div, the first response completing will swap it out - if this response isnt compatible with the same selector (e.g. a #response is not available) a second completing response won't be able to update the UI
  - naasking 2y ago
    There are many choices here, such as never setting outerHTML but only innerHTML/nested content. Also, "processing responses in order" doesn't necessarily mean "immediately mutate DOM for each response", eg. defer if there are in-flight requests and aggregate changes. htmx arguably gives you too much flexibility which is why there are no straight answers that work for all scenarios.

naasking 2y ago

> don't know if the author has a specific example in mind, but if a user submits an input, changes that input mid-request and submits again the request needs to be cancelled, otherwise the UI will be inconsistent by showing a response to an outdated input If you queue them and process responses in order, that would also be correct. Probably has fewer failure modes. Some indicator that an element is still being processed would help to prevent user confusion though.

sauercrowd 2y ago
This won't work if a response is meant to swap out a div, the first response completing will swap it out - if this response isnt compatible with the same selector (e.g. a #response is not available) a second completing response won't be able to update the UI
- naasking 2y ago
  There are many choices here, such as never setting outerHTML but only innerHTML/nested content. Also, "processing responses in order" doesn't necessarily mean "immediately mutate DOM for each response", eg. defer if there are in-flight requests and aggregate changes. htmx arguably gives you too much flexibility which is why there are no straight answers that work for all scenarios.