https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • g
    Hey @User I just updated the preload extension to allow you to override the events that it listens to and defaults this list to 
    mouseover
    , and 
    touchstart
    . It now also works with 
    preload="load"
    so that you can have an HTML fragment loaded automatically when the page loads.
  • m
    @User do you know if the browser will be smart about using the cache? e.g. if a prefetch has been done then a click occurs, then the prefetch finishes, the click will immediately use the newly cached result?
  • g
    In all of my (manual) testing, yes. And, in everything I've read, resources loaded via xhr are treated identically to ones loaded from the HTML itself.
  • g
    I guess we could try to do more digging about resources that take a long time to load. For instance, I mouseover something, then immediately click to load (after, like, 5ms). If the resource takes 500ms to load, it's conceivable that the browser might trigger two requests, because the first request hasn't been written into the cache, yet.
  • g
    I'm not saying that's how it works. Just that I don't know for sure, and it's plausible that it might work that way.
  • g
    I'll do more digging to see if I can clarify.
  • m
    excellent
  • m
    if this works, it's beautifully simple
  • m
    and involves no changes to htmx core code, and i'm not going to lie, i'm going to feel pretty damned smug about the extensions mechanism
  • g
    You can be smug now.
  • g
    And, you can be smugger when we add more extension points to take advantage of.
  • g
    FWIW, one of my goals is to be able to reproduce 
    hx-boost
    as a pure extension. It shouldn't be too hard, give a few more abilities. And, whether or not we actually do it, it would be a good test of what's possible with extension code.
  • g
    RE: caching -- At least for Chrome, it looks like multiple requests to the same resource (even ones in-flight) are not duplicated, but result in a single network request. See: Chromium Docs (https://www.chromium.org/developers/design-documents/network-stack/http-cache) under the bullet point "Enforce the Cache Lock"
  • g
    Browsers are made by some very serious developers, so I'm glad to see that they've already thought of this basic use case.
  • m
    well, chrome is the internet, so...
  • m
    > The cache implements a single writer - multiple reader lock so that only one network request for the same resource is in flight at any given time.
  • m
    😑
  • g
    \*Cries in Firefox\*
  • g
    But yeah, I'd be pretty surprised if other browsers handled it differently.
  • a
    Merry Christmas from Germany! It’s just past midnight 😁 @gorgeous-ghost-95789 adding the flexibility in the event listeners is awesome! I’ve got some more ideas which I got from looking at what the guy from https://instant.page did (eg perhaps adding a slight delay between when mouseover is fired and doing the prefetch, to have a better chance that the intent is indeed to click the link, thus reducing unnecessary server load,etc), but really these are just icing on the cake. I’ll comment on GitHub further.
  • a
    Like @gorgeous-ghost-95789 said: smug away sir! You are fully entitled to wearing a t-shirt that says: “👆pretty damn awesome” 😁
  • g
    Hey thanks, @User I'm checking it out. The additional triggers (like viewport and delayed loads) are pretty interesting. We can build additional intelligence into the extension as we go forward with the extension.
  • g
    I found one more thing that might be an issue, depending on how you're using htmx. Since the extension is just using its own xhr (and not the function used by htmx) we're not sending any htmx headers. This might affect server responses. I've written up a note here: https://github.com/bigskysoftware/htmx/pull/273#issuecomment-750562215
  • m
    @User yeah, and what about things like 
    hx-confirm
    etc.
  • m
    @User mentioned something like this in a DM:
    Copy code
    hx-preload="mouseclick"
hx-preload="mouseover delay:50ms"
  • g
    The delay could definitely be implemented right now.
  • g
    As for hx-confirm, the way it is now, it only preloads GET requests. So, I’m theory, you should be able to preload those regardless of the confirm dialog.
  • m
    well, you can still toss a 
    hx-confirm
    on a GET
  • m
    although you kind of get what you deserve
  • g
    Yes. I was typing that.
1...108109110...1146Latest