Give access to sessionStorage

[localforage]

Give access to sessionStorage

[thgreasi]

Just published a custom driver that uses sessionStorage in case someone is still interested.

[ianb]

sessionStorage is just like localStorage, but it's local to the tab, so if you have two tabs on the same site they won't see each other's sessionStorage. I use it to keep TogetherJS's session information.

[tofumatt]

Aside from changing localStorage to sessionStorage, there's no work needed here, right? Presumably we could just make a version of the localStorage driver that does var localStorage = this.sessionStorage, right?

[tofumatt]

That is a good point, and at this stage we’re closer to current versions of all major browsers plus all previous versions supporting IndexedDB/WebSQL.

Actually, I would say at this point if anyone wants to use sessionStorage they should write a driver.

localForage implementing its own per-tab namespace is out-of-scope for the library itself; I would leave that to the developer or to another library. It’s a good idea, but I would prefer it be in a separate library/codebase.

I’ll close this out I think.

[jirislav]

I think it would be nice to have an optional driver choice of sessionStorage so that I could use the benefits of deserialization already being implemented within the localForage .. @thgreasi thanks for your effort! i'm going to use it ;)

[tofumatt]

Forgive my ignorance, but isn't it just a session-based localStorage API? The idea of this library is more about improving performance (by not relying on blocking calls unless localStorage is all that's available).

What's the benefit of sessionStorage?

[tofumatt]

Oh, what a confusing name!

That’s cool; I don’t have many use-cases for any of my apps, but I’ll make a note of implementing it at some point.

[sole]

Ah, I didn't know about sessionStorage. I guess it makes more sense when building document-based apps, if you know what I mean :)

[jokeyrhyme]

Correct, the API is the same. It's literally just using a different global.

[tofumatt]

Would anyone still like to see sessionStorage implemented? localStorage is already the worst backend to use when using localForage and is really just here so old IEs are compatible. I don't particularly like supporting even it, so adding sessionStorage at this point seems silly.

That said, if there's demand I'll do this soon. If not I'll likely close this issue.

[jokeyrhyme]

I would vote against making sessionStorage automatic in any way. I agree that there are interesting use cases for it, but developers really need to know exactly how it works before they begin using it.

If we have a localStorage backend, then I agree that it would make sense to offer a sessionStorage backend as well for consistency. However, it absolutely must be opt-in. It would be very confusing to have a persistent storage system that doesn't persist.

[tofumatt]

Oh, I didn't even think to mention that but yes: it would never be an automatic choice. Good point!

• Matt

On Oct 7, 2014, at 17:42, Ron Waldon [email protected] wrote:

I would vote against making sessionStorage automatic in any way. I agree that there are interesting use cases for it, but developers really need to know exactly how it works before they begin using it.

If we have a localStorage backend, then I agree that it would make sense to offer a sessionStorage backend as well for consistency. However, it absolutely must be opt-in. It would be very confusing to have a persistent storage system that doesn't persist.

—
Reply to this email directly or view it on GitHub.

[areologist]

In a mobile-first SPA where many users had browsers that capped localStorage at 2MB--but did not limit sessionStorage at all, interestingly--I marked some data as high priority for persistent storage and then push the lower priority data sets (lazy loaded) off to sessionStorage if localStorage is at or near the quota. Better to load once and cache then load every time. (Incidentally, I'm now looking to build an Angular SPA and use localForage--if I'd had time I might have attempted to wrap IndexedDB, etc., but this wasn't in the cards.)

However, I agree with jokeyrhyme that shifting from local- to sessionStorage should not be automatic. Thinking I might prefer having distinct localForage and sessionForage libraries, where sessionForage similarly offers facade that might use WebSQL or IndexedDB under the covers.

[hsablonniere]

Where are we on this one? Would you be interested in a pull request?

[tofumatt]

Always happy to take a look at a pull request! I don't think anyone has been working on it.

tofumatt (Sent from mobile)

On 7 December 2014 09:08:26 GMT-05:00, "Hubert SABLONNIÈRE" [email protected] wrote:

Where are we on this one? Would you be interested in a pull request?

---

Reply to this email directly or view it on GitHub:
#2 (comment)

[michielbdejong]

I think adding sessionStorage as a backend makes no sense, if I want to use sessionStorage on a device that supports it, then why not use it directly? The asynchronous API of localForage would be reduced to just syntactical anti-sugar, and under the hood sessionStorage would still be blocking the main thread.

I think what is requested here is a mode in which localForage behaves like sessionStorage: On pageload, generate a unique namespace which identifies the currently open tab, and scope everything to that namespace for as long as the tab is open. So if you open a new tab, or refresh the page, you don't see any of the data that was created elsewhere or earlier. You would then also have to periodically clean up namespaces from crashed or closed tabs.

IMHO sessionStorage is a confusing and useless technology, but if people have a reason to use it (like quota circumvention), then they would obviously benefit from having a "sessionForage" to switch to

My 2ct.

[areologist]

I agree with michielbdejong. It's been useful to me to have a sessionStorage fallback strategy in a particular app but I don't think it would add value to localForage. And it would be confusing given that sessionStorage differs between sessions and browser tabs. In the specific cases where it makes sense to have a sessionStorage fallback it still makes sense to have distinct interfaces under the hood.

[jprichardson]

think adding sessionStorage as a backend makes no sense

Totally agree.

localForage implementing its own per-tab namespace is out-of-scope for the library itself;

Yep. This library can't get too bloated or it'll lose part of its appeal: simplicity.

[hsablonniere]

Fair enough...

[thgreasi]

Since we have support for custom drivers and this sounds like a crazy enough idea to me,
I might give it a try in the holidays :)

[tofumatt]

Added it to the wiki (https://github.com/mozilla/localForage/wiki/Custom-Drivers)

[thgreasi]

@jirislav I'm happy this is useful for you :)

[dhwang]

Thanks @thgreasi .

Just want to add that sessionStorage survives page reload, unlike what @michielbdejong said

Quote from https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage

while data stored in localStorage has no expiration set, data stored in sessionStorage gets cleared when the page session ends. A page session lasts for as long as the browser is open and survives over page reloads and restores.