Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
frederikhors opened this issue Sep 5, 2024 · 5 comments
Open

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

frederikhors opened this issue Sep 5, 2024 · 5 comments

Comments

@frederikhors
Copy link

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
Copy link
Collaborator

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
Copy link
Collaborator

Moving this to the extensions repo btw

@Telroshan Telroshan transferred this issue from bigskysoftware/htmx Sep 6, 2024
@frederikhors
Copy link
Author

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
Copy link
Collaborator

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 marisst mentioned this issue Nov 5, 2024
Open
@marisst
Copy link

marisst commented Nov 6, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Telroshan @marisst @frederikhors