Multiple Alpinejs instances on one page?

[hirasso]

Hi there! I have a scenario where I have to run multiple independent Alpine instances on one page (two custom plugins that are completely unrelated and could be installed together or alone). I'm using npm/webpack in both of these plugins. How can I prevent collisions with the two Alpine packages?

This is the best I could come up with until now (simplified code):

import Alpine from 'alpinejs'
import MyComponent from './components/alpine/MyComponent/MyComponent.js'

if( !window.Alpine ) window.Alpine = Alpine;

window.Alpine.data('MyComponent', options => MyComponent(options))

let alpineAlreadyStarted = false

document.addEventListener('alpine:init', e => alpineAlreadyStarted = true)

window.addEventListener('DOMContentLoaded', e => {
  if( !alpineAlreadyStarted ) window.Alpine.start()
})

Basically, I am re-using the window global Alpine in both of my plugins, if it already exists, and only start it once on DOMContentLoaded. That way, I can finish all Alpine.data calls before Alpine is started. Less then ideal, I know ;)

Maybe an alternative approach could be to use some unique prefix for each of my plugins like Alpine.prefix('ax-') and Alpine.prefix('bx-')? Of course, then I would loose the @ shortcuts for directives...

Does anyone have an idea how this could be solved in a cleaner way?

[zakutnya]

@hirasso, i'm not here for the prefix feature, but to thank you for window.Alpine existance checking solution. helped me very much, thank you!

[alexmacarthur]

I'd also be interested in the ability to customize the prefix! I'm using Alpine to manage interactivity on JamComments, and don't want to worry about potential conflicts w/ another version of the library loaded on the page.

[ekwoka]

I'd suggest finding a better way to deconflict.

Otherwise you're just repeating the age of jQuery sites where every site has 16 version of jQuery loading.

[alexmacarthur]

That's a good point.

[hirasso]

I'd suggest finding a better way to deconflict.

Otherwise you're just repeating the age of jQuery sites where every site has 16 version of jQuery loading.

@ekwoka do you have a rough idea how this kind of scenario could be handled better?

[ekwoka]

It can be a bit tough, considering how Alpine works, and handling all the different orders the scripts can run, so maybe I'm just really not sure...

the prefixing may actually be the best way for this...

The best alternative would really be to see if the "component" in question can't just be done with vanilla. Since a whole instance of alpine to handle really simple interactions for a few divs doesn't make much sense. Things that will be installed into other peoples websites have a real responsibility to not bring along things they don't need.

[hirasso]

I have a few WordPress plugins that enhance WPs admin area and have definitely complex enough UI to justify the use of Alpine.js.

[ekwoka]

Then I'd recommend using custom prefixes for them, or doing dynamic imports, so you only add Alpine if it's not already there.

[hirasso]

I have found the best approach to be this:

1. Install Alpine.js from npm and bundle it with your js file (documentation). Don't assign it to window:

import Alpine from "alpinejs";
// Assign a custom prefix:
Alpine.prefix("xyz-");
// Don't assign Alpine to the window (keep it private):
// window.Alpine = Alpine;
Alpine.start();

2. Use a different prefix for each of your packages
3. Keep in mind that the custom prefix will disable the @ shorthand for x-on:

<!-- will not work because of `@click` -->
<div xyz-data="{ show: false }" :class="{'is-shown': show}">
    <span xyz-show="show">👀</span>
    <button @click="show = true">Show!</button>
</div>
<!-- will work: -->
<div xyz-data="{ show: false }" :class="{'is-shown': show}">
    <span xyz-show="show">👀</span>
    <button xyz-on:click="show = true">Show!</button>
</div>

In my tests, the : shorthand kept working even with the custom prefix. To be on the save side, I would recommend to also not use that. So :class would become xyz-bind:class

So far I could not observe any conflicts between the two instances if following this approach. The only downside is that you won't be able to use the Alpine global directly in your HTML, but since I'm using re-usable x-data everywhere, this limitation doesn't impact me.