The new approach in Alpine 3 with Alpine.data + EventListener make some cases harder to maintain

[Niklan]

Alpine 3 introduced the way to register named data components, it's perfect, but it leads to problem with maintaining the code and problems.

I faced at least two downsides, which is not the case for Alpine 2.

№1. JS order is important, but it's reversed

Registering data via event is good on paper, but turns out not so good at practice. Especially with other technologies combined.

For example:

<script defer src="https://unpkg.com/[email protected]/dist/cdn.min.js"></script>
<script>
  document.addEventListener('alpine:init', () => {
    Alpine.data('example', () => {});
  });
</script>
<div x-data="example"></div>

This won't work, because at this point alpine:init event will be fired. So component will never be registered.

This way will also fail because Alpine is not defined at this point:

<script defer src="https://unpkg.com/[email protected]/dist/cdn.min.js"></script>
<script defer>
  Alpine.data('example', () => {});
</script>
<div x-data="example"></div>

To fix this, we should move our component to load before Alpine:

<script>
  document.addEventListener('alpine:init', () => {
    Alpine.data('example', () => {});
  });
</script>
<script defer src="https://unpkg.com/[email protected]/dist/cdn.min.js"></script>

<div x-data="example"></div>

This makes it mandatory to load the component BEFORE the Alpine.

But this is not good for some system like Drupal. We have a library system which is very clear how frontend dependencies are built. Assets can be standalone or depend on something, and someone can depend on another. So it builds a dependency tree.

For example, I define Alpine library. No problems. Then I define my component library, which depends on Alpine. This makes sense, because it's for Alpine. Drupal figures that out and build dependency tree like:

alpine
    └── my component

So my component will be attached to the page after Alpine, because it depends on it. But as said earlier this is not allowed now.

We have the way to make component load before alpine, but it makes dependency tree very complex and confusing and can potentially lead to new problems, because this is not a common case and makes no sense. Why we load the library on which we depend after the one which is using that library?

But registering data after Alpine init seems to be allowed and works! As I see, the main problem that when Alpine detects x-data="example", looking for data with such name, and then when it's not found, it leads to errors. So the real problem is: call to alpine data component should be after that component is registered. But the way it parsed and registered makes JS order important.

I see the solution for that. When Alpine detects x-data with named value, and it doesn't exist, it stops processing it. But additionally, it needs to track if data with example will be registered after that it will be initialized.

№2. Components on demand

This problem is very related to first one. For example, we have Alpine on the page but then AJAX loads JS and HTML with new component. It again can't utilize alpine:init event, because the Alpine is already on the page and initialized.

As I said, we can register Alpine.data() after it initialized, so we do it, and it works. But it leads to code like that:

let MyComponent = function () {
  Alpine.data('MyComponent', () => ({}));
}

if (typeof Alpine !== 'undefined') {
  MyComponent()
}
else {
  document.addEventListener('alpine:initializing', () => {
    MyComponent();
  });
}

Because we don't know, this component is loading after or before Alpine is initialized.

It seems the main problem is we can register named component on demand and Alpine can't handle this if detects that component usage before it registered.

[danddanddand]

Your first case, 'alpine:init' will not be fired, because it isn't dispatched until Alpine.start() and because alpine script is deferred it will not happen in sequence you describe. Using Alpine global in the callback of any of the alpine lifecycles hooks ('alpine:init', 'alpine:initialized') would be safe. The code in script with defer on it should always execute after script that isn't deferred.

The second case, I'd suggest component js code shouldn't be getting injected in your ajax call but should already be registered on page. And if you really have this requirement, you shouldn't use Alpine.data() because the hacks you'd have to do to get it to work would be fragile. If you were just relying on initTree() to be triggered using x-html it wouldn't dispatch another alpine:init and it shouldn't.

The reason the component has to be registered before alpine starts parsing page is that you'd have bunch of reference errors as alpine needs your components/stores/utils/etc to be present when it evaluates everything in your x-[whatever] directives.

Alpine.data() is just an optional tool in your belt. I choose not to use it when we migrated to V3 for completely different reasons (mostly just dev experience in IDE and already using bundle which exposes library global that hold our component structure).

[danddanddand]

@pomartel Does using document.addEventListener('alpine.init', () => { // your Alpine.data() and Alpine.store calls } ) from your application code work for you?

[pomartel]

@danddanddand Yes it works but the event listener has to be declared before Alpine is loaded. We would like to do it the other way around.

[joshhanley]

@pomartel if you are loading from NPM, you could actually make use of the same technique that is used in the CDN build of Alpine to defer the Alpine start so you can put it in your vendor file, by using queueMicrotask. See here https://github.com/alpinejs/alpine/blob/main/packages/alpinejs/builds/cdn.js

So what that would look like is

In vendor.js

import Alpine from 'alpinejs'

window.Alpine = Alpine

queueMicrotask(() => {
    Alpine.start()
})

In app.js

Alpine.data('example', () => {})

Caleb has a good episode on microtask, if your interested https://share.transistor.fm/s/ba571032

Hope this helps!

[pomartel]

@joshhanley Thanks but I am using the Rails asset pipeline which doesn't support modules and imports.

[joshhanley]

@pomartel ah right, that makes sense. Same thing applies though, the CDN uses microtask to start (basically starts right before the DOM is painted), so you shouldn't need to manually start Alpine as it starts last anyway.

Can you review my comment below which has examples of loading Alpine first and then adding the data call? As what I tested worked ok for me. Just want to confirm that you get the same result.

[pomartel]

I also opened a discussion a few hours ago related to your no 1. I struggle with the exact problem regarding the loading order. #1710

[Pronian]

I created an HTML file with the following content:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Apline load order</title>
</head>
<body>
    <script defer src="https://unpkg.com/[email protected]/dist/cdn.min.js"></script>
    <script>
        console.log('Load data script');

        document.addEventListener('alpine:init', () => {
            console.log('alpine:init');
            Alpine.data('example', () => ({
                a: 'text!',
                init() {
                    console.log('Example loaded');
                }
            }));
        });
    </script>
    <div x-data="example" x-text="a"></div>
</body>
</html>

And I got the following console output:

Load data script
alpine:init
Example loaded

I believe this works because of the defer attribute. Alpine is loaded after everything else is loaded on the page.

I also noticed that the data function you declared is returning undefined instead of an empty object:

Alpine.data('example', () => {});

It should be:

Alpine.data('example', () => ({}));

[pomartel]

@Pronian Yes, that will work! As you say, you are deferring the load of the Alpine lib so it is still loaded after you declare your components. My code organization looks more like this:

<script defer src="vendor.js"></script>
<script defer src="application.js"></script>

External dependencies are loaded in the vendor.js bundle. My application code (and Alpine.data) is loaded in the application.js bundle. Vendor goes first because the application code depends on the external libraries being loaded first (jquery for example). This is a common pattern in the Rails world with the Asset Pipeline. For now I just include the Alpine lib in the application.js bundle but it really should go in the vendor bundle!

To be clear, I had the same issue with V2 so that's nothing new. I would just hope that down the line, there will be a way to include Alpine but start it at a later stage like it's possible with Alpine.start() when loaded as a module.

[Pronian]

Ah, yes, I see. Thanks for explaining!

[danddanddand]

I added PR to support it #1721

[joshhanley]

@Niklan I may be missing something but your first example under issue 1 works fine for me. See this, you should see "working" https://codepen.io/joshhanley/pen/rNmeRWw

And second issue should be wrapped in alpine:init event listener and then it will work fine too. Same as previous example (but this has defer on both script tags), you should see "working" https://codepen.io/joshhanley/pen/ZEKWPeK

Hope this helps!

[Niklan]

@joshhanley but if we remove defer it won't work. So defer is required then? I didn't pay attention to that part, yes, I don't use defer at all, so at least Alpine should be loaded with defer? I'll try. If it works as in your first example Alpine with defer, but component isn't, it should help a lot.

[Niklan]

I did test that approach, when Alpine is loaded with defer and the components as in Alpine 2 after it. It actually helps. Thank you!

This has some aggregation downsides (Alpine can't be put into a single bundle with other vendors, because they're not defer), but this is not critical at all. At least now I can define libraries with correct dependencies and not worry about loading order, which leads to more pita than aggregation issue.

The second case working with workaround, maybe for such cases I simply won't use Alpine.data() as suggested earlier.

[joshhanley]

@Niklan yep, you need defer on Alpine CDN script tag specifically (V2 and V3 are the same about that).

Not sure what bundler you are using, but have a look at my comment above regarding how to delay start of Alpine when its bundled in with other vendors. #1705 (reply in thread)

[Shashank-Bhatt1]

@joshhanley
I was finding answer to this same question since many days and came across this thread so asking here.

If someone doesn't want to go to details of queueMicrotask then is there any chance of defining x-data (component) after Alpine.Start with confirmation of not getting error?

I have a case where my compiled file is already locked with Alpine.Start there directly after import and I am in middle of project so can't wrap it within queueMicrotask as I am not sure if it breaks anything at other places. Someone has removed compiled file from bundler(webpack config) and put it there forever as it is.

Thanks.

[joshhanley]

@Shashank-Bhatt1 honestly, I'm not sure. I would be looking at trying to find a way to rebuild your config and re-compile it with your added Alpine component (as surely that would need to be done anyway to update Alpine) but if that doesn't work, then I would just put the component definition before your bundle script and use document.addEventListener('alpine:init', () => {...}).

Hope this helps!