3 ms·

By queue only one additional request, do you mean cancel any existing queued request?

recursivedoubts 2y ago
the code is a little gnarly, but if you don't specify anything the default behavior is to keep the "last" event that comes in while a request is in flight: https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56dfe612346d668b37d1a38a24/src/htmx.js#L4210 https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56... and that dumps the existing request queue and puts request created by the last event in it by itself: https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56dfe612346d668b37d1a38a24/src/htmx.js#L4226 https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56... we don't cancel the current request or issue the next request until the current request finishes but there could be a bug in the code, for sure, it's pretty crazy
- dullcrisp 2y ago
  I thought they were complaining that any request is being cancelled by a subsequent one, since they wanted all the requests they made to go through (presumably the requests are altering state?) Probably I misunderstood what was meant by “losing work” though.
  - recursivedoubts 2y ago
    yeah i don't know if I understand what they were saying either regardless if you have a lot of events flying around then updating the UI via hypermedia exchanges is going to be a bad idea, as I mention here: https://htmx.org/essays/when-to-use-hypermedia/#if-your-ui-state-is-updated-extremely-frequently https://htmx.org/essays/when-to-use-hypermedia/#if-your-ui-s...
- angra_mainyu 2y ago
  >https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56dfe612346d668b37d1a38a24/src/htmx.js#L4210 https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56... This seems to be a scenario where switch/case blocks could make the elif-trees a bit easier to read. Also, the code could use some care about not going so deep into the Vs: // request headers if (requestAttrValues.noHeaders) { // ignore all headers } else { for (const header in headers) { if (headers.hasOwnProperty(header)) { const headerValue = headers[header] safelySetHeaderValue(xhr, header, headerValue) } } } could just be: // request headers if (!requestAttrValues.noHeaders) { Object.keys(headers) .filter(hdr => headers.hasOwnProperty(hdr)) .forEach(hdr => safelySetHeaderValue(xhr, hdr, headers[hdr])); } Not even sure if that hasOwnProp check is needed, unless header keys are explicitly set to undef.
  - recursivedoubts 2y ago
    yeah i prefer just plain ol' if statements, i find them easier to debug
- jrochkind1 2y ago
  I had to read and think carefully enough about what you just explained (on second try!) to feel like I understood it, so I'm not at all surprised if other people are confused about or misinterpret what they are seeing! (I'm not an htmx user though). Actually, I guess, then, OP just had an off-by-one error? Imagine requests [r0, r1, r2 ... rN], where r0 is still in flight... OP thought r0..r(n-1) would be cancelled, in fact just r1..r(n-1) will be cancelled (I think?). Or maybe OP understood it but just mis-described it! I am curious to hear the reasoning/use cases for this choice being the default strategy.
  - dullcrisp 2y ago
    It makes sense with GETs if you’re opinionated I think. This way an in-flight request has a chance to complete (otherwise if you send requests too often none of them would ever finish), but any request that hasn’t started yet isn’t sent since it’s meant to be overwritten by the result of the later request anyway. Of course if you expect later requests to do anything other than idempotently replace the previous ones you’ll be surprised.

the code is a little gnarly, but if you don't specify anything the default behavior is to keep the "last" event that comes in while a request is in flight: https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56dfe612346d668b37d1a38a24/src/htmx.js#L4210 https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56... and that dumps the existing request queue and puts request created by the last event in it by itself: https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56dfe612346d668b37d1a38a24/src/htmx.js#L4226 https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56... we don't cancel the current request or issue the next request until the current request finishes but there could be a bug in the code, for sure, it's pretty crazy

dullcrisp 2y ago
I thought they were complaining that any request is being cancelled by a subsequent one, since they wanted all the requests they made to go through (presumably the requests are altering state?) Probably I misunderstood what was meant by “losing work” though.
- recursivedoubts 2y ago
  yeah i don't know if I understand what they were saying either regardless if you have a lot of events flying around then updating the UI via hypermedia exchanges is going to be a bad idea, as I mention here: https://htmx.org/essays/when-to-use-hypermedia/#if-your-ui-state-is-updated-extremely-frequently https://htmx.org/essays/when-to-use-hypermedia/#if-your-ui-s...
angra_mainyu 2y ago
>https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56dfe612346d668b37d1a38a24/src/htmx.js#L4210 https://github.com/bigskysoftware/htmx/blob/1242977d11bebe56... This seems to be a scenario where switch/case blocks could make the elif-trees a bit easier to read. Also, the code could use some care about not going so deep into the Vs: // request headers if (requestAttrValues.noHeaders) { // ignore all headers } else { for (const header in headers) { if (headers.hasOwnProperty(header)) { const headerValue = headers[header] safelySetHeaderValue(xhr, header, headerValue) } } } could just be: // request headers if (!requestAttrValues.noHeaders) { Object.keys(headers) .filter(hdr => headers.hasOwnProperty(hdr)) .forEach(hdr => safelySetHeaderValue(xhr, hdr, headers[hdr])); } Not even sure if that hasOwnProp check is needed, unless header keys are explicitly set to undef.
- recursivedoubts 2y ago
  yeah i prefer just plain ol' if statements, i find them easier to debug
jrochkind1 2y ago
I had to read and think carefully enough about what you just explained (on second try!) to feel like I understood it, so I'm not at all surprised if other people are confused about or misinterpret what they are seeing! (I'm not an htmx user though). Actually, I guess, then, OP just had an off-by-one error? Imagine requests [r0, r1, r2 ... rN], where r0 is still in flight... OP thought r0..r(n-1) would be cancelled, in fact just r1..r(n-1) will be cancelled (I think?). Or maybe OP understood it but just mis-described it! I am curious to hear the reasoning/use cases for this choice being the default strategy.
- dullcrisp 2y ago
  It makes sense with GETs if you’re opinionated I think. This way an in-flight request has a chance to complete (otherwise if you send requests too often none of them would ever finish), but any request that hasn’t started yet isn’t sent since it’s meant to be overwritten by the result of the later request anyway. Of course if you expect later requests to do anything other than idempotently replace the previous ones you’ll be surprised.