search

bigskysoftware / htmx-extensions

164 stars 48 forks source link

Am I doing something wrong or is the `preload` extension asking the server for pages without the necessary headers? #89

Open frederikhors opened 2 months ago

frederikhors commented 2 months ago

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?

Telroshan commented 2 months ago

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

Telroshan commented 2 months ago

Moving this to the extensions repo btw

frederikhors commented 2 months ago

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.

Telroshan commented 2 months ago

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!

marisst commented 5 days ago

@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.