Show HN: Store.js v2.0 – Cross-browser storage for all use cases (opens in new tab)

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

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!

That's really nice to read :) thanks!

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...

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.

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!

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

Thanks, I'll keep an eye on that issue. I still have other more pressing milestones to reach anyway ;)

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 :)

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.

It's worth noting that vanderZwan was asking about localForage, the library by Mozilla, not localStorage, the browser feature.

Not that I disagree with your other arguments but this one sticks out:

> 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.

Yup on all accounts, although: > Not if you want to store more than few MB (5 or 10 max depending of browsers if I recall)

There's a case for something like http://pieroxy.net/blog/pages/lz-string/index.html

which can save up a lot of space

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.