Alpine v3 compatability

[allmarkedup]

Hey - this adapter is great (thank you!) but I'm just playing around with a project that is using Alpine v3.x and as far as I can tell they do not play nicely together.

Are you planning on creating a v3-compatible version at any point? Do you think it's even possible with changes to the Alpine API (i.e. Alpine.discoverUninitializedComponents etc seems to not exist anymore)?

If you are not planning on updating it I can try to dig in to see if I can figure out what might need to be done to port it over as it's pretty key for a few projects of mine.

Thanks again 👍

[SimoTod]

Hi, I'll eventually release a v3 compatibile version but i haven't looked into it yet. I think it's possible using either Alpine.start or Alpine.initTree (i think the latter has less side effects).

[HugoDF]

In the meantime here's a basic support plugin for v3 Caleb shared, not sure it captures all edge cases etc

https://gist.github.com/calebporzio/20cf74af4a015644c7bef5166cffd86c

[allmarkedup]

Thanks for the replies guys, and thanks @HugoDF for pointing me in the direction of that plugin. I've had a play with it and while everything works more or less, I get a lot of flashing across page loads of elements that are using x-show and whose visbility state is stored in localstorage. I need to get a reduced test case together to explore it more but it wasn't something I had an issue with using v2.

If I have a chance I'll have a play and see if I can contribute anything back. Thanks again for your help.

[AndreiMotinga]

do you guys have any idea how to implement this meanwhile?

I'd like to start building an app using alpine 3. seems like it is a bit nicer than v2. But can't get it to work with turbo. Could somebody please help?

[alexej-d]

This is what you need:

document.addEventListener('turbo:before-render', () => {
  let permanents = document.querySelectorAll('[data-turbo-permanent]')

  let undos = Array.from(permanents).map(el => {
      el._x_ignore = true

      return () => {
          delete el._x_ignore
      }
  })

  document.addEventListener('turbo:render', function handler() {
      while(undos.length) undos.shift()()

      document.removeEventListener('turbo:render', handler)
  })
})

I also had to add an event listener to each root element inside a template for cleanup:

<template x-for="(item, i) in items" :key="item.hash">
  <div @turbo:before-cache.document="$el.remove()">...</div>
</template>

[bep]

I have spent some time looking into this, and none of the snippets above works beyond the simplest setup. I have written some more about this here: https://github.com/alpinejs/alpine/pull/1995#issuecomment-911565806

[SimoTod]

I don't expect Alpine to work out of the box with Turbo. It might work fine for simple cases but it's likely to suffer the same issue we had with v2 (x-for, x-if, etc). After the PR to stop the mutation observer has been merged, it should be possible to port the v2 version to v3 but not being a turbo user myself, this project is not on my priority list at the minute.

[khrome83]

I really only need this to work for Turbolinks. I had no issues with the deprecated project.

[Ahmed-Elrayes]

In the meantime here's a basic support plugin for v3 Caleb shared, not sure it captures all edge cases etc

https://gist.github.com/calebporzio/20cf74af4a015644c7bef5166cffd86c

for some reason, this one doesn't work with me at all.

[bep]

I have created a gist (which I will try to remember to update if I find something more clever) with my current best approach to this:

https://gist.github.com/bep/a9809f0cb119e44e8ddbe37dd1e58b50

Note that the above requires the patch in https://github.com/alpinejs/alpine/pull/1995 to work.

There is one limitation, I guess, in the above, which I don't care too much about: Components marked with data-turbo-permanent cannot itself create more components once you have navigated (but that should be a rare requirement).

[khrome83]

So it seems like https://github.com/alpinejs/alpine/pull/2117 was added to Alpine v3 by Caleb, which should give us the ability to solve this issue.

See here - https://github.com/livewire/livewire/pull/3151#issuecomment-926020270

[bep]

@khrome83 There are a couple of unresolved issues for Turbo in Alpine V3:

1. The solution in #2117 doesn't really work with Turbo beyond its simplest setup. The only working solution I have found is to use Alpine.stopObservingMutations() (not currently exported) and then Alpine.start().
2. There are some open memory leak issues that, depending on how you use Turbo, will ... not be a great experience for people after a while. Note that fixing those should not be too hard, so we'll eventually get there.

[khrome83]

understood @bep, it does not sound like he is willing to export stopObservingMutations(). And it sounds like the defer mutations is not what is needed then.

[SimoTod]

I'm planning to have a look at v3 + Turbo next week. It's technically possible to stop the mutation observer already without that PR using a private API but it would be good if it wasn't needed because in v3 the mutation observer does other important things

[SimoTod]

I've got a working version without the need of stopping alpine mutation observer. I'll probably finish it off early next week then I'll need a few people to stress test it. Watch this space.

[bep]

understood @bep, it does not sound like he is willing to export stopObservingMutations().

That is not how I read it. Having AlpineJS work great with Turbo would be a big win for the project. But I do understand the hesitation of randomly exporting new functions from the internal API, which is why it's good to have it backed by some real data, which is why @SimoTod and others' work on this is so important/appreciated.

[SimoTod]

I actually think that Caleb accepted to expose that method. The only reason why I don't want to stop the mutation observer is because Alpine uses it to tear down components. For example, i imagine most of the fixes for the memory leaks will likely rely on the mutation observer to detect removed nodes (unless you manually call destroyTree for each component). Also, I think x-on directives using the window modifier would leak into other pages without the mutation observer. (i haven't verified though)

[bep]

@SimoTod the statement that "I don't want to stop the mutation observer is because Alpine uses it to tear down components" I suspect is a falsy one in re Turbo.

• If you want to navigate from page A to B
• Turbo caches the state of A, then replaces the body with the body of B

So, in that state shift (aka the before-cache), the state of the DOM is full of races and nothing the mutation observer can make any sensible observation about.

In page A there is a set of Alpine component that needs to be cleaned before going to B, so we can get back to A in a clean state and make sure that the memory from A is released. We know what components that is, we don't need the mutation observer to tell us.

[SimoTod]

The mutation observer on the render page detects that the old root nodes have been removed and calls destroyTree on them (which tears down the full tree when it finds alpine components).

On Fri, 8 Oct 2021, 21:23 Bjørn Erik Pedersen, @.***> wrote:

@SimoTod https://github.com/SimoTod the statement that "I don't want to stop the mutation observer is because Alpine uses it to tear down components" I suspect is a falsy one in re Turbo.

• If you want to navigate from page A to B
• Turbo caches the state of A, then replaces the body with the body of B

So, in that state shift (aka the before-cache), the state of the DOM is full of races and nothing the mutation observer can make any sensible observation about.

In page A there is a set of Alpine component that needs to be cleaned before going to B, so we can get back to A in a clean state and make sure that the memory from A is released. We know what components that is, we don't need the mutation observer to tell us.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SimoTod/alpine-turbo-drive-adapter/issues/40#issuecomment-939095617, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAJRWKBEBJJ5HLRNHIKIMTUF5HLBANCNFSM466RAOHA .

[SimoTod]

@bep this is the first draft if you want to try it out: https://gist.github.com/SimoTod/de091e93af1416a1af5ece8efc23e608

I'm still not sure about a few points so it's likely to change a bit but it should fix the core issues

[therealbenzene]

@bep this is the first draft if you want to try it out: https://gist.github.com/SimoTod/de091e93af1416a1af5ece8efc23e608

I'm still not sure about a few points so it's likely to change a bit but it should fix the core issues

This works for my use case

[Ahmed-Elrayes]

for some reason something messes up Select 2 with this method mentioned in here.

[SimoTod]

@Ahmed-Elrayes Can you please provide an example i can use and highlight the issues?

[Ahmed-Elrayes]

i can't give you an example now since i was using it on a project so i can't mess it up now, but all what i can say is my select2 uses Entangle ..etc, so when i change the values inside select2, nothing happens at all as if i haven't changed the values at all, i'm sure that my code works, and i've tried it with Alpine js V2.8.2. so when i submit my form, it gives me validation error that those fields are required.

[SimoTod]

@Ahmed-Elrayes Are we saying that the code works with alpine v3 + livewire + turbo but it breaks when adding the patch?

[Ahmed-Elrayes]

the code works perfectly, but when it comes to entangle it doesn't send the value for some reason.

[SimoTod]

I'm sorry, I find it hard to understand and help if you don't answer answer my questions or provide an example. It's not clear to me if you are saying one of the following:

• entangle doesn't work in v3
• entangle doesn't work in v3 when using turbo
• entangle doesn't work in v3 when using turbo AND the suggeated new adapter

The first one would be a livewire bug, the other 2 are possibly relevant although I'm not a Livewire user and I think Caleb posted something about making livewire compatible with Turbo.

[SimoTod]

@Ahmed-Elrayes https://github.com/livewire/turbolinks

[Ahmed-Elrayes]

oh, i see, i will be checking it thanks. as for your question i believe it is the 3rd one. also there might be a possibility that i wasn't using this adapter correctly.

[mikeychowy]

@bep this is the first draft if you want to try it out: https://gist.github.com/SimoTod/de091e93af1416a1af5ece8efc23e608

I'm still not sure about a few points so it's likely to change a bit but it should fix the core issues

Hi @SimoTod any update on this? Or will this gist be the final answer for v3? I've been using this in my local environment since a month ago with no significant problems, but I'm still hesitant on introducing it to even staging environment because it's not even a release yet.

If you're having some delay because of your IRL job, that's understandable btw, since it's release season for a lot of companies, I guess I'm just anxious due to no further comments on this. Thank you for the good work.

[SimoTod]

@mikeychowy it's safe to use as far as I know. I don't use turbo so I forgot about it. I'll tag a release over the weekend.

[tabishiqbal]

I am experiencing something similar on a rails project using alpine 3 where i get the following error

window.Alpine.discoverUninitializedComponents is not a function

[SimoTod]

@tabishiqbal The tagged release is still for Alpine v2 (Alpine.discoverUninitializedComponents is v2)

[matt-harvey]

@SimoTod Just wondering if you are planning to tag that v3 compatible release any time soon? Or are there remaining v3 compatibility issues on the current main branch that you're aware of?

[SimoTod]

There was just a minor regression with x-cloak when navigating back but it's now fixed. Tagged, better late than never. 😅

[matt-harvey]

Ah OK, nice one, thanks @SimoTod 😄