Alpine unified state

[0xDjole]

After using Alpine, I have come to the conclusion that global stores in Alpine are extremely powerful.

I've been using it with Astro.JS and most of my components don't even have imports or script tags...Almost all the logic is written inside plain .ts file containing global store, reactive variables with Alpine watch and event persistent parts. Its beautiful.

I believe if this project was to unify state ( and pretty much ditch x-data completely ) like Svelte 5 did with runes and only rely on global stores as a single way to do stuff, the project would be way more successful, as global stores can do anything local ones can.

I suppose this is not a feature request, but rather a request to remove a feature. I'm sure I'm missing something but unifying state is almost 100% way to go especially since the aim of Alpine is to be lightweight and would be easier for the devs.

Additionally instead of spamming $store to access stores, I'd add store alias ( $cart for example ) telling us it's a global store. ( Or if this magically gets into a real discussion, $ would just reference a regular unified state )

[ekwoka]

The issue with global stores is how would you simply have 8 of the same component on the page?

I don't see how that would be easier at all.

I'd add store alias ( $cart for example ) telling us it's a global store

You can already do this with Alpine.magic

[0xDjole]

Thanks, Alpine.magic is indeed good for aliasing. Great idea.

For the components, I'd create 8 store instances with unique names... It wouldn't be that much different then x-data in the script tag...as I am trying to avoid javascript in the strings.

Anyways..It's just a thought because stores are damn powerful. I've written 1000 line store for a full multi-step booking system that I can extend however I want and it works crazy well and I believe alpine can be used on even larger projects if that was promoted as a standard extendable pattern..

Only thing as a new user i've been struggling is to find a recommended way to pass alpine values as properties to child astro component. Anything on that regard?

[SimoTod]

You should use a single Alpine.data (no need to define jsnin x-data) instead of 8 copy-paste stores.

[0xDjole]

@SimoTod Not copy paste stores. Just 8 instance of them as a factory. At that point Alpine.store and Alpine.data are almost the same. That's the entire point of why I was thinking maybe x-data might not even be worth it..

Alpine.store can do everything Alpine.data can, but Alpine.data can't do everything Alpine.store can. Comes down to that.

[ekwoka]

This sounds like you're just forcing stores in where they shouldn't really be...

Like what if you need a 9th one? or don't need 8?

what if you need an unknown amount of them?

What is the benefit of having those 8 be stores instead of just...data?

Alpine.store can do everything Alpine.data

Not quite, they can't be destroyed. And they can't access magics.

Alpine.data can't do everything Alpine.store can

Like? be changed by random things across the page? That's by design.

This is basically mostly boiling down to "why have local state, when global state do trick?" and the point is that you might have items that are not aware of where they are or what specific key is for their state, so they access the available local state always, so they always use the right thing.

a Cart makes sense in a store, but imagine things like [https://www.osoandme.com/collections/french-terry](having every product card control it's own image for color swatches). seems like making that global would just make things messier, not cleaner.