OK OK, so I missed a few

lol

Ok 🙂

I can live with

htmx.trigger(htmx.find('#form'), 'refresh')

for now, but those dozen saved characters would make me surprisingly happy 😉

one dozen is about 25%, so I get it

it's also about 50% less cognitive load

"why are the characters htmx here twice? "

I've got an issue with HTMX and Rails that I'm a bit stuck on. I've got a

button_to

that runs a

hx-post

, and that's working. The response swaps the button out, and the idea is that the button can be clicked again, over and over as many times as the user wants basically. But when I click it the second time after it's been swapped in, Rails gives me 422

InvalidAuthenticityToken

. The new request has the new

authenticity_token

that was created in the response from the first click, and the cookie seems to be updated after the first request, so I assume it has the right new value in it, so as far as I can tell, everything is getting sent correctly, but I'm not quite sure. Anyone know what I might be missing?

Hey @User -- I'm not a rails developer, so I'm shooting in the dark a bit. StackOverflow says that the authenticity_token is included in the form post, is that correct? So, when you submit the button, are you swapping out the whole form, or just the button? I'd start by using your browser's dev tools to look at the contents of the HTTP Post to confirm what's being sent to your server.

Does this help get you pointed in the right direction?

Yes, the authenticity_token is a hidden field that gets submitted as part of Rails forms. It is included in this form that htmx is swapping out (button_to basically makes a form that's just a button, but it also adds this hidden field).

I did check the contents of the POST and it looks correct, which is what's confusing me

Strange. Is there a cookie that has to match the hidden field, too?

@User are you replacing the entire form?

@User yep

@User Yes, I believe there is. I was looking at this article that describes the process in detail: https://medium.com/rubyinside/a-deep-dive-into-csrf-protection-in-rails-19fa0a42c0ef

Does htmx affect cookies at all, or do they work as expected?

Oh my. Server-side integration for the win.

@mysterious-toddler-20573 will need to say how XHR works with Cookies. I'd expect that htmx isn't doing anything exotic, here, and that cookies would get set just like any other request.

There's definitely some rails-specific front-end logic going on. Is it possible (temporarily) to disable this feature in Rails so that you can keep working while you troubleshoot this?

Yes, I can temporarily disable it, but I'll need to re-enable it before I merge my changes and deploy them

I figured it out. It seems that even though the server responds with a new CSRF token, Rails isn't expecting a new one until the page reloads or something like that. Here's the code that fixed it:

document.addEventListener('htmx:configRequest', (event) => {
  const csrf_token = document.querySelector('[name="csrf-token"]').content
  event.detail.parameters["authenticity_token"] = csrf_token
})

That's cool. It looks like something that could be wrapped up into an htmx extension, to make it easier to use and embed in the future.

Yep, probably. I'm going to read up a bit more on this and talk to some team members and see if this is actually right. If it is, then I'll see about making an extension

If it works, it's right... 😛

Also, fyi it looks like this page is broken: https://htmx.org/extensions/rails-method

@User thank you! looks like I never got to that page

Er, or I removed that extension

However, it looks like there is a need for a rails specific extension

Speaking of extensions, I've been thinking about my "extension wishlist." @mysterious-toddler-20573 -- do you have a roadmap for this? Or, is it OK for me to just propose a bunch of crazy requests on the github issues list?