@mysterious-toddler-20573 doesn't seem the original event is there though. I mean I have trigger on form, so when input changes the form change is triggered. But is there a way to know which input did initiate the change?

expand detail

requestConfig

and show me the screenshot

oh, it's there in the detail.. I didn't open all of them TBH, is this somewhere in the docs I missed? Thanks a lot for the help with silly stuff 🙂

nice and shiny

not really well documented, you have to dig around

yep, get the target of the original event

thank you! I'm so impressed with the HTMX community here and on Reddit : D

maybe you can drop a hint in the events section it might be useful for someone in the future and that's where I looked for it (basically what data do I have available in every event type)

@lively-coat-67211 it's a great tool! I am using it with Django as well and it's a blast!

we mention

detail.requestConfig

here: https://htmx.org/events/#htmx:beforeRequest

but you'd have to know about the

triggeringEvent

via inspection :/

@User 🙂 glad you are finding it useful

yep I missed that, there's a lot of stuff in that event

👋 I'm using HTMX for a while now together with ASP.NET and I would like to know if it is possible to have channel dedicated to ASP.NET with HTMX named

aspnet-htmx

or

dotnet-htmx

- thanks!

There is #963040198390861875

Yes, @mysterious-toddler-20573 has just created it as requested.

Ah, ok 🙈

You can't beat that customer service

htmx newbie with a best practice question. please lmk if there is a better channel. i have an html table essentially displaying rows of a database, with pagination. the final "actions" column has an edit button. i am considering a few UX possibilities for what happens when the user clicks it: 1. traditional. no htmx involved. user is taken to a new page

/edit/123?page=2

. When the user is done editing they are redirected back to the table (the list view) at the same page they were just on, scrolled to the item they edited. pros: simple. cons: list page and its data have to be reloaded, which can take a few seconds, even though we know only 1 row has changed (the one we just edited) 2. edit in place. use htmx to load the edit form inline into the table row. the tricky part is the history. ideally, there would be a history state like

list?editing=123

, but then i need (i think?) to implement both the fragment route that swaps out the edit form in place, the "normal" list page (no editing), and the

list?editing=123

version that has the list with editing form already opened. 3. modal. open the edit form in a modal, and then, when the modal is closed, update the row that spawned it with the updates. this one i don't know how to implement in htmx, as it's not really a simple swapout and replacing a target (at least, i don't see how to view it like that).

@adamant-state-54102 see the examples for modal https://htmx.org/examples/modal-bootstrap/

I like 2 but dropping the history entry. I don't think people typically want or need to send out "editable" urls, so in general I bias towards keeping them hidden in favor of simplicity. This also prevents strange browser auto-complete issues in forms. You could also just chuck an hx-boost on the table and call it good 🙂

Yes, I was thinking about that too. And honestly it's probably a fine compromise.

I'd give it a whack and see how it feels

not too hard to flip things around if it feels wrong

end of the day you have a box w/ a form in it 🙂

you can stick that box anywhere

Thanks @sticky-ram-54793 . So it looks like I would modify

closeModal

to also include the "swap out the original row for the updated row" logic? This was the part that felt potentially un-htmx-like to me. Meaning, at that point I'm back to writing good ol' procedural dom-mutating javascript. But I didn't know if I was missing something....

i lean against modals for exactly that reason, but it's such a common pattern that we try to accommodate it. So long as system state remains synced via coarse grain HTTP & HTML interactions, we'll allow it 😉