Hacker News Reader

Comment by recursivedoubts | Hacker News Reader

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/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/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

View on HN

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.

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-s...

>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.

yeah i prefer just plain ol' if statements, i find them easier to debug

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.

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.

Reply on news.ycombinator.com