x-ignore+ initTree() (for "lazyloading") not working anymore (version >= 3.13.4)

[krausste]

Hi,
in our project we are using x-ignore plus Alpine.initTree() for lazyloading of our Alpine components.
in short: for lazyloading we remove the x-ignore attribute from an element and call Alpine.initTree(el) for that element afterwards.

The release 3.13.4 came with a change for x-ignore and init tree: 463f277
This change seems to break our feature.

I am wondering if it is attended behaviour that an element that once had an x-ignore attribute can not be initialized anymore via Alpine.initTree()? Or is a bug?

I prepared a simple example of our lazyloading approach in two versions:

1. before (version 3.13.3): https://alpinejs-xignore-issue-before.netlify.app/
2. after (latest): https://alpinejs-xignore-issue-after.netlify.app/

Thanks a lot in advance for your feedback!

[SimoTod]

Yeah, i think that line is supposed to be if (findClosest(e.parentElementl, i => i._x_ignore)) return because findClosest is also testing the starting element

[nikitaourazbaev]

Also running into this.

[SimoTod]

@krausste So, it turned out it wasn't the line in the original post (the code removes x-ignore so you can see that the subtrees initialises correctly but it skips the main element because it was marked as initialised by https://github.com/alpinejs/alpine/pull/4447/files#diff-446fd9132e92dae865fe0867395c131a4c77074eb308a22c038c07988c414dccR99 even if in reality it was skipped because of the x-ignore directives on the first run so basically x-data was never processed).

Opened #4458 to fix it which also contains a test for this use case

[krausste]

Hi @SimoTod, thank you very much for your support!
That diff explains the issue :)

[nikitaourazbaev]

@SimoTod, thanks for that PR!

There’s still one remaining case that I’m running into with initTree and Alpine >= 3.14.3, which is when a lazy-loaded component is added to a teleported element. In that case initTree won’t run because it returns after finding an _x_ignore on a parent element here:

alpine/packages/alpinejs/src/lifecycle.js

Line 89 in 60cbc24

if (findClosest(el, i => i._x_ignore)) return

That _x_ignore is on the first child of an x-teleport template.

And I’m pretty it’s added here:

alpine/packages/alpinejs/src/directives/x-teleport.js

Line 55 in 60cbc24

clone._x_ignore = true

Should that _x_ignore on the cloned teleported node eventually be removed?

[SimoTod]

Yeah, the case you described is likely introduced by that change. Unfortunately I don't know the reason for that change as it was introduced by the maintainer (i suppose something to do with Livewire but I'm not sure)