have you done anything funny with

hx-history-elt

?

The code for restoring history is pretty simple

it just looks in local storage for the latest HTML associated with the URL and slams it into hx-history-elt

is there a lot of javascript mutating the DOM here?

Not using

hx-history-elt

at all – and frankly I'm a bit puzzled as to what it does exactly when reading its docs site.

Some – I have a (maybe hacky, but best I could come up with) way of initializing special fields like

Select2

when loading a page – since I couldn't rely on the good old `DOMContentLoaded`/`$( document ).ready` anymore when fetching pages via HTMX.

javascript
document.body.addEventListener('htmx:pushedIntoHistory', function(evt) {
    // used for highlighting the currently active navigation element
    activate_navigation();
    // initializing Select2, Tooltips, ...
    initialize_listeners();
});

this is a feature, not a bug 🙂

Ah, OK. So, here's the deal

and I need to document this, sorry

You probably want something like this:

js
htmx.onLoad(function() {
    // used for highlighting the currently active navigation element
    activate_navigation();
    // initializing Select2, Tooltips, ...
    initialize_listeners();
});

And then, in

htmx:beforeHistorySave

you want to undo any DOM changes that that code did, so that you end up with "pure" html in the cache:

js
  htmx.on("htmx:beforeHistorySave", function(evt){
      deactivate_navigation();
      destroy_listeners();
   });

this will save clean HTML to the history cache, and when it is reloaded by htmx on a history navigation, it will be reinitialized properly

Alright, thanks for the info. 👍 I chose a history-related event though to ensure the assigned logic is only executed when a new page is loaded. And not a partial e.g. like the

Online counter

in the top right corner of the recording which is polled via

hx-trigger="every 120s"

OK

One pattern to potentially use there is to select the affected content out of the element that has been inserted:

js
htmx.onLoad(function(elt) {
    // used for highlighting the currently active navigation element
    activate_navigation(elt.querySelectorAll('.nav');
    // initializing Select2, Tooltips, ...
    initialize_listeners(elt.querySelectorAll('.whatever');
});

that deals with the "only initialize once" problem

Will give that a spin tmr – that's probably also going to fix the previous page not loading when navigating back, despite the URL being pushed.

Set a reminder for tomorrow's event btw – curious to see how many newcomers will flood into here

If you want your back button to behave as you expect it to… this pattern of “undoing” all the DOM manipulation your JS widgets did initially on page/fragment load, is critical. We learned this the hard way, since because we only had full page reloads before, we were pretty careless about where and when we added JS widgets… and never bothered to destroy them, because… full page reload. Now, all our JS widgets (select2, tinymce, etc), gets neatly created on load in a single place and neatly destroyed just before the htmx history snapshot is taken in a single place… which means back button behavior that mostly just works like you would expect.

🙂 probably not that many

I need to document that much better

@User a real-world example boiled down for the docs would be awesome, if you have time

Sure… I’ll post it here tomorrow

Ah exactly where I'm at right now, it all makes way more sense now – alright then I'll know what to do

btw, if you want a quick hack that will work you can set the history cache to size 0, and it will retrieve the HTML from the server and rerender

it won't store scroll state, etc. but it will eliminate the need to be tidy with your javascript

Nice; that's definitely good to get started or for projects that have to deal with a lot of listeners

https://news.ycombinator.com/item?id=28851861 > I use htmx then mithril for those pages that really need client side interactivity.

sounds about right to me

@User this is a screen recording of the interaction