I think there's something in htmx where it won't re-process a node that's already been processed.

Yes, as of right now it won't reinitialize and won't pick up the modification unfortunately

😑

best thing to do is to reinsert the element and reprodcess

sorry about that

Alternatively, could you send new tags in the htmx response, either in the body as part of a larger element, or OOB swaps?

Thanks for letting me know I was going about it wrong! No need to apologize. htmx is awesome, I just need to learn more about these edge cases. 😃

I think I've begun to understand where fragments make sense. While the examples show a template containing all of the HTML required for the page, there's no real requirement that that be the case. I'm not convinced having the whole HTML in a file will scale to multiple pages - you'll want to extract out your layout or similar at some point. However, when a page has multiple pieces of HTMX functionality, that's when fragments make sense. Most templating libraries will let you do something like partials, which could be used instead. The advantage of fragments is that you can have all of your partials in the same file and have that LoB goodness. I'd be curious to see how that scales when things like OOB updates start to get introduced though - I'm not sure what that would look like, and whether it starts to break things. Just thinking outload - I saw that someone has stepped up and implemented templates for Jinja, which got me thinking again: https://github.com/sponsfreixes/jinja2-fragments

Yep. Also when you have elements that are tightly bound together and you want to keep them in the same file but still update part of it dynamically, such as a table body. The point of template fragments is to divorce the decision to split a file out (which should be based on your general template management philosophy) from the practical need to simply render some subset of content in a template.

@mysterious-toddler-20573 Is it possible to respond to two different events inside a form and submit to different endpoints based on that event

No

You can put a div inside the form and handle the other event/url

maybe a new feature to do this is a good idea? https://discord.com/channels/725789699527933952/725789747212976259/1015598125110530099

oh?

So something like this?...

<form hx-post="/main-endpoint">
  <div hx-post="/other-endpoint" hx-trigger="other-event" hx-include="#something">
    <input name="something" id="something">
    <button type="submit">Save</button>
  </div>
</form>

For this quickie example, never mind where the events come from 🙂 (EDIT: I haven't tested.. you'll probably need to use hx-include, to make the post work correctly, too)

hmm. not sure. I want to use it with Sortable so I'm not sure the div inside will trigger

one way (but crappy) is to have a hidden input and some custom js + custom event

and send to the same endpoint

Ok, yeah. I'm coming up on something similar, too. Not sure how I'll handle it yet, but probably some custom JS/HS to do the post.

you can hook into htmx:configRequest and set your request path based on

triggeringEvent

proeprty

and presumably set custom data for the request?

oh, indeed. that's a much a better solution

thanks

check that https://github.com/bigskysoftware/htmx/blob/master/src/htmx.js#L2698-L2709 to see up to date list of available request settings

nice.

Still wish I could have namespaces for the hx attributes though

oh well~

but this is much appreciated

bump