Storex is a frontend store with state management handled on the backend. It allows you to update the store state both from the frontend and backend, with all communication occurring over WebSocket.
Efficient state management: Only the differences (diffs) in the store state are sent with each mutation, minimizing data transfer.
Real-time updates: State changes are immediately reflected across all connected clients via WebSocket communication.
Backend-driven state: Storex allows both the frontend and backend to update the store state seamlessly.
Lightweight and fast: Designed for minimal overhead, ensuring rapid state updates and communication.
Key Differences from Phoenix LiveView
Phoenix LiveView is a powerful tool for building rich, interactive web applications without writing custom JavaScript. However, as your application grows, managing complex client-side state across multiple LiveViews or components can become challenging. This is where Storex comes in.
Client-Side State Management: While Phoenix LiveView handles server-side rendering and event handling, Storex focuses on managing state on the client side. It allows you to keep your client-side state in sync with the server, but with more flexibility in how that state is stored, updated, and accessed.
Decoupled State Logic: Storex decouples state management from the LiveView itself, enabling you to manage state across multiple components or even across the entire application. This contrasts with LiveView, where state is typically tied to a specific LiveView process.
Predictable State Updates: Storex follows a predictable, unidirectional data flow similar to Redux. This makes it easier to reason about state changes and debug issues, especially in complex applications.
Extensibility: Storex is designed to be highly extensible, allowing you to integrate it with other tools and libraries in the Elixir ecosystem. You can also define custom middleware to handle side effects, logging, or other tasks.
For an overview of Storex in action, check out the example provided here.
That’s interesting.
Do you think it would be feasible to add fw-specific wrappers around Storex, so that we could (for example) use a SolidJS store transparently?
So (in this case) Solid’s reactive system could create an event, which is (maybe) processed in the backend (without any further ado) which then modifies the store which then leads to a reaction (without further ado) on the client side…?
Thats very nice. So Storex on the client side acts as an observable (implementing subscribe)…?
I’ve only played a little with SolidJS, so I can’t say if there are any drawbacks (besides having to “learn” the Storex API for writing). If it works as I think (have to try it out) this just rocks. Liveview is really great, but I’ve a project now, that is so dynamic that I need a frontend framework. This could bring one of the biggest benefits of LV - removing all the layers between backend and frontend - to any (reactive?) framework (implementing sth like from)
Yes, storex has the subscribe method in Store to work with reactivity.
I’m using storex with svelte frontend framework which works on subscribe method on reactivity.
Example:
<script lang="ts">
import Storex from 'storex'
const store = new Storex<RandomNumber>({
store: 'App.RandomNumber',
params: {},
})
</script>
{#if $store}
Random number: {$store}
{/if}
