@mysterious-toddler-20573: This is probably nothing, but while trying to update my fork. I got a message from bigskysoftware/htmx: Merge pull request #2 from bigskysoftware/master (#140) about MY changes. Since I a github newbie, just wanted to make sure I didn't somehow circumvent it's security and messed up the htmx code base.

@User the right thing there is to make the headers an anchor tag that does the sort server side, so that when polls occur the sort is part of the request and is preserved.

@User I am making a sample that does almost exactly that. Although I have it update stats on a 4 second poll. The trick was to use a client side variable, through localstorage to track which column is the sorted column. I am impressed with the fact I have used no javascript at all to achieve this effect. I will place the sample out there on github when my extension gets through approval. Not a discord guru yet, but I will include my anchor code in the next message. Ignore the hx-ext="localvars" and include-local-vars attributes for now.

Character TakeDowns Assists Deaths <!-- Stinky 2 3 1 -->

@User Just a caveat, the server side needs to know what to do with the anchors' post and sort accordingly. I am saying this because sometimes some JavaScript libraries out there do the sorting for you on the client side.

@User Interesting. I'm looking forward to seeing it.

FYI - the other situation I struggled with was notification if polling failed. I finally wrote some JavaScript in an event to make a DIV visible that there was an error. It didn't feel elegant though.

Theres a channel 😮

hellow!

@enough-bear-62625 I am a better programmer than github user, struggling with some of the recent code base changes and my own pull request for my fork. As soon as I can get some of my new changes into my pull request and then get my pull request approved I can be a little more responsive. But I thought error handling wasn't that hard -- I though there was an extension for it (maybe just dreaming). In intercooler I know there as a ic-failure or something like that (sorry been distracted by life lately).

can anyone point me to an example of authentication

@mysterious-toddler-20573 When you get a chance, please leave comments on next steps for local-var-extension pull. thanks!

@User auth should work the normal way on your platform, orthogonal to htmx

@User sorry, super slammed for the next three or four weeks, will review if I have a chance

@incalculable-hairdresser-83570 You have a couple of typos in your documentation, "(...) the the localStorage" and "The localStorage variable do not..." (should be variables). Also you should probably add your extension to the list in

www/extensions.md

and remove the package-lock file from your PR.

@User Thanks for catching those errors! Fixed, uploaded to github!

@User Based on our previous conversations about using a frontend server with htmx, with a json API on the backend - I must actually talk to another team here, as they use JSF as a frontend server in much the same way.

Oof Java server faces?

Yeah...

That what some teams are using as they're Java devs with very little frontend knowledge

Well, at least you have precedent.

True. Though seeing as they're essentially using JSF as a frontend server, I think it might be interesting to spin up an Express server in front of our JSON API and utilise htmx. Basically I'm at the stage where I've had enough of SPAs and want to push as much as possible back onto a server.

Hi all. 👋 Wondering if anyone might be able to guide me on this little issue. I have a like/unlike ♥️ that animates between each state, and with a small loading animation to bridge the two states that is triggered when

.htmx-request

is applied. And I would like to enforce a min 1 sec application of the load state, ...as it otherwise looks very jittery and glitchy when the loading state is flashed for a few ms. You can see a cleaned up version of it here, but where I am using Alpine to simulate the network request, and to enforce a small delay that makes it look better. If you wish to witness the problem first-hand, take my 1000ms delay and move it down to 100. https://codepen.io/kerns/pen/YzwJPaJ?editors=1100 As I am using Sprig (and therefore htmx) [https://putyourlightson.com/plugins/sprig#article] with a similar blob of code in production, I was wondering what my options were in htmx world. I was playing with swap and settle as possible methods for making sure the load state drags out a bit more... but they only seem to work on either side of the actual request. https://htmx.org/attributes/hx-swap/ Ideas welcome. Maybe there is another way to tackle it.

Sounds like you want to limit the request trigger time so a second request doesnt happen, correct?

(btw, good looking like button 🙂

Would it not make more sense to only show the loading state after X amount of time?

@User (thanks) @User Well... not sure if I understand, but from a UX point of view we need application of the loading state class to be immediate, on click. So if you mean a delay before we show the loading state then that wouldn't do the trick. It's actually even more complicated than my original problem desc. because not everyone has blazing fast broadband ...so we wouldn't want to make an xhr request that had already taken 1.5 seconds, or 4 seconds (poor 3G) take another full second. Rather we just want to enforce a minimum of 1 sec. Strange, I know.

I'm honestly not sure what you mean

Here's what I imagine. User clicks on the heart icon (at this point, if possible, it's probably a good idea to disable it, or lighten it so the user knows something is happening), app then does the XHR request. Should this request take longer than X amount of time, display a loading indicator. Once request returns, swap the html and remove the loading indicator (if exists).

So that way, if you're on fast broadband, you get a near instantaneous swap of the heart icon (no loading indicator needed). Otherwise, if you're on a slower connection , the loading indicator will be shown.