Description: Alpine.store allows you to define and access shared, reactive data or state that is accessible from any Alpine component on the page. This is particularly useful for managing application-wide concerns like user authentication status, global settings, or, as in our example, the contents of a shopping cart across different UI sections.
Defining a Store: Alpine.store('storeName', { ... })
This is how you create a global store. It's typically done once per store within a <script> tag, ideally inside the alpine:init event listener to ensure Alpine is ready.
// Inside document.addEventListener('alpine:init', () => { ... });
Alpine.store('cart', {
items: [], // A data property (reactive)
addItem(product) { // A method to modify state
this.items.push(product);
},
get itemCount() { // A getter for computed state
return this.items.length;
}
});'storeName': A string that uniquely identifies your store (e.g., 'cart', 'user', 'settings').items: []): These are the reactive pieces of state. When they change, any part of your UI bound to them will automatically update.addItem(product)): Functions that can operate on the store's data or perform other logic. They are the preferred way to mutate state.get itemCount()): Functions prefixed with get that compute derived state from your data properties. They are accessed like properties (e.g., $store.cart.itemCount) and are also reactive.Accessing Store Data: $store.storeName.dataProperty
From within any Alpine component (elements with x-data) or Alpine directives (like x-text, x-bind, x-show, x-for), you can access a store's data properties and getters using the magic $store object.
<div x-data>
<p>Items in cart: <span x-text="$store.cart.itemCount"></span></p>
<ul>
<template x-for="item in $store.cart.items" :key="item.id">
<li x-text="item.name"></li>
</template>
</ul>
</div>Calling Store Methods: $store.storeName.method()
You can also call methods defined in your store from Alpine components, typically in response to events like clicks.
<div x-data="{ newProduct: { id: 1, name: 'Sample Book' } }">
<button @click="$store.cart.addItem(newProduct)">
Add Sample Book to Cart
</button>
</div>Defining a store after components try to access it:
Alpine.store() definitions must be executed before any Alpine components that rely on that store are initialized. The safest place to define stores is within the document.addEventListener('alpine:init', () => { ... }); callback. This ensures Alpine is fully loaded and ready. Placing store definitions in a <script> tag early in your HTML (e.g., right after including AlpineJS itself, or in the <head> if not deferred) is also common, but the alpine:init event is the most robust approach.
Modifying store data directly from many places without clear patterns:
You can directly modify store properties from components (e.g., $store.cart.items.push(...) or $store.user.isLoggedIn = true). However, for more complex applications, this can make state changes hard to track and debug. It's often better practice to define methods within the store itself to encapsulate state mutations (e.g., $store.cart.addItem(item), $store.user.login()). This is analogous to using setters, service methods, or actions/mutations in backend architectures or other frontend state management patterns. It centralizes the logic for how state changes, improving predictability and maintainability.
Overusing global state for data that is truly local to a component:
Alpine.store is powerful, but not everything belongs in global state. If data is only relevant to a single component or a small group of closely related components that can communicate via props or events, manage it locally using x-data. Global state is best reserved for data that truly needs to be shared and accessed across disparate parts of your application. Overuse can lead to tight coupling and make components harder to reason about in isolation. Think of it like global variables in Python – use them judiciously.
Loading products...
Price:
Items in cart:
Total Price: