https://htmx.org logo
Powered by
# htmx-general
  • a
    Is the problem that the get request is to the same url, I'm just checking for the HTMX header in the get method in the view then rendering appropriately
  • g
    It's hard to say right off the bat because there are lots of moving parts -- both htmx and your server config. It is definitely easier if you have distinct URLs for each resource you're calling.
  • g
    Also, page fragments might be getting cached in your browser. One quick test would be to use your browser's dev tools to (temporarily) turn off caching to see if this is the culprit.
  • g
    How does your server know to return a whole page vs. a fragment?
  • a
    It checks for the htmx header, if it isn't there then return the base page, if it is then return the fragment
  • g
    Ok, gotcha. (That's what I do, too). You'll definitely want to put 
    hx-push-url="true"
    in your 
    <body>
    tag, so that history gets updated.
  • a
    Ah that's good to know, I was thinking of all the refactoring I was gong to have to do (!)
  • a
    So it just needs to go in the body tag? Okay
  • g
    Yeah, it gets inherited, so you only need to put it on the top level.
  • g
    The app that I'm building (painfully slowly, btw) listens for the 
    hx-request
    header, then serves a whole page or a fragment. But the "wrapper" content is included in the initial whole page return. That means only one HTTP round-trip instead of two.
  • a
    Hmmn, it still does weird things. Like, in the cart page, I have a post request that creates a "job" and redirects to the jobs page. If I hit back then it loads an entire version of the webpage back inside the frame that normally would contain just the cart
  • g
    That is strange. Something is getting crossed -- although htmx is pretty thoroughly tested in this area. I'd start by using your browser's dev tools to watch all of the network requests. See if something is being cached in your browser.
  • g
    Double-check htmx by verifying that all of the requests contain the right headers for the current context, then double-check that your server is returning the right content given the http headers
  • g
    Somewhere along the line, you'll find the discrepancy. I'm kinda hoping its in your code, because that will be easier for you to fix and it will mean the bug isn't in htmx. But if you can demonstrate it doing "the wrong thing" with some sample code, someone (maybe me) will get it fixed pretty quickly.
  • a
    Okay, I'll try that. One more thing, if you are wanting to trigger a redirect (for the example I mentioned above) how are you achieving it?
  • g
    You can add a header to your server response that will force a redirect: https://htmx.org/reference/#response_headers
  • a
    Obviously there's the django way and HTMX client side way - just wondering if perhaps that's what's causing an issue
  • a
    ?
  • a
    Ah okay, so client side
  • g
    I've gone back and forth on how to handle redirects. I'm not using django, so the end result is a little different. I've tried a couple different ways, and I haven't settled on one definitively, yet. But I think it's better to let htmx handle it. Someone with a more complete app may contradict me. If they do, then listen to them 🙂
  • a
    Yeah, I've been flip-flopping haha. Appreciate your insight though and all your other suggestions 🙂
  • s
    if its possible to handle it on a browser/server level then it is almst always best to avoid introducing javasript into the problem
  • s
    but ya I did the same with a base layout the loads a partial tmeplate via htmx, it works great for making the server side code simple
  • a
    That's great, thanks @User
  • a
    @User - would you mind roughly explaining what you meant when you were avoiding 2 requests?
  • g
    I tried to type it up a couple times, but it just comes out as a word jumble. One thing I tried, after an http 
    POST
    was to have the server just respond with the next page you should see... essentially a server-side redirect.
  • g
    Oops.. I think you're referring to something else, though. scratch that.
  • g
    In your first question, it sounded like you have one HTTP call for the page "wrapper", that then loads the inner page content via htmx. Is that correct?
  • a
    That's correct
  • a
    It's basically the base page + nav, which then calls in the report/content
1...151152153...1146Latest