Does Leptos allow Partials/HTML Fragments? Like HTMX or Fresh

[Sleepful]

HTMX and Fresh allows a GET/POST request submitted through form or a tags to fetch only partial HTML content, and insert it or replace a small piece of the current page.

Is this something that Leptos supports or plans to support?

• Htmx
• Fresh Partials

[gbj]

Leptos can be compatible with HTMX's way of doing this, of course, if you simply want to use Leptos for server-side templating and use HTMX to fetch partials from the frontend.

I do have plans for client-side routing with islands -- i.e., it works as the current islands mode does, but rather than full-page refreshes it enables client-side routing. (See the roadmap issue.) That works is being enabled by the current rewrite that is moving toward 0.7. This model is relatively similar to something like React Server Components. I haven't used Fresh Partials but it looks somewhat similar to that but maybe less manual? Not sure.

[Sleepful]

In Astro the Page Partials are meant to be used in conjunction with HTMX. Astro adds the feature by allowing routes in the server that return only a "partial" piece of the HTML page (not the entire HTML document), and HTMX handles the DOM changes in the client.

Like you said, this is very similar to just using leptos with the experimental-islands feature flag to turn the app into an MPA and then sprinkle some HTMX.

Fresh is the same idea, the difference is that Fresh doesn't rely on HTMX, it uses its own code to update the client.

The idea behind partials is to start with a "MPA" style app, and then add small pieces of client-side navigation that work through fetch to create interactivity through the server.

The partials enable this client-side navigation for a sub-section of the page (similar to the isolation of islands). Inside this sub-section of the page, the actions that trigger a page load (like an anchor tag) no longer trigger a full-page reload, instead a fetch request is used. The server is expected to reply with an HTML response to the fetch request, and annotate this response with an ID. Once the client receives the response, it places the response on a specific HTML DOM node which should match in ID with the response.

---

The island-navigation that you mention sounds rather similar, albeit maybe more complicated in implementation :)

I think the key point to make HTMX (or island-navigation) work properly, is the support for routes that return HTML fragments (like Astro mentions on their Page Partials docs).

[Sleepful]

I am not sure, but I suspect Page Partials are a stronger primitive (concept) than client-side navigation for islands. A Page Partial could be placed inside or outside an island. And the response could be static HTML or include an Island inside.

[Sleepful]

One last thing, just in case it helps you think about this? maybe I am just creating confusion lol.

I noticed that you wrote this on the roadmap:

when navigating, we can actually go to the server and ask only for a certain chunk of the page

I am not sure I understand your thought-process here, but just FYI, the Partial routes that I have used are usually their own endpoint, independent of other endpoints, and meant to be used only by Partial-enabled navigation.

[Sleepful]

Although TBH I don't understand the idea of a "persistent island", in my mind if a full page reload occurs then all islands are gone, intentionally. If a Page Partial is loaded then islands are unbothered, no special case is needed for them to maintain their state.

Caveat: maybe to avoid a weird situation, don't use a Partial Page response to replace DOM Nodes in the Island that include an event handler, that might be confusing, but I don't see why this would be necessary.