https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • e
    @late-king-98305 Thanks. You wouldn't happen to know of a document that describe, in high level terms, how htmx works under the hood. I tried setting a breakpoint on a dom element, but it was hard to follow the htmx code. I thought htat might be a good place for me to figure this out – by following how htmx resolves it's attributes and turns them into actions.
  • l
    I'd start with https://htmx.org/docs/#debugging which describes some techniques you can use. It also references loading the unminimized version; which might be easier to follow if you're wanting to dig into the internals.
  • e
    @late-king-98305 Perfect, thanks Daniel!
  • a
    I'm not entirely sure how to tackle this one. I have a 
    <form hx-get="blah" hx-target="#content">
    inside the 
    #content
    div. The API response seems to be working fine. The client gives me this :
  • l
    That unminified version should be at https://unpkg.com/htmx.org/dist/htmx.js - I don't think it's linked from the debugging docs.
  • a
    Thanks !
  • l
    Oh - you're welcome to use that too... That was for @eager-city-40681 . In your case, I'm not sure. I would think that for even a malformed payload, it would throw a nicer error. That being said - the unminimized version would have better function names in the stack trace. 🙂
  • a
    Yeah, the trace is a little more handy, but uh...
  • a
    ( great coincidence having that link to the unminified stuff )
  • l
    Does your payload have any triggers or other things that would require evaluating script?
  • a
    The 
    get
    is intercepted with a pretty basic 
    configRequest
    :
    Copy code
    javascript
    document.body.addEventListener("htmx:configRequest", function (event) {
        event.detail.path = "/html/maps/" + document.getElementById("callsign").value;
    });
  • l
    Do your dev tools show what's coming back from that? Since this is being thrown during the settle phase (bottom of that stack trace), you should be able to see the request and response in the Network tab.
  • a
    The response looks just fine, at a glance. The client in the Network tab is seeing the same response as the server seems to be sending
  • a
    I imagine having two 
    script
    tags one after the other is not a problem ?
  • l
    It shouldn't be. Thinking....
  • a
    Copy code
    html
<div id="map_layer" class="h-96" style="border-radius: 10px;"></div>

<script>
    form = document.getElementById("form_maps");

    document.getElementById("look_up").addEventListener("keypress", function (event) {
        if (event.key === "Enter") {
            form.submit(event);
        }
    });

    document.body.addEventListener("htmx:configRequest", function (event) {
        event.detail.path = "/html/maps/" + document.getElementById("callsign").value;
    });
</script>



<script>
        var map = L.map('map_layer').setView([47.67, -122.4], 8);
...
  • f
    Solution to my own question 😅 adding 
    hx-include="this"
    isolates the duplicated form to ignore the other identical form state
  • l
    I wouldn't think that htmx would be evaluating that as script - but I'm wading into an area in which I don't have a lot of experience. Your payload is probably useless without the script tags, but you might try taking them out of the return value just to see if that's what's causing the htmx error. (assuming that's something that you could easily do; it wouldn't be a fix, just a debugging step)
  • a
    Let me try pulling the second script.
  • a
    I think that might be it. Let me look more closely to make sure this response is correctly-formed...
  • a
    Looks like my Leaflet pieces that are being built server-side might have syntax issues
  • a
    Ah, the response contains 
    "
    instead of 
    "
  • a
    Fun stuff...
  • a
    Escaping is not working. Hmmmmm 😄
  • l
    Escaping is always the right decision - except when it isn't... 🙂 The server-side software tries to keep us from shooting ourselves in the foot, but it usually just ends up replacing the real bullets with blanks.
  • a
    Cool, I'll see what I can do, maybe there's a "don't escape this stuff" setting in my FastAPI response. Thanks a bunch, super helpful !
  • l
    Glad I could help.
  • a
    Quick and dirty solution is to 
    autoescape=False
    on Jinja2's 
    Environment
    . Will have to scour for collateral damage 😛
  • a
    And for damage control, a 
    {% autoescape false %}
    block in the template works great. Thanks again Daniel.
  • r
    I was unable to reproduce this. I tried it in jsfiddle, and, while I did not have a proper server and used client side templates, the 
    unSetBodyClasses()
    method always worked on clicks from 
    #unset_update
    , removing the 
    .update-On
    class from the body, regardless if 
    #unset_update
    element was in the main page or in the response content. Please provide more details about your intended behavior and error messages (if present)
1...100410051006...1146Latest