4 ms·
Haha ok let me expand, I didn't actually mean only styling but layouting as well. Consider this example from htmx.org: <html> <body> <div>Account n
by jdthedisciple 4y ago
Haha ok let me expand, I didn't actually mean only styling but layouting as well. Consider this example from htmx.org:
<html>
<body>
<div>Account number: 12345</div>
<div>Balance: $100.00 USD</div>
<div>Links:
<a href="/accounts/12345/deposits">deposits</a>
<a href="/accounts/12345/withdrawals">withdrawals</a>
<a href="/accounts/12345/transfers">transfers</a>
<a href="/accounts/12345/close-requests">close-requests</a>
</div>
<body>
</html>
What I don't get is who says I want to have all of that html displayed in this exact form anywhere I make a request for account info? Say I want to only display the Account balance - are you telling me client has to cut and parse the html response for that? How much html parsing is that gonna be all over a web page?
Also the example I gave below about setting the css classes and ids inside the returned html elements...
- quickthrower2 4y agoNo. You would not reuse the “partial view” API call by parsing and adapting the result. You make a different partial view for each instance. 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.
- geoffeg 4y agoI imagine it would be somewhat easy to provide a way for the APIs to include a way to filter the resulting HTML they produce. A CSS path as a URL parameter that the API runs to only return the content of the CSS path. 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.
- quickthrower2 4y agoYeah there could be some kind of “varnish-like” layer outside the app server designed to modify the response to the required “lens” that is specified in a header. 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.
- geoffeg 4y agoLooks like HTMX already has something like this, just client-side. https://htmx.org/attributes/hx-select/ https://htmx.org/attributes/hx-select/ That's probably safer in some ways than filtering server side.
- recursivedoubts 4y agohtmx supports a few different ways to take complete page responses and wire them in to an existing page: https://htmx.org/attributes/hx-select/ https://htmx.org/attributes/hx-select/ https://htmx.org/attributes/hx-select-oob/ https://htmx.org/attributes/hx-select-oob/ https://htmx.org/extensions/morphdom-swap/ https://htmx.org/extensions/morphdom-swap/
- BeefySwain 4y agoOh wow, this feels like a somewhat buried lede for how you would actually use HTMX in the real world. I've played with it quite a bit and didn't realize this was a pattern that was actually viable. I think it would really benefit the project to have more documentation/examples of architectural patterns for how an app might use HTMX.
- recursivedoubts 4y agoyeah, a problem w/ htmx being a backend-agnostic extension to HTML is that you need to produce examples for all the popular backends. there is a page here with links to various repos people have put together: https://htmx.org/server-examples/ https://htmx.org/server-examples/