Am I doing something wrong or is the `preload` extension asking the server for pages without the necessary headers?
Sorry to bother you,
I'm trying these days htmx for the first time (CONGRATULATIONS!) and I'm trying right now the preload extension.
Is it correct that the preload today doesn't send headers like hx-request and hx-target?
If this is correct I'm wondering how can such an extension be useful without these headers?
The server will return a whole page on each preload-trigger and my navigation between pages in browser using htmx will never take advantage of that preload.
Simply because what I'm asking to the server are fragments and not entire pages.
Am I wrong?
Hey,
I don't use the preload extension myself, but I'm afraid the method you're suggesting (using the same endpoint and determining what to answer based on headers) wouldn't work very well with preload.
To have preload work correclty, you'd have to cache the responses by setting the Cache-Control header from the server so that when the actual request happens, the response is already ready to be processed by htmx.
AFAIK, headers will not invalidate your cache, so no matter what your hx-target is and if hx-request is sent along the request, since the endpoint is identical, you'll get the same cached response for all requests to the same endpoint (unless they bust that cache with say URL parameters). So you'll either always get a full page response which would mess up htmx, or always get a fragment response which would mess up standard page accesses by URL.
Let me know if I missed something, but I would instead encourage you to split your endpoints so that each can be cached separately and work well with the preload extension
Moving this to the extensions repo btw
the method you're suggesting (using the same endpoint and determining what to answer based on headers) wouldn't work very well with preload.
Why not?
Right now as very well explained here I'm using the same endpoint choosing what to render (between full or fragment) based on hx-request header.
Oops indeed, totally forgot about Vary, you're totally right!
Then I don't see why the extension should not send the htmx headers, so if you'd like to suggest an implementation and open a PR to address that, feel free to do so!
@frederikhors The preload extension is sending HX-Request headers when the element target is anticipated to be loaded by HTMX. This was not the case in some earlier versions of the extension, but since the addition of source: node here it has been fixed.
Please note that <a href="/link" preload> is not anticipated to be loaded by HTMX, and preload will therefore issue a regular XML request without HX-Request headers. But for elements with hx-get or data-hx-get attribute HX-Request header will be passed along with other hx values.
A more tricky case is if you use hx-boost="true" property. The current version of the extension will not add HX-Request headers to boosted hyperlinks e.g. <body hx-boost="true"><a href="/link" preload>Link</a></body>. #106 is fixing it, and if you would like to use that version of the extension already now you can access it here.
@frederikhors could you confirm if #106 (now merged) addresses all your concerns ? (new extension's version is not yet published, so you'd have to use the file directly from the repo and not the npm's one!)
@Telroshan I'm not using htmx unfortunately.
Oh I see, then I'm closing this as it sounds like solved by #106 , feel free to reopen / ping if anyone encounters this again!