https://htmx.org logo
Powered by
# htmx-general
  • m
    I see what's going on here.
  • m
    The old behavior was "wrong" but worked for this case.
  • m
    lemme think
  • a
    Me -> 
    can of wurms
    😬
  • m
    OK
  • m
    first hot take: we should update 
    htmx.find()
    to include the root element
  • a
    Hmmm... you sure? It feels like maybe I'm just looking for a quick find-and-replace" solution, where instead I should just embrace the htmx way and change the old behaviour inside the "init" type methods?
  • m
    what code are you using to find the element?
  • a
    It makes a lot of sense the htmx.onLoad gives you the element that got loaded.... instead of the root element who got stuff loaded inside of it
  • m
    yeah, I think the htmx.onLoad() logic is correct, it's just a pain to work with in this case
  • m
    I never liked the root node distinction in querySelector() tbh
  • m
    very body-centric IMO
  • a
    I'm happy... explaining my problem also helped me clarify my own understanding of what's happening and why. I'll just modify the existing logic to work with this behaviour, not a big deal 👍
  • m
    roger
  • a
    Fyi: adopted my init logic to cater for this behaviour and it's working like charm. Barring any major surprises, I'm on track to finish migrating a pretty large app from Intercooler -> htmx ... in record time
  • m
    absolute unit
  • a
    @User / @User 2 questions about the preload extension:
  • a
    1. It seems that the preload requests ended up not passing the hx request headers. Is that right? Doesn't seem to make a difference though on the htmx.org site... it still works as expected?
  • a
    2. I also use the https://htmx.org/extensions/ajax-header extension, so the back-end knows it's an ajax request and thus serves a fragment instead of a full page. The preload extension of course doesn't sent the 
    X-Requested-With
    header though. This means that the click request gets a the fragment, whilst the preload loads the whole page. I guess nothing much to be done about that eh?
  • g
    Watching cartoons with children. Answer more later.
  • g
    right now, it may be an interaction between preload and hx-boost.
  • g
    Preload uses hx.ajax when it detects a hx-get call. Uses regular http otherwise.
  • g
    hx-boost is probably unexpected. Let me know if you need more, and I’ll try to elaborate 🙂
  • a
    Hmm... not quite following that entirely. But I'm not in a hurry 😁 I am using hx-boost on the app's nav as well.
  • g
    Ok, better English this time 🙂 I’m just speculating, because I haven’t really looked into the problem. However, the preload extension tries to do the right thing when it comes to HTTP requests. If it looks like it should go through htmx (because it has an hx-get attribtute) then it uses htmx.ajax() to do the request. If it looks like a regular request (because it has an “href” attribute) then it uses a plain XMLHttpRequest.
  • g
    I didn’t do any analysis of what to do with an hx-boost. So, by default I think it should see the href and treat it as a regular XMLHttpRequest. We’re not trying to see if it’s “boosted”, but it seems like maybe we should.
  • a
    Ok, that makes sense
  • a
    But.. one thing I still don't quite understand... on the htmx documentation site... hx-boosted is being used ... but it still works?
  • g
    Hmmm.. I don’t either. I’m just guessing right now, based on your reports. I’ll need to do some actual work to see what’s happening. On the htmx.org site, is EVERYTHING boosted from the down? We’re only using the preload on the top level navigation. Is it possible that those links are outside of the boosted content?
  • a
    ☝️ from the htmx docs site
1...124125126...1146Latest