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.
It is a crazy super power and I did a lot on my site vibe coding using the custom HTML component to reference markdown files so that I could tweak figures quickly but have things like counters and a price calculator on the site.
I really enjoyed reading this thread. It is amazing to me you all understand the content. High 5’s to all of you. This is miles over my head. I’m grateful you all can understand and comprehend how this can be used in elements. I see a bright, bright future! I will just be using the components you all dream up!
I have never coded in RW in my life and using it since RWv5, however I am great copier and paster especially of my snippets for store. At nearly 70 I didnt think I had the brain capacity to learn the HTML custom components yet I have done loads and Benn confident enough to put them on here too! Although I did copy and paste I watched Dev Diary 15 and that helped me understand the basics and I just played around, now I have a very BASIC understanding of what’s going on and can add and change things with effect. Also there are great people on here to help like @Doobox@handshaper@upssjw and lots more who normally chip in or makes things better when I get stuck. So watch Dev Diary 15 and have a play then you will start to learn basics and you never know get to use Alpine later. Good Luck!
.
