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!
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:
function putString(id, s) {
storePutAPI(id, {s:s});
}
function getString(id) {
var o = storeGetAPI(id);
return o ? o.s : undefined;
}
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
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!
Also kudos on https://github.com/marcuswestin/store.js#version-20 that is how to to do a readme page.
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...
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!
As a bonus of switching from cookies to local storage, now requests don't send along those values anymore to the server.
> Except if you want to store objects/arrays/numbers (localStorage only supports strings)
My normal usage of localStorage usually looks like this:
const getItem = (item) => { JSON.parse(window.localStorage.getItem(item)) }
// and
const setItem = (item, val) { window.localStorage.setItem(item, JSON.stringify(val)) }
There's a case for something like http://pieroxy.net/blog/pages/lz-string/index.html
which can save up a lot of space
I believe store.js addresses all the use cases of simpleStorage, and then some (E.g Safari private mode, etc).
If that's not the case I will make it work for your use case :)
Cheers
Check back in coming days for more details.
Store.js will soon have pluggable support for localForage (either by implementing similar functionality in separate storages, or by simply adding a pluggable storage which uses localForage under the hood).
There are a few benefits to using store.js, such as full cross-browser support and useful plugins, but the biggest meaningful value-add over localForage is probably the availability of a synchronous API that allows you to read and write values without callbacks, promises, etc.
In my experience you only want to use asynchronous APIs when you have to, since they add a fair amount of complexity, are a common source of errors, and are harder to debug properly.
But yeah, check back later and you'll likely find that store.js supports the same storages as localForage, in addition to the its other functionality.
There is an active issue to add the async indexdb/websql storages to Store.js (https://github.com/marcuswestin/store.js/issues/181) so that they can be used when needed (e.g when you need to store many tends of MGs of data), but for 90% of your use cases the simplicity of the synchronous store.js API may likely save you a meaningful amount of code and callback/Promise/stack trace debuggery :)
The other requirements localstorage alone can't address.
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. :)
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!
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.
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!
Overall localForage seems like a better cross-browser storage system, it also has a pluggable backend system (drivers) but defines an async interface.
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
Will tackle a bit down the road.
Thanks for taking the time to make the case!