Questions about hx-boost behavior

[jreviews]

Using the extensions system, I wrote some functionality to implement a different history caching mechanism. To do that I also used the global htmx configuration to change the default values for:

• historyEnabled: false
• defaultSwapStyle: outerHTML

Changing these values globally completely breaks the hx-boost functionality.

Also, if the boosted element has a parent with an hx-target, hx-vals or hx-include attributes, these are used by the boost request.

While it is possible to force some of these values back to what they need to be using additional attributes:

<a href="/some-page" hx-boost="true" hx-target="body" hx-params="none" hx-swap="innerHTML">link</a>

<div hx-boost="true" hx-params="none" hx-target="body" hx-swap="innerHTML">
   <a href="/some-page">link</a>
</div>

The same is not true for the history value, since historyEnabled is global-only and cannot be controlled for individual requests/elements.

If boosting is meant to be a progressive enhancement for links and forms, and we already have the option to load HTML partials using all the other hx-[request] attributes. Shouldn't the boosting functionality remain consistent regardless of global config and parent attributes?

[1cg]

I agree, this is a bug. I have fixed it with 1a6f9b1

[jreviews]

Thanks @1cg. I took a look at the fix, and seems like it's only for the swap style. What about when caching is disabled globally or when a boosted element has an ancestor with the hx attributes i mentioned? It would still break in those cases, no?

[1cg]

mm good point, we should explicitly override them rather than defaulting...

more work tomorrow

[1cg]

OK, I looked at this a bit more. I will definitely handle the parent hx-swap issue. The history one is a bit more difficult due to the way things are implemented, it's more of an all on all off situation. Maybe we can discuss what you are doing with history and figure out if there is a cleaner way to surface that ability in htmx, without switching off history entirely? Maybe a plugin entrypoint?

[1cg]

Actually, sitting here thinking about it... if a parent has an hx-swap on it, that probably should be inherited, even by boosted elements.That can be used to modify the way boosted elements swap, which is a valid use case. I'm backing off on implementing that...

[jreviews]

If boost works with swap, vals, target and include attributes, isn't it then just another instance of hx-get. My initial understanding of boost, which may very well be wrong, was that it would behave like a standard link, but swap the body without a page re-load, and without being affected by other hx attributes. If I need something different, then I can always use hx-get.

For me, an hx-history or hx-cache attribute, that is inherited by child elements, and allows overriding (disabling) the global history configuration per request would be very useful and provide more flexibility. Or even the ability to do it within htmx:configRequest so it applies just to that request.

I am implementing a component-based caching approach where only the component HTML response is pushed to the browser history. Then on popstate it also replaces just the affected component.