This is my slight “ugh” against it and why I prefer the idea of the frameworks that just get the entire page and do a differential swap because architecturally that is simpler. No need to create lots of weird little partials and wire them up.
This is my slight “ugh” against it and why I prefer the idea of the frameworks that just get the entire page and do a differential swap because architecturally that is simpler. No need to create lots of weird little partials and wire them up.
https://htmx.org/attributes/hx-select/
I think it would really benefit the project to have more documentation/examples of architectural patterns for how an app might use HTMX.
there is a page here with links to various repos people have put together:
There's probably some kind of balance between giving every partial it's own URL and allowing each partial to support a filtered response. You could write a little middleware for your http server to support the filtered response on every endpoint that returns HTML.
This would process the app response and filters/zoom to the part of the doc you want. The app could be agnostic and it reduces the amount of crap sent over the wire.
That's probably safer in some ways than filtering server side.