LocalForage – A fast and simple storage library for JavaScript | Hacker News Reader

LocalForage – A fast and simple storage library for JavaScript

github.com

108 pointsvmorgulis20 comments

This is a great library. It's simple but flexible. You can treat it like async key-value storage but it has extra features like using different databases, all while handling the details of IndexedDB, WebSQL or localStorage support.

General question: How do you handle cases where people surf in private mode in Safari? Safari doesn’t allow localStorage in private mode.

https://github.com/localForage/localForage/blob/master/src/u... seems to be the only check. They would actually have to try setting an item then remove it to catch the private browsing use-case EDIT:misunderstood the question. Seems like they are https://github.com/localForage/localForage/blob/master/src/l...

Ideally these libraries will fall back to in-memory storage, which is lost when you navigate away, but keeps pages working when they expect to be able to write then read back a value in the same page.

Some browsers like Firefox throw exceptions when you try to touch storage in private browsing mode. This can be super annoying since it tends to break pages that use storage and haven't been specially tested in that mode in that browser. A library-based memory fallback helps avoid that. AFAIK it's what Chrome does with storage in incognito mode: just save calls in RAM, return them if asked for, then throw it away when navigating.

There's a PR to add this for localforage but it's been stuck in purgatory for a while and seems to have some resistance despite the utility: https://github.com/localForage/localForage/pull/555

I think the reasons stated for not including this PR are pretty well thought out, and while your arguments on utility seem consistent and definitely make logical sense, they don't really reflect my own development experience.

This could be just personal preference, but it seems far more likely to me that my expectation when storing values in localStorage would not match Chrome's apparent silent fallback of not storing that value. I'd much prefer to handle the error case.

localStorage can be cleared at any time anyway. This simply makes it happen on each page navigation.

IDK what you'd rather do in Chrome Incognito, Safari Private, Edge InPrivate, etc.

---

PS. If the OS registry entry for localStorage location is invalid or missing, IE will also throw an error.

What I would do in Incognito, etc. would depend on the website/app and use-case. The point was that handling that on a case by case basis makes more sense than the suggested silent (and I would say unexpected) behavioural change.

I'd say that if the user is using a private browsing mode, they are explicitly indicating to the browser not to store anything, and they will know that will happen. It's the whole purpose of the feature, so I don't think it counts as "silently" doing anything. I don't think there's any reason to then potentially break web pages that (quite reasonably) expect storage APIs to work.

Right. It's like "silently" removing session and non-session cookies when the windows closes. That's the whole point.

Clarification for those who parsed this (incorrectly) like I did: localStorage does work in Firefox in Private Browsing Mode[1], it's IndexedDB and the DOM Cache API that throw. (Although Firefox has private browsing support for IndexedDB in the works. That effort is tracked on https://bugzilla.mozilla.org/show_bug.cgi?id=781982.)

1: But it's exclusively memory-backed and will be forgotten somewhere between 0 and 20 seconds after the last active page for the origin is gone. It is not persistent for the lifetime of the private browsing session. However, because Firefox has a back-forward cache ("bfcache") that keeps pages around (frozen) for a while after you navigate the window to another location, the storage may be kept alive for some time even with no active windows.

Interesting, I've been very happy with pouchdb finagling all these browser DBs into one that matches couchdb on the server side.. I would really have to think about the auth logistics for memcache to switch to a kV store. But that would be even more insane minimalism atop the absurd complexity of the web stack.

This is at least the 8th time this has been posted (https://hn.algolia.com/?q=localForage). Is there something new or significant that we need to know about?

There's a post on the front page about it, it's just brought it to peoples attention again. https://news.ycombinator.com/item?id=13419823

While I am fascinated by this, what are some good use cases for using offline storage? How can a web-enabled browser app benefit from offline storage? I've come to appreciate the power that client-side stores like what Redux and MobX provide, but what's the benefit and use case of using this?

This is good for storing data across sessions, whereas Redux/MobX lose data once the user closes the tab.

You usually use localStorage for e.g. user settings that are not stored on the server. There are many sites that give you the possibility to change a preference or two without the need for an actual account on the site. That sort of information is usually stored in one of the client-side storages.

I think Splitons is a good example of an App using rightly Local storage combined with AppCache : splitons.com

It keep tracks of expenses offline and sync states when you have connectivity again.

We actually use localforage as a backing store to "persist" parts of the redux store automatically.

The app itself is a freight logistics tracking and scanning app which is meant to download and store a few hundred MB of carton data and be able to scan and process it offline and sync back to a server when online again.

With redux-persist and localforage it's been effortless to enable this. Parts of our store are whitelisted and are persisted to localforage every 300ms or so. When the app is loaded the next time it pulls the data from localforage and "rehydrates" the store with it so it's like we never left the page in question.

It's asynchronous, localStorage is synchronous

I tried this but ended up going with SimpleStorage. I can't remember why but there was something better about it.

Reply on news.ycombinator.com