To be fair.. I'm currently still triggering it with the jQuery call... and it's not working. Gonna try with htmx.trigger()

that should work

Boom! Works. Thanks!

This is again a "happy accident"! Because it allows keeping having a "boosted" request even with the redirect. Pretty convenient..

🙂 sometimes things work out

Another topic, I have had a situation this morning where I think

HX-Retarget

would make sense. I am currently implementing a middleware for authentication that intercepts all requests on the server before they arrive in the handlers/controllers. This middleware is activated for restricted resources and it checks the session/cookies and verifies if the current user is authenticated. If that’s not the case, it redirects (303) the user to the homepage. So let’s say now that I have an admin page on my website that contains a table listing all users. And for each row in the table, there is a

<tr hx-target="this"><td>John</td><td hx-delete="/deleteUser/:id">delete</td></tr>

to delete the user/row inline. This is a htmx behavior to trigger a DELETE request on the server, and the response is supposed to be empty so that it removes the row from the table. Now let’s say the session of the user terminates, but the user is still on the page with the table. Then, he clicks the delete button and the middleware intercepts the request. It realizes that the user is not authenticated anymore and executes the redirect to the home page. However, we are in the middle of a htmx request, so in the end, htmx will swap the content of the home page in the

<tr>

, which is really not what we want. Having the possibility to retarget the swap to the body here would make sense. It is a really specific example but I am sure there would be other behaviors where it could be handy.

At least I don’t see how I could easily handle this wrong behavior without this

HX-Retarget

. If anyone has an idea, I would be glad to hear it!

Howdy! I've been working to convert a Vue app to use htmx. I'm enjoying it! There is one thing I haven't figured out, though, and was wondering if anyone has encountered it. My scenario is that I'm using authorization from Auth0 (using their

auth0-spa-js

package), which attempts to re-establish authentication once the page loads. (I'm using the auth event to put the JWT in

hx-headers

on the body tag.) This works if the browser is refreshed on a public page, but fails when it's refreshed on a must-be-authenticated page (fails with HTTP 422 because of the missing JWT in the header). I imagine that this is a scenario that is pretty common, but my searching hasn't turned up anything. Assuming there is a write-up somewhere, can one of you point me to it?

Not sure about other cases, but the way we handle session expiry in the middle of an htmx request, is to return an

HX-Redirect

(e.g.

response.setHeader("HX-Redirect", url);

) to throw the user back to the login page. Could this work for you?

It kinda works, but I am trying to avoid page reloads as much as possible in my app. And adding a

HX-Redirect

triggers a page reload 😕

I'd imagine you'd want Auth0's traditional web app solutions instead of anything SPA related. What server framework are you using?

Its basis is ASP.NET Core. I'm using Giraffe (F#) to generate the pages. I'm trying to develop a Giraffe extension to support htmx natively as I go through the process of migrating this application. Now that you mention it, though, I bet their non-SPA stuff uses cookies, which would be present on a refresh (unless the user had removed them). I've had to rethink a lot of what I learned with SPAs, so that might just do the trick. I was happy to get Bootstrap toasts working yesterday; I send a header from the server, and use a listener on

afterOnLoad

to detect it and show it. The state is controlled on the server, but the UI is still interactive. Really cool stuff; I'm digging this framework!

Could you use an out of band swap for this?

<form hx-confirm="Transfer these items?" hx-post="/url" hx-include="[name='filter'],[name='buildingFilter']" hx-swap="innerHTML" hx-target="#search-results">
    <!-- omitted -->
    <a hx-get="/url/detailsModal/@item.ID" hx-swap="innerHTML" hx-target="#modal-holder">Details</a>
</form>

I have an hx-get inside of a form tag and it is triggering the hx-confirm. Is this expected?

Yep, most attributes are inherited in htmx. As of the latest release, 1.6.0, you can use the

unset

keyword to undo the attribute:

html
<form hx-confirm="Transfer these items?" hx-post="/url" hx-include="[name='filter'],[name='buildingFilter']" hx-swap="innerHTML" hx-target="#search-results">
    <!-- omitted -->
    <a hx-confirm="unset" hx-get="/url/detailsModal/@item.ID" hx-swap="innerHTML" hx-target="#modal-holder">Details</a>
</form>

Can't thank you enough

the docs were bad (that is, absent) on this, so I added some: https://htmx.org/docs/#inheritance

I am not sure how. Do you mean that when I want to redirect the user to the homepage (because of bad perms on the action), I return as a response only an out-of-band element that would replace the entire "body"/"main" by the login page (meaning I should have an

id

on one of those elements)?

something like this:

html
<div hx-swap-oob="innerHTML:body">
   <!-- content to swap into the body -->
   ...
</div>

I think that should place all that content inside the body tag

haven't tested though

🙂

Effectively, i forgot that

hx-swap-oob

could take a selector, I thought oob needed an

id

somewhere. So yes, it seems to mimic what could be achieved with

HX-Retarget

. Thanks!

🙂 no prob, I forget too. you are pushing htmx hard, this is good!

Yes, I really like the html over the wire paradigm, and I want to dig as much as possible as a proof of concept to demonstrate that this method is really fast and efficient. I am also interested in seeing how many customizations are needed on the backend to be "htmx compliant". Ideally, I’d like to stay as generic as possible, by developing the same way as before, but trying to take advantage of this spa feeling. I am currently using htmx alongside golang on the backend. If that works well, I might document/tweek/blog about it in the future!

By the way – is there a (semi) automatic way to retrigger HTMX events based on

hx-push-url

? What I mean is, when a URL is pushed and the site is reloaded, it would be nice to have the same state again.

E.g. by matching the

hx-push-url

element and retriggering the wired up HTMX-event.

Can you explain a bit more?