5 ms·

He might be referring to the problem that URLs are not enough to get to a certain state, which you might run into when trying to share a specific view or when y

He might be referring to the problem that URLs are not enough to get to a certain state, which you might run into when trying to share a specific view or when your browser heavily unloads your tab. I found this to be the biggest issue when building my webpage, I wanted to have a link like /blog/foo, but what exists out there is just / and the documents at /blog and /blog/foo are just the small fragments that get loaded once you click your way through / Ultimately I hacked around it by adding some js to every file beyond /, which redirected to / with some anchor, and having / restore the state through the anchor, but it doesn't look the same as regular links into a website (/#blog-foo vs /blog/foo)

hipadev23 2y ago
> I found this to be the biggest issue when building my webpage, I wanted to have a link like /blog/foo, but what exists out there is just / and the documents at /blog and /blog/foo are just the small fragments that get loaded once you click your way through Huh? /blog/foo should return the full document. Why did you do it so it depends on the user clicking through links in a certain order?
rmbyrro 2y ago
Can't see why you wouldn't be able to handle this with htmx. I see two scenarios: 1. User interacts triggering "/blog/foo", which should return a fragment You can add a "?fragment=true", or a custom header, or hidden input indicating the backend the desired behavior. 2. User's mobile browser reloads "/blog/foo" Respond with the entire page, including the fragments as if the user had interacted each step of the way.
- dietr1ch 2y ago
  And now I'm stuck replicating htmx's behaviour on the server side? Seems doable and not that much of a hassle as fragment replacements should be simple afterall, but I'm simply running my site as a static page for now and I had to hack a redirecting extension for things to sort of work.
- _heimdall 2y ago
  The "HX-Request" header is automatically included for every request triggered by HTMX. You can just check that to know if you should respond with a fragment or the full page.
  - rmbyrro 2y ago
    Thanks for pointing out. Even easier then.
    - infogulch 2y ago
      If you use HX-Request header to overload routes with both normal browser and htmx requests, remember to add `Vary: HX-Request` as well, otherwise the browser may use cached htmx requests when you reload the page.

hipadev23 2y ago

> I found this to be the biggest issue when building my webpage, I wanted to have a link like /blog/foo, but what exists out there is just / and the documents at /blog and /blog/foo are just the small fragments that get loaded once you click your way through Huh? /blog/foo should return the full document. Why did you do it so it depends on the user clicking through links in a certain order?

rmbyrro 2y ago

Can't see why you wouldn't be able to handle this with htmx. I see two scenarios: 1. User interacts triggering "/blog/foo", which should return a fragment You can add a "?fragment=true", or a custom header, or hidden input indicating the backend the desired behavior. 2. User's mobile browser reloads "/blog/foo" Respond with the entire page, including the fragments as if the user had interacted each step of the way.

dietr1ch 2y ago
And now I'm stuck replicating htmx's behaviour on the server side? Seems doable and not that much of a hassle as fragment replacements should be simple afterall, but I'm simply running my site as a static page for now and I had to hack a redirecting extension for things to sort of work.
_heimdall 2y ago
The "HX-Request" header is automatically included for every request triggered by HTMX. You can just check that to know if you should respond with a fragment or the full page.
- rmbyrro 2y ago
  Thanks for pointing out. Even easier then.
  - infogulch 2y ago
    If you use HX-Request header to overload routes with both normal browser and htmx requests, remember to add `Vary: HX-Request` as well, otherwise the browser may use cached htmx requests when you reload the page.