https://htmx.org logo
Powered by
# htmx-general
  • m
    OK, I see
  • m
    so you are doing something with hx-history-elt
  • m
    So, OK
  • m
    You need a header to indicate that this is an HX history restore
  • m
    that's perfectly reasonable
  • g
    Ideally, it seems like those history restore requests would look the same as a regular request. Could they just include the same HX-Request headers?
  • m
    It's different though, since the target is the history element
  • g
    @mysterious-toddler-20573. I’ll see if I can replicate the “revealed” bug reports. At first glance, it seems odd to me.
  • m
    In most cases you want the whole page on history requests
  • g
    Yeah, that gets tricky.
  • m
    whereas if you are looking at the 
    HX-Request
    header it's usually to render a smaller bit for a specific target
  • m
    HX-History-Restore-Request
    reasonable?
  • m
    For most people just using hx-boost or whatever, they can ignore it
  • m
    it's only when you are using a 
    hx-history-elt
    that this should matter
  • s
    if you don't touch hx-history-elt would it not default to body?
  • m
    yeah, it defaults to the body
  • s
    oh i guess you mean for people using hx.boost with a target other than body
  • s
    im a biit unsure when i would want the target and the history.elt to be different though, when using boost
  • s
    and if they are the same, then serving a fragment on history miss gives the expected result.
  • m
    basically, on restoration, we assume the target is the body and try to get the entire content for it, we don't focus in on any specific area (regardless of the target of the request that created the history entry)
  • s
    alternatively an outerhtml swap instead of an innerhtml swap might also work? .. so that hx attributes are triggered again, I think that was my biggest surprise.
  • m
    yeah, it's tricky because you must use an innerHTML swap on body
  • m
    :/
  • m
  • m
    9.6k, running out of room for new features, probably time to put a lid on it and just fix bugs
  • m
    I'll save a bit of room for SSE/WS improvements
  • g
    I agree that bug fixes > features.
  • g
    Plus, many new features could be built as extensions. I’d suggest trying to make anything new as an extension first. If you want to be really aggressive in the future, there are even some existing features that could be extensions.
  • g
    I’m not positive about this, but I think you could also save some space on the swap functions. Isn’t there some duplicate code that could be eliminated?
  • m
    let me look
1...146147148...1146Latest