4 ms·
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 peopl
by 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 agoIt 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.