https://htmx.org logo
Powered by
# htmx-general
  • s
    a trick in most frameowrks including asp.net is you can specify the layout file optionally, either only inserting it when hx header found (laravel) or simply setting it to null when no hx.-header found (asp.net).. it makes it super easy to use the same endpoints and the same views for htmx content
  • s
    id suggest maybe some kind of tutorial for this usage pattern in the site, it really makes the backend remarkebly simple while getting all the value of only rendering partial parts of the page.
  • s
    in asp.net i simply use layout = Viewbag.layout and either its the layout path or null 🙂
  • s
    now if only the bug with missing headers on history miss gets fixed this will work flawlessly.
  • g
    Hey @User, I just added a ticket for the tutorial you mentioned. It sounds like a good idea to me. https://github.com/bigskysoftware/htmx/issues/366
  • g
    As for the "bug with missing headers on history miss" -- is this already documented in GitHub somewhere? I didn't know this was a thing.
  • s
    not sure, strictly speaking i do not even know if it is a bug
  • s
    but the request made by htmx when history is missed on a back button doesn't include any hx headers, however htmx will still attempt to substitute the target div
  • s
    this.. breaks things, but it is easily solved by setting a no-cache header forcing the browser to reload the full abck on a back button
  • s
    since all my apps have dynamic content, this is generally the solution i use anyway
  • g
    Ouch. That sounds like a bug to me 🙂 I don't know how the history setup works, but we can at least put this into GitHub as a ticket to dig into.
  • s
    its easier to do security if the browser doesn't store dynamic content in the cache (or after logout someone could simply press the back button to see a users private info)
  • s
    so I think its a minor thing anyway, but was a point of confusion for me.
  • g
    And here I thought I was going to do some "other" work today. Damnit htmx. Every time I think I've gotten away, you just pull me back in...
  • s
    and certainly a static site would wish to use the history cache
  • s
    id say its pretty low priority either way, in general i think the whole history caching thing is just trying to be a little too clever.
  • s
    most things o nthe web are too dynamic to want a historical cache of the data.
  • g
    Yeah, and I'm working on something like a static site, so this will certainly be relevant to me, once I get there.
  • g
    I just added this. Feel free to expand with additional details, if you have 'em 🙂 https://github.com/bigskysoftware/htmx/issues/368
  • m
    I will try to take a look at history this weekend and work out any bugs
  • m
    @User we have a few reported bugs around the revealed event: https://github.com/bigskysoftware/htmx/issues/351 https://github.com/bigskysoftware/htmx/issues/360 I have asked both reporters if the infinite scroll demo works for them.
  • m
    > but the request made by htmx when history is missed on a back button doesn't include any hx headers, however htmx will still attempt to substitute the target div The way htmx history is supposed to work is, on a cache miss, we reissue the GET as just a plain old GET (no HTMX funny business) and then swap the response in, in its entirety, into the body. Is this not what you are seeing? I want to get the history bugs worked out this weekend so I can cut a new release if possible.
  • s
    The problem is that I want to return a fragment to swap in (im also using -history-elt? to make the awap in to a div instead of the body.. but regardless, without being able to identify that it is a htmx request the server will return the full page and not just the fragment that I would want to swap in.
  • s
    At least for my use the primary value in htmx is avoiding the server having to generate the navbars and layout.
  • s
    I think i might have to actually make a full page for a personal project to explain the problem, since all my stuff is for work its hard to share an example.
  • s
    Imagine a server endpoint that on a fresh pageload returns a layout file with a div that contains htmx triggers to load the contant from the same endpoint, if I do this on my nav links then I can use hx boost and ctrl + click and f5 works great 🙂
  • s
    but what happens on history miss is the server returns the layout file again and htmx swaps in the div/body which in this case is blank, and so the screen is just navbar and empty content.
  • s
    easy workaround is setting no-cache headers and forcing the browser to reload the page, for security reasons I do not really mind using this solution.
  • s
    but it seems strange there is no way at all to see the history miss request was made by htmx, this this request have distinct behavior from a normal browser load, the server needs some clue to behave differently.
  • s
    hope it makes sense, either way I can work around it 🙂
1...145146147...1146Latest