Breaks when visiting a page using Alpine+Livewire's entagle with Turbo

[tonysm]

Hey, folks. I'm having an issue when making a Turbo visit to a page that uses Alpine+Livewire's entangle. It throws an error in the console and the components don't work anymore. It works when I refresh the page, though (first browser refresh to that page).

This error can be found in a Jetstream's clean install, after upgrading Alpine to v3 and manually installing Turbo (npm install @hotwired/turbo -D). The user profile or the team settings page use entangle for the modals.

I have an example application deployed that showcases the error: https://turbo-laravel.tonysm.com/ (you can use whatever dummy email+password to register and see it for yourself). Source code is here, here's the commit with the Laravel+Alpine+Livewire+Turbo upgrades.

[tonysm]

This is the missing piece to get Livewire+Alpine working fully with Turbo. I've tried to understand where the problem lies, but no luck. I couldn't wrap my head around entangle.

I was able to trace it to this line in the x-data directive. When an Alpine component that uses entangle is passed to the evaluate function, it returns undefined, which causes the error I'm seeing. It only happens when the page is rendered from Turbo's session cache, though. So, the first-page refresh to a page that uses entangle works. Navigating to that page from another page (with Turbo), breaks.

The expression that it tried to evaluate is here (although I don't think it's valuable, I think - it's from one of the modals that come with Jetstream)

{
        show: window.Livewire.find('YwxlCoLFxt8s4r7zNqsA').entangle('currentlyManagingRole') ,
        focusables() {
            // All focusable element types...
            let selector = 'a, button, input, textarea, select, details, [tabindex]:not([tabindex=\'-1\'])'

            return [...$el.querySelectorAll(selector)]
                // All non-disabled elements...
                .filter(el => ! el.hasAttribute('disabled'))
        },
        firstFocusable() { return this.focusables()[0] },
        lastFocusable() { return this.focusables().slice(-1)[0] },
        nextFocusable() { return this.focusables()[this.nextFocusableIndex()] || this.firstFocusable() },
        prevFocusable() { return this.focusables()[this.prevFocusableIndex()] || this.lastFocusable() },
        nextFocusableIndex() { return (this.focusables().indexOf(document.activeElement) + 1) % (this.focusables().length + 1) },
        prevFocusableIndex() { return Math.max(0, this.focusables().indexOf(document.activeElement)) -1 },
    }

[dsazup]

@SimoTod thanks for the suggestion, but that doesn't seem to work. It fails on this line

alpine/packages/alpinejs/src/mutation.js

Line 145 in c4e0549

onElAddeds.forEach(i => i(node))

and this isn't guarded by _x_ignoreMutationObserver. I was playing around with alpine and what I found works is exposing stopObservingMutations method. In the turbo:before-render I can then call Alpine.stopObservingMutations() and then in the turbo:render I can call window.Livewire.restart() and Alpine.start(). Not sure if starting alpine again is a good way, but at least this seems to work perfectly.

[SimoTod]

I see, Alpine v2 was exposing something to start and stop the observer, i was using it in my bridge library. That shouldn't be any harm in starting Alpine at that point since it's a new page.
I think you can send a PR and explain to Caleb the use case. It would probably get accepted.

[bep]

Probably related to SimoTod/alpine-turbo-drive-adapter#40 -- which I suspect will not be possible to fix without a way to pause/start the observer. A PR from someone would be much appreciated!

[dsazup]

Submitted a PR here: #1995 feel free to provide some feedback.

[SimoTod]

👍 I think start is good because it also fires the alpine events so it exactly replicates the normal page load behaviour. The only thing i would check is if the mutation oberver duplicates the calls after calling start again.

I suspect those arrays (https://github.com/alpinejs/alpine/blob/main/packages/alpinejs/src/mutation.js#L1-L3) already contains the callbacks. The effect would be that new components generated by genuine mutations later on would be initialised twice so x-on's could be fired twice after.

[calebporzio]

Solution here: livewire/livewire#3151 (comment)