Alpine v3 compatability about alpine-turbo-drive-adapter HOT 36 CLOSED

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.

from alpine-turbo-drive-adapter.

@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.

from alpine-turbo-drive-adapter.

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).

from alpine-turbo-drive-adapter.

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

from alpine-turbo-drive-adapter.

@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

from alpine-turbo-drive-adapter.

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

from alpine-turbo-drive-adapter.

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.

from alpine-turbo-drive-adapter.

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>

from alpine-turbo-drive-adapter.

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.

from alpine-turbo-drive-adapter.

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.

from alpine-turbo-drive-adapter.

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?

from alpine-turbo-drive-adapter.

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: alpinejs/alpine#1995 (comment)

from alpine-turbo-drive-adapter.

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

from alpine-turbo-drive-adapter.

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.

from alpine-turbo-drive-adapter.

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 alpinejs/alpine#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).

from alpine-turbo-drive-adapter.

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

See here - livewire/livewire#3151 (comment)

from alpine-turbo-drive-adapter.

@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.

from alpine-turbo-drive-adapter.

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.

from alpine-turbo-drive-adapter.

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.

from alpine-turbo-drive-adapter.

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)

from alpine-turbo-drive-adapter.

@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.

from alpine-turbo-drive-adapter.

from alpine-turbo-drive-adapter.

@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

from alpine-turbo-drive-adapter.

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

from alpine-turbo-drive-adapter.

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

from alpine-turbo-drive-adapter.

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.

from alpine-turbo-drive-adapter.

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

from alpine-turbo-drive-adapter.

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

from alpine-turbo-drive-adapter.

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.

from alpine-turbo-drive-adapter.

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

from alpine-turbo-drive-adapter.

@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.

from alpine-turbo-drive-adapter.

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

from alpine-turbo-drive-adapter.

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

from alpine-turbo-drive-adapter.

@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?

from alpine-turbo-drive-adapter.

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

from alpine-turbo-drive-adapter.

Ah OK, nice one, thanks @SimoTod 😄

from alpine-turbo-drive-adapter.