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;
}
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
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!
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 :)
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)) }
And then you won't have issues with any type.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