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.
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:
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
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. :)
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!
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.
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.
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.
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!
Since I assume both have their pros and cons, when would I want to use Store.js, and when would I want to use localForage[0]? I'm asking as someone who has offline storage planned for an app, but has yet to get around to it. I'd like to know which one is probably best for my needs :)
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.
Sounds like (based on other comments) you should really just be using localForage. Store.js only currently supports a sychronous interface, which will be incompatible with modern web APIs.
On the other hand, synchronous interfaces tend to be less error prone and simpler to work with (and more enjoyable...? :)
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 :)
If you're writing buggy async code I'd say the storage library is far from your biggest concern. I'm all about human factors and making devs lives easier and all that, but async is a core skill for a web dev.
Store.js is here to make life easier for all web devs, beginners and pros :) I've concluded that adding an async API in addition to the sync one for access to the more powerful storages makes total sense though! Off the top of my head I'm leaning towards new methods for the async versions, and then probably adding localForage as a new storage.
I think something like store.js ends up being genuinely useful for anyone building functionality that depends on localStorage. More often than not you find yourself either having to deal with issues that store.js solves for you (E.g not breaking your site in Safari private mode) or requiring extra functionality that already exists as a small store.js plugin. (E.g expiring keys, default values, etc). All of these are things you can of course do without a library, but at that point you're reinventing the wheel a bit and not benefitting from all the automated testing that ensures cross-browser correctness. With that said, I agree there are times when just a quick read/write directly to localStorage can be the right call, but by default I think it comes back to bite you one way or another more often than not :)
Well, I need more than 5 MB and would like to store other values than strings (mostly large TypedArrays). Something simplifying my life there would be appreciated.
I believe syncing could live in a plugin! Would you be up for creating an issue and quickly describing your requirements? I'm genuinely interested in supporting every real use case!
Almost! Except if you want to store objects/arrays/numbers (localStorage only supports strings), or want your site to work in Safari Private mode (where localStorage breaks), or if you have to support legacy environments with old browsers (like many government services), etc etc etc :)
Except when a value has already been stored previously without JSON.stringify (in which case JSON.parse will throw), or you need a default value if unset (e.g `store.get('username', 'anonymous')`, or ... :) But I also see your point that sometimes the very quick and simple solution can be useful!
Not if you want to store more than few MB (5 or 10 max depending of browsers if I recall).
Not if you want/need an async API.
Not if you need to be able to search your storage.
The only problem I've noticed with simpleStorage is the Safari private mode thing, but I see that as a bug in Safari so I just show a message to users telling them why the site won't work properly for them.
Hey, I'm not sure what an angular2 version would look like or do. Could you please open an issue with a more detailed description of what you need? I'll help if I can!
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!