If you’re already in this choir you already know this. I just joined this choir today and I’m in love with x-data.
x-data is how Alpine.js gives an element its own little brain.
It’s where you define the data and functions that belong to that part of the page. Alpine watches that data for changes and automatically updates the HTML, so you can make things interactive without writing a bunch of JS elsewhere.
Alpine is as far as I can see available in all your pages by default .
Just scratching the surface in my little test here.
The counter in the test is a component I created, and I just had to add a tiny broadcast on animation end so anything else on teh page can listen out for it, and act on it however you want.
The footer in this test listens for the broadcast and is simply a html component, no javascript
Hah, that’s awesome. It’s really easy to vibe code anything by asking ChatGPT to use Tailwind and AlpineJS, throw it in a custom component and it just works. I still think it’s a bit of hidden super power in Elements!
At the moment we always include Alpine JS on the page (providing there’s at least one of our components). We plan to make it more intelligent in the future and only include it, if it’s actually used. But for now it works
It’s really nice that everyone can use one set of frameworks to make everything just work seamlessly together. We’re really keen to keep it that way as the benefits for users are HUGE.
Interesting idea about the x-data entry fields What do you think @ben, does that make sense or do you have other ideas?
Welcome to the world of Alpine. It’s truly an amazing “little” framework that adds so much functionality with so little code. I see it as “inline javascript”, and I mean that in a good way
We use it extensively in our core components, it’s what powers all the interactive components (with the exception of Reveal).
I’d need some convincing on this one!
There are a few issues that could arise if we added in-app support for x-data — firstly it would be seen as an “official endorsement” for Alpine, and we want to keep things open for both user’s and developers.
We don’t want to tie the app to one particular framework. Alpine just happens to be, in our opinion, the best fit for our components right now. That could change in the future if something better appears.
There are also issues around nesting x-data’s inside of each other — the inner x-data doesn’t have access to the parent’s data, that could cause some confusion for the end user.
I have considered something along these lines, something that is targeted towards generic HTML attributes would allow you to add aria, data, alpine, etc. attributes without tying the app to a single framework.
My initial idea was to add an Attributes collection on certain components, in theory I think that could work, but we would need to explore that some more before committing to doing attributes in this way.
Oooo, that sounds on the face of it a little scary.
Imagine this scenario. Developers like myself adopt it in the components they ship to the store. They don’t include their own reference to Apline and the plugins, as they are available (right now in Elements).
Sound like developers should do something like this preemptively .
Could be strengthened if version matters.
<script>
(function () {
function loadAlpine() {
if (window.Alpine) return Promise.resolve(window.Alpine);
if (!window.deferLoadingAlpine) {
window.deferLoadingAlpine = (init) => { window.__startAlpine = init; };
}
return new Promise((resolve, reject) => {
const s = document.createElement('script');
s.src = 'https://cdn.jsdelivr.net/npm/alpinejs/dist/cdn.min.js';
s.defer = true;
s.onload = () => {
if (window.__startAlpine) {
try { window.__startAlpine(); } catch {}
} else if (window.Alpine && !window.Alpine.started) {
window.Alpine.start();
}
resolve(window.Alpine);
};
s.onerror = reject;
document.head.appendChild(s);
});
}
loadAlpine().then(() => {
// Your add-on code that needs Alpine
console.log('Alpine ready');
});
})();
</script>
We’ve already been thinking about that and have started sketching out an API that would let developers declare which libraries their components depend on. That feels like the right approach — a single, central place where Elements can handle loading libraries automatically, so developers don’t need to manually check or include them like in your example
We might need to push this up the list as it’s going to be a constant question once the store is ready.
For now, you can just rely on Alpine being included
Can you please do better so that you have a full tickle! I also noticed you were nearly tickled pink too! Great work but looks a little woof around the edges!
So for the time being I just created a little utility component, just a drop zone that injects attributes right after the tag (similar as suggested for advanced section). While it works, using it I realise it’s not a great user experience.
Keeping track of the code I place in it visually is terrible, as you can see in attached.
What would be a great user experience would be a new control that can be added to the component properties, just like Element already has in the page inspector the “Edit Extra Code” button.
This way you get a proper little editor to add attributes.
.
