Anyone have a recommendation for a small, no-dependency js lib that can make an html table sortable by clicking the headers?

thanks

I'm having trouble understanding whether the back button problems of SPAs are really solved when using htmx. When the back button takes you back to an htmx page, and pieces of the page have been modified, is it guaranteed in all browsers that all previous modifications will be applied? Or is this browser-specific, like it is with an SPA? Seems like it depends on what the browser caches in the history, but I'm not familiar with the details of this.

I'll let @mysterious-toddler-20573 weigh in on guarantees, but I'll say that they've been solved for me (with some work).

Htmx pushes items onto the browser history stack (you can also disable this when needed) and it keeps a history of what the DOM looks like on each push. Again, I'll leave specific behavior of this up to others.

I believe this cache has a maximum size or number of items, so it is possible for someone to "back" themselves into oblivion and run out of cached DOM. In this case (I'm pretty sure that) htmx re-runs a "GET" for the required resource.

Does this make sense?

Thanks. I'm thinking specifically of the case where

hx-push-url="false"

(or unspecified) when the last modification was made, the user navigates to a different site, then presses the back button. In that case would htmx have saved the last modification, and will reapply it? (I'm just starting to learn about htmx, so I may not be thinking correctly.)

Hey, sorry I'm just getting back to you now. Like any good hypermedia, if you change the page materially, you'll want to update the URL.

hx-push-url="false"

works great for things like expanding an accordion or a tree control. I also use it for modal dialogs (though you could make a case that these, too, should get their own URLs, it was just too hard to do on my server, right now).

To answer your question, I'm not exactly sure what it would do -- it might depend on the state of your cache. If this is super-important, a couple of quick experiments would clear it up for your specific cases. But I don't think it's something to worry too much about. Try to use

hx-push-url="true"

everywhere you can, and it's a non-issue.

One more thing comes to mind, and I'm not sure where it's mentioned on the site: One great pattern is for your server to recognize a full-page request (e.g. from someone hitting the "refresh" button) vs. a partial-page request from htmx. Htmx sends the

hx-request

request header with every partial page request. You can use this to identify partial requests, doing things like remove expensive site navigation from the response.

the way history works in htmx is that, when a new URL is pushed, we snapshot the current DOM to localStorage and associate the URL with that snapshot. When we catch a back button event, we restore the DOM associated with that URL. So we act as much as possible like "normal" browsing. That said, the history support is the trickiest and touchiest code in the library and I understand it about four weeks out of the year.

Hi y'all! Does anyone here have experience integrating htmx into a Shopify Liquid template? I want to build a cart configurator thing using their AJAX API. It provides an option to rerender template sections (partials) and send the HTML down with the response e.g. to a request to modify the shopping cart. I wonder if it's possible to do multiple swaps for a single request with htmx? Relevant Shopify Docs: https://shopify.dev/api/ajax/reference/cart#bundled-section-rendering

any example of how to enable or integrate jwt based oauth2 ? I did not find any on htmx examples page. my app is html based for most part and just one api is rest/json response but need to add login based access so am looking at jwt if that is applicable at least to start with html pages and if it can also be extended to rest/json api.

@gorgeous-ghost-95789 @mysterious-toddler-20573 Thank you for the responses!

that seems like a really great case study

jwt will work fine, how does your server expect it? As a bearer token in the header?

you can probably just stick https://htmx.org/attributes/hx-headers/ at your base

I'm curious about this too.

@hundreds-camera-24900 I am using fastapi but mostly serving html but just one rest api returning json. I need to add login feature to app and also protect that rest api for which I am looking for more details like example on fastapi / htmx lines. here is fastapi docs i am referring: https://fastapi.tiangolo.com/tutorial/security/oauth2-jwt/ and yes its bearer token as per docs. I thought to try that when first dashboard page loads I try to send back 401 and show login modal dialog but since its not xhr request am unable to intercept and use htmx trigger to load modal partial html. seems login page has to be full html page.

I feel like it's still a little clumsy, but here's a hyperscript snippet that sorts table rows by clicking headers. It works, but I need to make it more robust. https://github.com/bennettscience/canvas-lms-mastery-helper/blob/main/app/static/hs/sortable._hs

I could spread the evil virus htmx again. One small startup yesterday, and today one developer was very impressed by infinite-scroll... Sympathy for the devil 🙂

I have hx-confirm on a parent div. Each child Input element has its own hx-post, but if the cancel button is clicked on the confirm message, I would like the Input element to catch that and perform additional processing (specifically restore its original value based on it's placeholder value). any ideas on how I can hook into that cancel "event"? ..hopefully without having to create a custom script, ideally another hx-X attribute on each Input element? I see the hx-confirm is pretty basic, so I ended up changing the logic so that I pop my own confirm on the element and if the confirm returns true then I send a htmx.trigger to the element to tell it to post, else, I do my "cancel" processing.. NM!

mmm, I am a bit confused. I am triggering GETs when I have a change event on a set of 3 dropdowns. These GETs target a different element of the DOM (not the dropdowns themselves). I am pusging the URL because I want the users to be able to navigate back and forth between the dropdown combinations they have selected, or just to share the current selection with another user. To my surprise, when navigating back and forth, the dropdowns selected value gets reset to the default. That seems to be a browser issue and not an HTMX issue, but I was wondering if anybody has had this issue before.

Here I attach an example of what I mean (the dropdowns lists were not captured, but hopefully you get what I was doing):

I trying with autocomplete="off" or "on" on the `select`s and doesn't make a change 🤔

maybe it's because they are not inside a

form

, checking that...

nope

Is there any downside to switching the default swap type to morphdom