Persistent $store values

[joshuahamilton]

Apologies if the functionality is there and I'm too dumb to read the docs good, but is there a plan to support persistent storage of $storeed values? For context, my project was leveraging Spruce.store(), but with v3 of Alpine the author has put Spruce into 2.x maintenance mode. Unfortunately, as far as I can tell, Alpine has not implemented local storage as an option, a key feature of Spruce, so my project is crippled a bit as a result.

I've been exploring making my own implementation leveraging Alpine.magic functions, Alpine.reactive, and nbubna/store but honestly this is a bit beyond my depth.

Thanks, and congrats on the milestone. I've been really happy with Alpine the last couple months I've been working with it.

[ryangjchandler]

Hey @joshuahamilton, Spruce author here. I don't know if there's any plans to support persisted stores, although I am tempted to extract this out into a separate package that would be powered by Alpine.store under the hood.

[danddanddand]

@joshuahamilton So I got a PoC working - you can find it here: https://github.com/ryangjchandler/fern

From my testing so far, it seems pretty solid. Alpine.effect is the real hero - I haven't published anything yet, but feel free to use the files in dist/ for testing.

It does require you use a new Alpine.persistedStore function, although I don't know how I feel about patching a method onto the Alpine object...

@ryangjchandler I have one use case where I do something similar but I'm manually persisting it using watch. My use case is on search forms throughout app where each page you can toggle some features on/off but they are page dependent.

For example, I don't want persisted state on every page in app, just pages you've visited and changed state for when you navigate back to that page.

Do you think it makes sense to add optional boolean parameter (or options object) so it turns into something like function persistedStore( name : string, value? : any, locationBased? : boolean ) and when it does stores it changes to something like localStorage.setItem(__fern_${name}_[${location.href.replace( location.search, '' )}], json).

Just an idea based on my use case. Would obviously make the lookup more complicated too and might be too niche to be worth it but I could imagine people thinking about global state in terms of page and not application sometimes.

[ryangjchandler]

@danddanddand Thats an interesting idea. I guess this could already be handled in user land by using a unique store name on each page, right?

[joshuahamilton]

@danddanddand My situation is fundamentally similar. To simplify a bit, I have a global preference that can be overridden on a per-page basis. What I did is store the global value as one entry and a list of key:value pairs for the local preferences. On page load I check for these values and use whichever applies. The local values are structured like:

globalPref = "option1"

localPrefs = {
  "/unique/page/url/: "option2",
  "/a/different/page/: "option3",
}

[danddanddand]

@danddanddand Thats an interesting idea. I guess this could already be handled in user land by using a unique store name on each page, right?

Ya, in our case we just use the same store name for this feature out of convenience so there is no setup/wiring to use it on any page. Any component just has to use $store.feature and it's a toggle that has one-to-one relationship to page so works well for us using the location based strategy

[danddanddand]

Sounds very similar @joshuahamilton where they are both location dependent. I'm just making localStorage do it automatically using the location.href (minus query params)

[calebporzio]

I'd like to offer this behavior by combining the existing stores API with the new (unreleased) "$persist" plugin.

Let's talk potential APIs. This is the first one that comes to mind:

// Persist a single value
Alpine.store('counter', {
    count: Alpine.$persist(0),
})

// Persist the whole store
Alpine.store('counter', Alpine.$persist({
    count: 0,
}))

Not sure this is even something Alpine should tackle. Wondering how high the demand is for persistent stores.

[joshuahamilton]

I'm not using the machine with the code on it, but in general here's the (probably bad and mess, but effective) solution I put together.

I made a new magic helper $storage that does a bunch of heavy lifting and stored variable juggling. I'm still using nbubna/store to handle the localStorage itself, mostly because I've used it many times and I didn't want to deal with it myself.

Extending on what @ryangjchandler did in their PoC, $storage has 2 proxy objects with getter and setters. The first is $storage.data for persisted data and $storage.temp for ethereal data. The latter basically just calls Alpine.store. I can just use $storage.data. my_variable = 123 (or this.$storage from JS) to set and $storage.data. my_variable to get, which is nice. Since store2 is under the hood, I also tacked on some helpers since it's basically features for free. I have the flexibility to call, say, $storage.set("my_variable", "my value", false) to write to the temp store, $storage.get("my_variable", "fallback value") to get a default value, and so on.

I'm not suggesting my code is good, but more that this approach stays out of Alpine's airspace and it super-easy to use in templates or JS.

[joshuahamilton]

@calebporzio In case it's helpful, here's the code I ended up with by Friday afternoon.
https://gist.github.com/joshuahamilton/c1c10574ea94f93d7d1d826965ea05b8

[ryangjchandler]

But as you can see, I much prefer composable APIs over new distinct methods like "persistedStore"

I agree. Composable methods are cleaner but inside of a third party package, the dedicated method was easier to handle.

[ryangjchandler]

Adding it to core doesn't make sense, but adding it to one of the first party packages does. I've had a tonne of people asking me about it since they no longer use Spruce in 3.x, the upgrade path is difficult / impossible.

In my opinion, the Alpine.store() implementation should have at least been on par with Spruce's features, lots of people have been left with missing functionality hence the package I wrote.

[robdekort]

I'd like to offer this behavior by combining the existing stores API with the new (unreleased) "$persist" plugin.

Let's talk potential APIs. This is the first one that comes to mind:

// Persist a single value
Alpine.store('counter', {
    count: Alpine.$persist(0),
})

// Persist the whole store
Alpine.store('counter', Alpine.$persist({
   count: 0,
}))

Not sure this is even something Alpine should tackle. Wondering how high the demand is for persistent stores.

I'd love something like this. Very readable and it makes sense. Def. have use cases for this.

[KevinBatdorf]

I'd prefer a solution that allows you to optionally pass in your set and get methods for persistence since I sometimes use something other than localStorage.

[danddanddand]

I was thinking that with the PersistOptions version too, you could pass in Alpine.store( key? : string, value? : any, persistOptions? : PersistOptions )

and PersistOptions could be something like

interface PersistOptions {
….
setItemFunction?: ( key : string, value : any ) => void;
getItemFunction?: ( key : string ) => any;
….
}

It would default to localStorage I’d assume but if you wanted to plugin something else could just pass it in as options?

[ryangjchandler]

This is something I handled in Spruce - allowing you to change the persistence "driver". An object that had a getItem, setItem and removeItem method.

[danddanddand]

I’ve been missing Spruce for sure but we’ve migrated to Alpine.store without many issues. There are a few things that are nicer like not even needing a store because children components are inheriting props from parents. We’ve had to do a few hacks to migrate like passing $watch function around to things that weren’t in Alpine’s lifecycle before (to replace Spruce.watch) and those watchers were slightly cleaner with Spruce since they just needed path and not $store.path but not big deal.

[ryangjchandler]

Yeah, I'm also missing the dedicated watch method. To be honest though, you can work around that using Alpine.effect(), it's just not as obvious as a watch function.

Alpine.store('myStore', {
    count: 0
})

const store = Alpine.store('myStore')

Alpine.effect(() => {
    // do stuff with `store` here...
})

[ledahu]

hi
Just to add that i my case of persistence, i use Dexie JS to store in indexedDb
so the Alpine/Spruce store is only used for the current state of the SPA, not the core data that are in Dexie