[marcuswestin]

Store.js was originally released on HN in 2010 :) https://news.ycombinator.com/item?id=1468802

It's live on tens of thousands of websites (like cnn.com!) and has seen lots of improvements over the years.

Store.js version 2 is a full revamp with pluggable storage (it will automatically fall back to one that works in every scenario by default), pluggable extra functionality (like expiration, default values, common array/object operations, etc), and fully cross-browser automatic testing using saucelabs.com.

Feel free to ask any questions! I'm going to sleep now, but I'll make sure to answer in the AM.

Cheers!

[EdSharkey]

Hey Marcus, I'm a user! Thanks for doing the heavy IE lifting in store.js.

Anyhow, I had a requirement to store raw strings to the local storage or userdata rather than go through your calls to JSON.parse/stringify. I forked and am using my fork rather than your maintained version, which is sad. Since you've got the hood popped for maintenance, would you mind adding raw string support to store.js in version 2? Thanks in advance. Here's my fork repo for reference, please see the getRawString and setRawString API's I added:

https://github.com/woldie/store.js

[greggman]

Genuinely curious but why is this important? Assuming the current API only takes an object can't you just provide 2 functions

    function putString(id, s) {
       storePutAPI(id, {s:s});
    }
    function getString(id) {
       var o = storeGetAPI(id);
       return o ? o.s : undefined;
     }

Note I have never used the API nor looked at the docs but assuming you can store objects why the need for special functions?

On top of which AFAIK JSON.stringify and JSON.parse work with plain strings so I'd be curious what prevents using plain strings in store.js without any changes

Sorry this isn't a put down , just trying to understand

[EdSharkey]

Not at all at all, I understand your confusion. Mine is definitely a niche case, perhaps straying a bit into the eclectic.

I have put together a virtual file system for a programming environment for kids that is built atop the local storage/userdata API's.

I support legacy IE back to IE6 as well as modern browsers, and I wanted to maximize my very limited allowed storage space on legacy IE.

Also, I needed to have some certainty around how much free space is remaining in the file system. My design was to organize the underlying storage into 4K blocks that were pre-allocated when the system first starts; whatever the host system could give me in terms of space I would take.

JSON is nice for the general case, but the way it escapes some characters makes computing the free space I have remaining unpredictable as new files get written.

Of course, I can do my own encoding of bytes into unicode char codes and write those as raw strings using store.js. JavaScript strings are saved as 16-bit unsigned arrays if you unfocus your eyes and stare at the screen for awhile, and I use as many bits as I am able in my scheme.

So, I rigged up a byte-to-string encoder/decoder that was universally accepted on IE and modern browsers, and calling through to my getRawString/setRawString API, I just about doubled my storage over the default JSON.stringify/parse!

Suprisingly, performance isn't bad with my encoded strings either. That said, my compy has a retro flair, and I don't think my users will mind much that they have to wait a second or two to load their games from disk. Perhaps even adds a bit of authenticity. :)

[marcuswestin]

Bonus points for best use case on the page :)))

Eclectic as it is, I think we should totally consider making it a plugin/storage! If you open an issue with links to the relevant material I'd really appreciate that. Thanks!

[marcuswestin]

Hi! Allowing users to add the plugin behavior they want is the whole idea, so let's do it :)

Could you please open an issue? If you include a short snippet with the rationale for what and why you need it that would help guide the discussion.

Thanks!

[EdSharkey]

Will do soon. Thank you Marcus!

[noir_lord]

Had somehow missed that this was a thing, it looks amazing.

Also kudos on https://github.com/marcuswestin/store.js#version-20 that is how to to do a readme page.

[marcuswestin]

That's really nice to read :) thanks!

[frik]

Will it support WebSQL in future too?

[marcuswestin]

I don't know when WebSQL would be better than other storage alternatives, but yes, you could easily add WebSQL storage :)

The rationale behind the new architecture is to make it trivial to write new backing storages - see https://github.com/marcuswestin/store.js#write-your-own-stor... for a quick explanation of how you'd do that.

This is also true for adding new functionality, which sits "on top of" the storage (and is agnostic to whatever particular storage is being used). Here's a list of plugins that come out of the box: https://github.com/marcuswestin/store.js#list-of-all-plugins, and here is a quick explanation for how you'd write your own plugin: https://github.com/marcuswestin/store.js#write-your-own-plug...

[egeozcan]

If I'm not mistaken, your API is designed to be used synchronously. Not sure how WebSQL or IndexedDB could work towards a synchronous API.

[masklinn]

That's also the way I read it, and indeed both WebSQL and IndexedDB only have async interfaces. IndexedDB used to have a sync interface available inside workers, but that was removed from the spec as there weren't any supporting use cases.

Overall localForage seems like a better cross-browser storage system, it also has a pluggable backend system (drivers) but defines an async interface.

[marcuswestin]

Duh, of course! Sorry, 3am and not too sharp in the nut at the time :)

I'm genuinely interested in supporting every needed use case - would you be up for creating an issue? Either way I'll have it in the back of my head and see what can be done.

Cheers, Marcus

[alexcroox]

Does it support indexdb, or is it not designed for larger storage needs?

[marcuswestin]

You can back it with any storage you want :) See https://github.com/marcuswestin/store.js#write-your-own-stor... for a quick explanation of how you'd do that.

[EmielMols]

I don't think so. Your API seems to be synchronous, where all modern IndexedDB/WebSQL/etc APIs use promises. The reason they do this is that in modern browsers storage often runs on a separate thread and/or use sqlite and you don't really want to stop-your-js-world when the rendez-vouz and sqlite processing can take 100s of milliseconds on mobile devices.

This really is one (of many!) of the ugly parts of modern JS development. Newly designed APIs will probably gravitate towards using Promises (because these also support sync backends - the other way around: not so much).

But, hell, it feels stupid having to allocate a closure to memory (and decorate your code with indentation and an additional function if you don't transpile using await) every time you just want to get your session token from storage.

[marcuswestin]

Duh, of course! Sorry, 3am and not too sharp in the nut at the time :)

I'm genuinely interested in supporting every needed use case. Off the top of my head, I could see e.g get returning a promise in some cases, or passing an optional callback to get, or having a get.async... Either way - I'll have it in the back of my head and see what can be done.

If you open an issue on GitHub we can continue there. Cheers!

[CharlesW]

Marcus, when you say "Cross-browser storage for all use cases", I want to store media files for offline playback. Can I use Store.js for that? (TIA!)

[marcuswestin]

I'm genuinely interested in supporting all use cases!

If you create an issue at https://github.com/marcuswestin/store.js and describe your use case in more detail we'll figure out what the right answer is.

Thanks!

[db-dzine]

Does store.js support saving files locally too? For example a PDF or similar?

[marcuswestin]

I created an issue to investigate viability and usefulness :) https://github.com/marcuswestin/store.js/issues/193