Thanks. It worked. A little less elegant than i had wished for with having to set the classes for all the inputs, but ok 🙂

Not sure how far the css selectors go, but if you haven’t already, I’d also try hx-trigger=“change from:#myform select” If that works, it won’t require classes on your selects

All right. I think I will leave it with the class trigger. If it aint broke.

With the way HTMX handles history, I am having a hard time recreating a SPA that I originally built in Vue. A simple form of my problem is: - User 1 is on page 1 and there is state such as a view counter with say a value of 100 views - User 1 clicks a boosted link to go to page 2 - User 2 goes to page 1 and now the counter has a value of 101 views - User 1 clicks the back button to go from page 2 to page 1 and the counter shows a value of 100 because of history snapshotting, when in reality it should now show 102 views. Is there a way that when someone clicks the back button, a request for that URL is sent via HTMX rather than displaying a stale snapshot? I don't want to set history cache to 0 and cause a full page reload. If I am thinking about how to do this incorrectly, is there a better way to handle navigating back in such a way that dynamic content is shown, not stale content from a snapshot, and a full page reload is not required?

would making just this one page not use history be useful? Or do you want something more elaborate?

> from the hypermedia.systems guide @mysterious-toddler-20573 Doesn't take long, does it? The industry is hungry for simplicity!

\> ppl r using ur stuff

@mysterious-toddler-20573 From a UX experience, I find it kind of jarring that some pages would require full reloads on back. However, I feel like this could be avoided with a change to how the hx-trigger="load" works. Currently, hx-trigger="load" does not fire on a snapshot (when a user clicks back to a page where an element has hx-trigger="load", this trigger will not fire again). Would it be possible to have a way to mark an element so the contents of that element will not be included in the snapshot, and the "load" trigger will fire? I am not sure exactly of the specifics, but basically a way for lazy loading to still work on snapshots. What do you think?

what if you set up a trigger to listen for the

htmx:historyRestore

event from the body: https://htmx.org/events/#htmx:historyRestore

also wondering if we want a way to cache invalidate here. This would be a problem with "normal" HTML as well.

let me think about it for a bit, sorry, it's vacation here and I'm kinda vacating

No problem! Thanks for responding to my requests at all :). The htmx:historyRestore event is promising, but it feels a bit hacky to have different "load" and "historyRestore" behavior. I can't find it in the docs, but is it possible to have hx-trigger work with events like this? Something like hx-trigger="htmx:historyRestore"? I am trying to avoid using hyperscript or something like a global javascript file. I haven't tried this avenue, but perhaps I can use alpine on elements with dynamic content like this, though I want to try to avoid JS as much as possible

yes, you could have it like so:

html
<div hx-get="/view-count"
     hx-trigger="load, htmx:historyRestore">
  Count is ...
</div>

and it will load lazily on the first one and then it should load again on a history load

in theory

I have a form:

when I click the button with a mouse, I get a boosted htmx driven form submit

when I hit enter in the last input I get a full document submit

I have no idea why

I was asking a question somewhere that included some htmx code (Not intentionally), where a respondent mentioned that tags like

hx-*

are not great. Instead,

data-hx-*

would be ideal. What do you think about this?

Face palm on my part, I must have had a caching issue, but hx-trigger="load" is firing for history snapshots, so htmx:historyRestore is not needed in hx-trigger. Since this is the case, if there were something like hx-ignore-history on an element so it wouldn't stay in the history snapshot, then combined with hx-trigger="load" you could have spa like behavior when pressing the back button. This is needed because now if you just use the hx-trigger="load", the snapshot will still contain the stale data, which gets replaced quickly by the "load" trigger (causing a flash on the screen).

Big brain developers like to say this, you can summon up htmx that way too: Click Me!

Good section from the https://www.hypermedia.systems book: > HTML is extended in two ways: > - Ad-hoc extensibility. HTML is a fault-tolerant language, choosing to ignore things it doesn’t recognize instead of throwing errors. This means you can use unspecified attributes. htmx relies on this heavily. If extensions see common acceptance, they might even be incorporated into specifications! (We can dream.) > - Specified extension points. Things like classes, tags, custom elements and data- attributes are made for custom data. They can be used to build meta-languages embedded in HTML.

This is an interesting discussion to see this morning; I've been recently considering whether my library that generates htmx attributes for .NET / F# views should produce

data-hx-*

instead of

hx-*

. The former would pass validation (do people still do that?), while the latter saves 5 bytes every time it's used. I don't think the difference is worth the complexity to do either, based on a flag, and I guess it's OK to be opinionated. I haven't gotten any complaints either way.

If it’s automated, I’d lean towards generating the valid html

data-hx-*

tags. Y’know, for the big brains.

an attribute to disable history for a specific page is coming in the next release (next week I hope)

My guess is some sort of script interference. Maybe use

monitorEvents()

to see what's up? https://htmx.org/docs/#debugging

@mysterious-toddler-20573 Being able to disable history for a specific page is great, and I think it would complete the picture to be able to disable history for a specific element. The solution I am using now is:

<div
    hx-get="/somedata"
    hx-trigger="load"
    x-init="$el.innerHTML = ''">
</div>

Here, alpine will clear the data that would otherwise load stale in a snapshot when a user navigates back. If alpine did not clear it when restoring from a snapshot, before the element loaded, there would be a flash as the old snapshot data was replaced with the new data from on load. Is there any appetite for having an

hx-ignore-history

or something like that which could be put on an element? I think an extension could be written, but it feels to me like it would fit the core and really enable SPAs without having to use Alpine.

(x-init fires before htmx:load and htmx:beforeOnLoad)