|
|
|
|
|
by wtatum
1589 days ago
|
|
I find this approach really interesting and have spent some time browsing HTMX docs in the past but there's one thing I feel like I'm missing. Most existing server-side rendering frameworks / templating engines I'm familiar with tend to assume they're rending a complete HTML document rather than just an HTML "fragment" needed by something like HTMX to do dynamic page updates. What does the server-side look like with an HDA stack look like in practice? From TFA, they use the example POST /search where a snippet of HTML is returned from the /search call and is injected into the page. What would the backend look like? Presumably you still want HTML templating and component-based design instead of regressing to hand building the response, but what frameworks/packages/utilities exist in that space that don't assume they are rendering a complete page? In particular, "whole app" frameworks like NextJS or SvelteKit are automatically mapping URLs onto a root component that is automatically decorated with all the chrome needed to make it a complete page. Is the approach to just overload those root page components and take all the chrome away to get a partial document in the response? |
|
htmx includes headers, `HX-Request` which will be true if the request is an htmx request, and `HX-Target` that will be the id of the target element, if any, that allow you to modify your response as needed on the server side. This is very common: you have a single URL that satisfies both the htmx and non-htmx request (e.g. /search) and in the htmx case, you don't render the surrounding layout, but in the "normal" case you do.
If a server side option isn't available or is inconvenient, you can instead use the client-side attribute `hx-select` to select a bit of the HTML from the response for inclusion in the DOM.