HTMX Boost issue with Alpine-based Navigation component, solution reinit-Tree Alpine? #4485

bluz71 · 2024-12-23T04:41:56Z

bluz71
Dec 23, 2024

Hello crew,

I encountered an issue with my mobile navigation menu component (implemented in Alpine.js) automatically being open when navigating from page to page with HTMX Boost.

The component starts like:

<header
  x-data="{ mobileNavOpen: false }"
  id="page-header"
  class="sticky top-0 z-50 flex flex-none items-center bg-gray-900 py-4"
>

Obviously the menu should be closed (the default Alpine state as denoted by mobileNavOpen ) when navigating to a new page. But instead it automatically is open, that is weird.

Take away HTMX Boost, everything works as expected.

Boost is similar to the old Rails Turbolinks, it does AJAX GET and <body> swap such that the navigation feels like an SPA navigation. I am not sure what it does with JS, obviously something that makes this Alpine component fail.

I chatted with Claude.ai and we both conclude that it appears to be some sort of Alpine initialisation issue. Adding this code to my top-level application.js file solved the issue:

    // Reinitialize Alpine after each "boosted" page change.
    htmx.on("htmx:afterSettle", (event) => {
      if (event.detail.boosted) {
        Alpine.destroyTree(document.body)
        Alpine.initTree(document.body)
      }
    })

When HTMX settling after a boost page change reinitialise Alpine manually. This seems to work. I infer this is somewhat similar to starting Alpine from scratch when doing a normal Multi-Page-App browser page change (JS and CSS start from scratch including Alpine.start()).

Is this bad? Are there better solutions?

SimoTod · 2024-12-23T08:59:03Z

SimoTod
Dec 23, 2024
Collaborator

Do you have a simplified example? Are you swapping the whole body or just part of the page?

0 replies

bluz71 · 2024-12-23T09:55:05Z

bluz71
Dec 23, 2024
Author

Whole body, that is what hx-boost does, similar to Turbolinks or GitHub pjax.

At the moment I don’t have a simple example.

The JavaScript re-initialise snippet solves the issue.

Is it a good or bad thing that I use destroy and initTree?

8 replies

SimoTod Dec 26, 2024
Collaborator

Yeah, there's a plugin for it, you don't have to hook into htmx (btw, htmx offers events so you could). The plugin won't resolve your use case anyway, I'm not suggesting you should use it: I was just curious about what was changing the flag since it should use whatever comes from the new page.

I haven't had time to look at your repo over Christmas but I'll definitely have a look during the next few days because it's a weird behaviour.

Re destroyTree and initTree, I don't think they will disappear unless there's a new major release but there's no Alpine team so I can't guarantee it, all design decisions are taken by the maintainer.

bluz71 Dec 26, 2024
Author

I believe the plugin you are thinking about is HTMX alpine-morph.

When doing a partial page update (within current page) one can use this plugin to morph into the current page using Alpine's official morph plugin.

However, hx-boost is different in that I can't see a place to hook into this operation to use Alpine's morph vs what HTMX will do internally which is bog-standard DOM <body> swapping.

As soon as the <body> is swapped all the Alpine state & listeners are lost UNLESS Alpine is re-initialised.

So it seems to me.

I am very surprised more HTMX & Alpine users are not hitting this.

SimoTod Dec 27, 2024
Collaborator

Doesn't hx-boost use whatever swapping strategy is used by htmx? If so, it should use alpine morph when you import the plugin without you doing anything special but again it's not really relevant to your issue (i was asking in case that was the root cause but it isn't).

I think you can use your initial suggestion. As soon as I look at your repo I'll let you know if I can see what is going on as it shouldn't really happen.

bluz71 Dec 27, 2024
Author

I am not a HTMX expert.

But, no, that is not my understanding.

HTMX, I believe, will use the default HTMX swapping mechanism unless you specify a different mechanism for a particular swap operation.

See the HTMX Alpine-Morph notes, in this example notice:

<body>
  <div hx-target="this" hx-ext="alpine-morph" hx-swap="morph">
      <div x-data="{ count: 0, replaced: false,
                     message: 'Change me, then press the button!' }">
          <input type="text" x-model="message">
          <div x-text="count"></div>
          <button x-bind:style="replaced && {'backgroundColor': '#fecaca'}"
                  x-on:click="replaced = true; count++"
                  hx-get="/swap">
            Morph
          </button>
      </div>
  </div>
</body>

On a page I could have a swap using this hx-ext="alpine-morph" and have another <div> somewhere else using the standard HTMX swap mechanism.

That is my understanding.

So, no, I do not believe just installed the HTMX Alpine-Morph extension will do anything. One needs to explicitly call it. And with hx-boost I don't know how to do that; actually I suspect it is not possible.

bluz71 Dec 27, 2024
Author

Note, all my testing has been done with HTMX Alpine-Morph plugin registered and loaded.

However, something somewhere needs to call it.

Changing the <body> as follows does not work:

  <body
    hx-boost="true"
    hx-ext="preload"
    hx-ext="alpine-morph"
    hx-swap="morph"
  >

Noting, the <a> is far below the <body> tag.

I suspect hx-boost internally does not hook into user morph override.

bluz71 · 2024-12-25T00:59:11Z

bluz71
Dec 25, 2024
Author

@SimoTod,

I will try and produce a minimal repo highlighting this issue.

I am normally a Rails person, but that is too heavy for this. I will instead use Astro (server-side Node).

Stay tuned.

0 replies

bluz71 · 2024-12-25T02:36:36Z

bluz71
Dec 25, 2024
Author

@SimoTod,

I have created an Astro project highlighting the interaction I see between HTMX hx-boost and an Alpine.js based Navigation bar.

Steps:

git clone https://github.com/bluz71/htmx-boost-with-alpine
cd htmx-boost-with-alpine
npm install
npm run dev
With browser go to localhost:4321
Click About and Details links, notice the Navigation menu automatically opens

Now open up src/layouts/Layout.astro and delete hx-boost="true" from the <body> tag, and repeat clicking of About and Details links. We are now using standard browser link handling, no issue. On a page change from About to Details, JavaScript (including Alpine) and CSS will be loaded from scratch.

Now add hx-boost="true" back into the <body> tag and uncomment my Alpine.js re-initialisation code (starting line 49 of the same file):

  htmx.on("htmx:afterSettle", (event) => {
    if (event.detail.boosted) {
      Alpine.destroyTree(document.body)
      Alpine.initTree(document.body)
    }
  })

This event handler runs after a HTMX hx-boost has occurred and re-initises Alpine. It runs well.

The actual navigation bar code lives in src/components/Header.astro, it is Tailwind component from the library I use. I did not create this component myself, so I can not vouch for the quality of the code.

Noting, HTMX boost is intercepting the click event on <a> tags and issuing an AJAX GET request and then swaps the <body> tag of the response into the DOM. I don't know what it does with JavaScript, maybe nothing?

So the <body> with existing Alpine event handlers will be blown away with a new <body> containing Alpine content but with event handlers not initialised?

0 replies

bluz71 · 2024-12-25T03:47:57Z

bluz71
Dec 25, 2024
Author

I timed events:

  Alpine.destroyTree(document.body)
  Alpine.initTree(document.body)

This usually takes about 1-2ms in totality.

  Alpine.start()

And this usually takes 2.5-3ms.

So when doing normal page change (not hx-boost) the cost of starting Alpine is 2.5-3ms.

When doing a hx-boost page change the cost of re-initing Alpine (via destroy/initTree) is about 1/3rd of a full Alpine start.

Also, HTMX <body> swap appears to take around 25ms vs a normal DOM Content Load time of around 75ms (for a normal browser GET request).

Interesting.

0 replies

SimoTod · 2024-12-28T00:30:36Z

SimoTod
Dec 28, 2024
Collaborator

I haven't got to the bottom of the issue but I think it's something HTMX does when it detect the same id, I suspect it kind of reverts the style property added by x-show after the swap. If you remove the id, it works as expected.

For example, if you pause the mutation observer before the swap, defferring all the Alpine effect until after the DOM settles, it also works with the ID.

  htmx.on("htmx:beforeSwap", () => {Alpine.deferMutations()})
  htmx.on("htmx:afterSettle", () => {Alpine.flushAndStopDeferringMutations()})

I couldn't find anything in the HTMX documentation about the ID behaviour but that doesn't come from Alpine.

0 replies

bluz71 · 2024-12-28T00:51:12Z

bluz71
Dec 28, 2024
Author

@SimoTod,

My interpretation is different.

Just speculation on my part, and I could be completely wrong.

hx-boost <a> tags result in an AJAX get call with the response <body> swapped into the DOM replacing the current <body>. Much like Rails Turbolinks (back in the day) or Github pjax.

When it does the swap that all existing Alpine DOM event listeners are destroyed (because the <body> tag has been swapped)..

The new <body> comes in, including the Alpine header component with x-data="{ mobileNavOpen: false }", however, since Alpine DOM listeners have been destroyed by the <body> swap, the Alpine header component is visible because there are no listeners running to hide it.

However, re-initialising Alpine via destroyTree / initTree after the swap re-establishes Alpine listeners and the header component is made invisible by default. Problem goes away.

If hx-boost could use Alpine morph to replace the <body> tag I believe this would not be a problem since the Alpine DOM listeners would be preserved. However, I don't see a way to do that with hx-boost. With hx-get yes it is possible, and recommended, to use Alpine morph.

Again, I am not HTMX or Alpine expert, but above is my interpretation of what I am seeing.

2 replies

SimoTod Dec 28, 2024
Collaborator

Nah, that's wrong. When new HTML comes in, it gets automatically initialised by alpine (Alpine runs a mutation observer to detect new components, directives, etc).

If you try the snippet above, you will see that the components works without having to call initTree.

I've actually found the relevant paragraph under https://htmx.org/docs/#details:

When new content is received from a server, before the content is swapped in, the existing content of the page is examined 
for elements that match by the id attribute. If a match is found for an element in the new content, the attributes of the old 
content are copied onto the new element before the swap occurs. The new content is then swapped in, but with the old 
attribute values. Finally, the new attribute values are swapped in, after a “settle” delay (20ms by default). A little crazy, but 
this is what allows CSS transitions to work without any javascript by the developer.

So what happens there is:

HTMX detects an ID so it reads the value of the attributes.
It merges the attributes from the old page (which are the same) and swap the dom
Alpine sees new HTML, the mutation observer kick in and process x-show adding the style="display: none" attribute
the DOM settles and HTMX revert the attributes to the ones received from the original response (so it removes the style attribute).

I think your options are:

no ID on the nav tag
set htmx.config.defaultSettleDelay to 0 if you don't care need CSS transitions
use Alpine.deferMutations and Alpine.flushAndStopDeferringMutations to ensure directives are processed after the DOM is settled
and yeah, after settling the dom, destroy every alpine component and re init them as you suggested

3 is probably slightly more performant than 4 since each directive is processed once instead of twice.
2 makes your page even faster if you don't have to care about CSS transitions (probably you don't, I think here is HTMX trying to be too clever for some edge cases)
1 works but I assume you don't want to remove the ID

bluz71 Dec 28, 2024
Author

Interesting, I was indeed wrong. Thanks for the clarification.

Note, I did not create the <header> component (including the ID).

That comes from the 3rd party Tailwind + UI component library I use. Basically I cut-and-paste the components into my application.

no ID - I don't know what the effect of that will be unless I test it (again not my code)
I prefer to keep CSS transitions, I will be using HTMX transitions for fade-in / fade-out effects
Interesting, I will experiment with these
current solution.

I would be willing to do 1., I am not sure what the ramifications are for this 3rd party component. I could just remove it and see what happens.

appeals to me since other components from my 3rd party Tailwind + Alpine UI component library may also be using IDs.

bluz71 · 2024-12-28T01:35:00Z

bluz71
Dec 28, 2024
Author

Just tested, this works well:

htmx.on("htmx:beforeSwap", (event) => {
  if (
    event.detail.target.tagName === "BODY" && event.detail.boosted === true)
  ) {
    Alpine.deferMutations()
  }
})

htmx.on("htmx:afterSettle", (event) => {
  if (
    event.detail.target.tagName === "BODY" && event.detail.boosted === true)
  ) {
    Alpine.flushAndStopDeferringMutations()
  }
})

Only do Alpine mutation pauses for <body> swaps that are hx-boosted. For HTMX partial page updates such as hx-get, hx-post, don't do anything (use HTMX Alpine Morph plugin to preserve Alpine state).

So, you believe that is more performant than doing this:

htmx.on("htmx:afterSettle", (event) => {
  if (
    event.detail.target.tagName === "BODY" && event.detail.boosted === true)
  ) {
    Alpine.destroyTree(document.body)
    Alpine.initTree(document.body)
  }
})

0 replies

bluz71 · 2024-12-28T01:56:40Z

bluz71
Dec 28, 2024
Author

I did some crude timings for the defer / stopDefer solution vs destroyTree / initTree.

Both hover around 1ms combined, but generally it seems destroyTree / initTree is generally a bit faster.

defer (add defer took and stop defer took times together):

reinit (this combines destroyTree and initTree into one timing):

Counter-intuitive.

I am inclined to go with destroyTree / initTree, it seems faster.

1 reply

SimoTod Dec 28, 2024
Collaborator

Hard to time with a standard page and under 1ms but when you add something to a page the mutation observer in alpine will init new components and process new directives in both scenarios.

If you destroy the tree and re init it, you are just doing the same operation twice. If you defer, you are doing it once.

You can try adding an x-effect with a console log and it will print out twice when you destroy/reinit.

However I suspect init tree is faster then the mutation observer itself (the code in the mutation observer is more complex because it accounts for a lot of edge cases). Because they both start after settling the dom, this could explain what you are seeing.

Both solutions are fast unless you have a really complex component with an x-for rendering thousands of items.

bluz71 · 2024-12-28T07:37:02Z

bluz71
Dec 28, 2024
Author

Thanks @SimoTod,

My inclination is that destroyTree / initTree is actually preferred here because conceptually I am transitioning to a whole new page, so Alpine.js starting from scratch makes sense in how the web used to work for standard link navigation.

If I remove hx-boost from <body>, going old-school, then when I click a link Alpine would also start from scratch on the new page via Alpine.start() (this operation takes around 2.5-3ms).

hx-boost is just an AJAX trick to make page navigation feel more like a Single-Page-App navigation, avoiding the flush-of-unstyled-content.

If pause / resume mutation observer was faster than destroy / initTree that would a factor in its favour. It seems slower, not slow, but slower than destroy / initTree.

Overall I am pleased where I now am. Whenever a hx-boost link tag is activated I re-init Alpine; which takes less than 1ms compared with DOM <body swap which takes 25ms. So the Alpine re-init really is no cost at all, it actually is much faster the Alpine.start().

I don't doubt this whole issue likely is to work around HTMX id quirks.

Thank you @SimoTod for your assistance and interest. Hopefully this conversation may be useful to the next person who use Alpine.js with HTMX and then enables hx-boost only to encounter weird issues.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

HTMX Boost issue with Alpine-based Navigation component, solution reinit-Tree Alpine? #4485

{{title}}

Replies: 10 comments 11 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

HTMX Boost issue with Alpine-based Navigation component, solution reinit-Tree Alpine? #4485

bluz71 Dec 23, 2024

Replies: 10 comments · 11 replies

SimoTod Dec 23, 2024 Collaborator

bluz71 Dec 23, 2024 Author

SimoTod Dec 26, 2024 Collaborator

bluz71 Dec 26, 2024 Author

SimoTod Dec 27, 2024 Collaborator

bluz71 Dec 27, 2024 Author

bluz71 Dec 27, 2024 Author

bluz71 Dec 25, 2024 Author

bluz71 Dec 25, 2024 Author

bluz71 Dec 25, 2024 Author

SimoTod Dec 28, 2024 Collaborator

bluz71 Dec 28, 2024 Author

SimoTod Dec 28, 2024 Collaborator

bluz71 Dec 28, 2024 Author

bluz71 Dec 28, 2024 Author

bluz71 Dec 28, 2024 Author

SimoTod Dec 28, 2024 Collaborator

bluz71 Dec 28, 2024 Author

bluz71
Dec 23, 2024

Replies: 10 comments 11 replies

SimoTod
Dec 23, 2024
Collaborator

bluz71
Dec 23, 2024
Author

SimoTod Dec 26, 2024
Collaborator

bluz71 Dec 26, 2024
Author

SimoTod Dec 27, 2024
Collaborator

bluz71 Dec 27, 2024
Author

bluz71 Dec 27, 2024
Author

bluz71
Dec 25, 2024
Author

bluz71
Dec 25, 2024
Author

bluz71
Dec 25, 2024
Author

SimoTod
Dec 28, 2024
Collaborator

bluz71
Dec 28, 2024
Author

SimoTod Dec 28, 2024
Collaborator

bluz71 Dec 28, 2024
Author

bluz71
Dec 28, 2024
Author

bluz71
Dec 28, 2024
Author

SimoTod Dec 28, 2024
Collaborator

bluz71
Dec 28, 2024
Author