Using μjs on single-page static sites

[Dietr1ch]

I've started using the following pattern (more like, hack tbh) to have a static SPA site that replaces fragments,

/
├── blog
│   ├── _.html (fragment for /blog)
│   ├── index.html  (sentinel file redirecting to /?path=/blog/)
│   └── my_post
│       ├── _.html (fragment for /blog/my_post/)
│       └── index.html (sentinel file redirecting to /?path=/blog/my_post/)
└── index.html (SPA dynamically using fragments)

This works fine with HTMX because you can specify an URL for the apparent link and another for the fragment contents,

<button hx-get="/blog/my_post/_.html" hx-push-url="/blog/my_post/">My Post</button>

This way users only see the /blog/my_post/ path which works fine with the SPA redirect hack, and don't get to see the /blog/my_post/_.path which is uglier and worse, would render a broken page without the needed skeleton to contain and style it.

---

Currently the recommendation for µJS is to conditionally serve either the fragment or full page,

if ($_SERVER['HTTP_X_REQUESTED_WITH'] === 'XMLHttpRequest') {
    // µJS request — return only the fragment
    echo $fragment;
} else {
    // Normal request — return the full page
    include 'layout.php';
}

but when trying to serve from a simple file server this isn't possible and you must resort to serving from 2 different files.

Is there a way to work with a separate fragment file?

[Amaury]

For a static file server, the simplest approach is to have /blog/my_post/index.html contain the full page (skeleton + content), and let µJS extract only the content fragment client-side:

<a href="/blog/my_post/" mu-target="#content" mu-source="#content">My Post</a>

µJS fetches the full page but only injects the #content fragment into the current page. The URL pushed to history is /blog/my_post/, which is exactly what you want. And if someone loads /blog/my_post/ directly, they naturally get the full page.

If you're using a static site generator, producing full pages should be straightforward. The tradeoff is a slightly heavier response than a bare fragment, but for a static site that's usually acceptable.

That said, your use case is interesting. I'll think about adding a parameter to explicitly control the URL pushed to the browser history. No promises though!

[Dietr1ch]

Thanks for the quick reply.

Yeah, it's not too bad to bump the fragment size, and it doesn't seem too hard to refactor the generator to do so. It'd also get rid of the sentinel files that redirect to / without reaching for the 404 handler.

However, it'd cause inconsistent behaviour during cache expiration as there'd be multiple versions of the skeleton. Not much of an issue to me currently given GitHub pages' 10-minute cache expirations. I guess it just shows how awkward duplication can get.