it's always something

does hx-post always put the input parameters in the url query params?

or is it because i have hx-boost somewhere in the parent hierarchy

should only end up there on GET

hmm, i had an idea that i thought might work but i'm having a hard time finding the right incantation. https://gist.github.com/mekhami/d98efb0efd49b00080a227d713f2c522 I have this modal. The first time it loads, it renders the empty form. Then I click the button, it POSTs, the server returns the form with errors if there are any. On line 79, I check

if not form.errors and form.is_bound

. Basically, if you posted a form (form.is_bound) and everything is good, I want to fire an event that removes the modal. But

htmx:afterSettle

and

htmx:afterOnLoad

and

htmx:load

didn't work. I think what i'm looking for is an event that fires once this element is present in the dom at all. the server will only render this dom node in the case of a successfully posted form...

but, i guess because i'm re-rendering the entire modal every time, the event listener that was created before has been removed, so any event listeners I put in that submit button are no-op.

ahh, I think I have a pattern...

mannn i can't describe how this makes me feel haha. I've been doing webdev for like 8 years, so not forever, but I've definitely been experience javascript fatigue (especially with the build system side of things, just so much complexity to show and hide modals and do really basic stuff with forms...) getting back to basics and letting the application state be entirely on the server is just... it's almost emotional for me lol. it's a huge weight off my chest.

🙂

we're all gonna make it, friends

hypertext is the engine of application state and don't let anyone tell you otherwise

i think it actually takes some pretty careful consideration to structure an application like this correctly. i'm concerned that it's hard to pull things apart once you've already put them together.

yeah, it can get hairy if you try too hard to force a certain UI

but if you go with the grain of the web, you can get a lot done with minimal complexity

modals are always problematic because there is client state involved

are you familiar with python/django at all?

I tend to do inline edit UIs instead

I'm not, sorry

but there are a lot of django folks on here

no worries. was gonna share my repo with you and tell you what my concerns are so far and ask how i can untangle them

I can take a look, I'm sure I can make sense of it

it's all the same, I'm a rails guy

but I am going to bed right now, lmk if you want me to look at it

well this is the repo: https://gitlab.com/mekhami/htmx-demo If you feel like trying to run it and check it out, my concern is over the

ledgers

page. right now that whole UI is fully re-rendering the body, and I think what I want, in order to demonstrate the utility of this, is for only the table to re-render. reorganizing seems kinda tough though. all my filters and paginator need to target just the table, and so my backend view function needs to render one template for the full page load (not an htmx request) and one template for the partials. The pattern is out there already, and there's a library for doign this sorta thing, but I guess I didn't see the pattern correctly when I'm starting and now rewriting it seems a little messy. But i'm gonna give it a try and see what happens. This is the demo I'm gonna give to my company btw, a lot of people I've shown little tidbits of this to are really excited by it.

I'm also starting to think about reusability. Imagine I have some domain model that I want to search in more than one place. If those UIs have two different constructs, I have to have two different endpoints for the searching. Granted the internals of that search are reusable, but the template and the view/controller is not. I can see this leading to a proliferation of endpoints for doing the same thing in different places in the UI. In the JSON API/"rest" world, I have a single endpoint for that. I'm not entirely sure this is actually a problem, but it's something I'm thinking about.

Not sure I understand your issue entirely but you could, in theory, have just one search endpoint which figures out what to search for based on the form name and returns the appropriate results.

templates should be composable and reusable, depending on need. The different URLs should be expressing different contexts and therefore drive different queries to establish data, but the UI can be reused on the server side (again depending on context)

Whatever conditional logic you were doing on the front end can be done on the back end just as well, you are moving the query code to the back end.

also, this: