https://htmx.org logo
Powered by
# htmx-general
  • s
    The evil back-button: Imagine I open a page. The first state of this page is P1. Now I modify some things via htmx. And I see P2. I navigate to a different page. Then I press the evil back-button. And .... grrr I see P1 and not P2. Is there a way to tell the browser that it should display P2?
  • u
    Isn't it a cache problem?
  • m
    htmx should snapshot the DOM before navigation if you are using HTMX for the navigation
  • m
    are you?
  • m
    Or is it a "normal" link?
  • m
    we could add 
    saveHistory()
    to the public API and allow you to snapshot the current DOM state for the current URL with
    Copy code
    js
  htmx.saveHistory()
  • u
  • u
    I started fiddling around with HTMX because it sounded really cool. But during my first basic testscenario (pagination) it started behaving funky (see GH issue above). After seeing some other GH issues related to basic scenario’s i decided to put further research on hold for now. (I don’t expect any reaction, im just sharing my experience 🙂
  • m
    Yes, I am planning on looking at hx-boost next
  • m
    I want to make it a drop in sub for turbolinks
  • m
  • m
    including the value of the clicked button in form submissions, does anyone care to do a code review?
  • m
    I am using focus to track the last clicked button, 
    focusin
    and 
    focusout
    events in particular, can anyone think of a way that wouldn't work?
  • u
    I REALLY wish I could help, but im just a derpy .NET developer with a bit of jQuery skills 😦
  • s
    Yes. Up to now I use normal links with anchor tag "href"
  • m
    Got it. So the way history works in htmx, it snapshots the DOM immediately before and after any HTMX request. So if "other stuff" happens after the request, it won't see that.
  • m
    if you mutate the DOM in a way that HTMX can't see, it won't update the history cache with that new DOM state.
  • m
    This is particularly annoying if you use a javascript library that trashes the DOM: you don't want to store the trashed DOM in the history cache. Instead you want to store the DOM just before the library trashed it and then, on history restoration, rerun the javascript library against that DOM
  • m
    I must admit this is not a fun part of the code for me
  • m
    suggestions for how to make this better are welcome 😑
  • g
    https://github.com/WICG/app-history/blob/main/2021-06-28-incubation-update.md apparently there is a new history API under development
  • m
    i hope for the best, but I do not expect improvement
  • m
    i mean, it can't be worse than the current history API
  • m
    which literally has ONE slot you can handle history events with
  • g
  • m
    htmx and intercooler try to be good citizens and if an existing history handler is there, we wrap it, but other libraries just nuke it
  • m
    i had an analytics library break our whole app navigation thanks to that very cool thank u for that
  • g
    Yeah, not sure what happened there, somebody just forgot events existed i guess
  • g
    anyway this new thing seems like a boon for SPAs (which some htmx apps are)
  • m
    looks like a better API
1...315316317...1146Latest