How to store persistent data client side
Asked Answered
R

5

18

I need to programmatically store data on the client side without having to transfer the data from the server on every page load. I considered generating a dynamic JavaScript file with the needed data for the current session of the user and make sure it is cached, but that seems really messy and there are a few drawbacks I can think of to such an approach.

How can I go about storing persistent data on the client side?

Removable answered 3/4, 2009 at 15:21 Comment(1)
Possible duplicate of Persist variables between page loadsGunman
D
11

You may store data in window.name, which can hold up to 2MB of data (!).

/* on page 1 */
window.name = "Bla bla bla";

/* on page 2 */
alert(window.name); // alerts "Bla bla bla"

Edit: Also have a look at this Ajaxian article regarding this.

Note that other sites in the same tab/window does also have access to window.name, so you shouldn't store anything confidential here.

Darr answered 3/4, 2009 at 15:30 Comment(5)
There seem to be some security concerns with this method. Have you used it before? Any potential issues you found?Interrupted
Yes, I've used it (mostly for caching though). Other sites in the same tab/window may read or write the window name, so it's not really a safe place to store data in – but for caching and such, I think it's great.Darr
Those other sites could also just overwrite your data, so it's not very reliable either.Clouet
Any idea on how compatible this is (eg. minimum browser required, mobile, etc.)?Keynes
With the advent of the Web Storage API this answer is now massively obsolete. Even when this answer was given, this was a very bad idea. The window.name property is not intended to hold state.Technocracy
K
23

You can use the Web Storage API (Window.localStorage or Window.sessionStorage). Check out this article on html5doctor for a more in-depth explanation. The Web Storage API is supported by all modern browsers at this point.

The read-only localStorage property allows you to access a Storage object for the Document's origin; the stored data is saved across browser sessions. localStorage is similar to sessionStorage, except that while data stored in localStorage has no expiration time, data stored in sessionStorage gets cleared when the page session ends — that is, when the page is closed.
https://developer.mozilla.org/en/docs/Web/API/Window/localStorage

As highlighted above:

There are two methods of setting and getting properties via the Window.localStorage and Window.sessionStorage API's:

  1. Access the properties directly:

    localStorage.name = 'ashes999';
    console.log(localStorage.name); // ashes999
    delete localStorage.name;
    console.log(localStorage.name); // undefined
    
    sessionStorage.name = 'ashes999';
    console.log(sessionStorage.name); // ashes999
    delete sessionStorage.name;
    console.log(sessionStorage.name); // undefined
    
  2. Use the Storage.setItem, Storage.getItem, and Storage.removeItem API methods.

    localStorage.setItem('name', 'ashes999');
    console.log(localStorage.getItem('name')); // ashes999
    localStorage.removeItem('name');
    console.log(localStorage.getItem('name')); // undefined
    
    sessionStorage.setItem('name', 'ashes999');
    console.log(sessionStorage.getItem('name')); // ashes999
    sessionStorage.removeItem('name');
    console.log(sessionStorage.getItem('name')); // undefined
    

Caveats:

  • Browsers may impose limitations on the storage capacity per origin of the Web Storage API, but you should be safe up to 5MB.
  • The Web Storage API is limited by the same origin policy.
  • Access to Web Storage from third-party IFrames is denied if the user has disabled third-party cookies in Firefox
Keynes answered 1/3, 2014 at 12:34 Comment(4)
I've edited to expand your answer a bit here as this is the most easily found duplicate target at the moment and the Web Storage API method was a bit underrepresented. If my edits strayed to far from the original intent of your answer or are found in any way harmful, please feel free to roll them back.Schleswigholstein
@TinyGiant I think you pretty much rewrote my answer. I'd rather you post it as your own (and get your own rep credited for it); especially considering that this is not the accepted nor top-voted answer at the moment. If you feel that's Too Much, no worries, I won't roll it back.Keynes
I don't feel like adding another answer saying what was already said here. I don't much care about the rep gained from it either. I just care about the usefulness of the Q&A here on Stack Overflow.Schleswigholstein
@TinyGiant okay, then I guess we're in agreement to leave this as-is. Thanks for letting me know.Keynes
D
11

You may store data in window.name, which can hold up to 2MB of data (!).

/* on page 1 */
window.name = "Bla bla bla";

/* on page 2 */
alert(window.name); // alerts "Bla bla bla"

Edit: Also have a look at this Ajaxian article regarding this.

Note that other sites in the same tab/window does also have access to window.name, so you shouldn't store anything confidential here.

Darr answered 3/4, 2009 at 15:30 Comment(5)
There seem to be some security concerns with this method. Have you used it before? Any potential issues you found?Interrupted
Yes, I've used it (mostly for caching though). Other sites in the same tab/window may read or write the window name, so it's not really a safe place to store data in – but for caching and such, I think it's great.Darr
Those other sites could also just overwrite your data, so it's not very reliable either.Clouet
Any idea on how compatible this is (eg. minimum browser required, mobile, etc.)?Keynes
With the advent of the Web Storage API this answer is now massively obsolete. Even when this answer was given, this was a very bad idea. The window.name property is not intended to hold state.Technocracy
C
3

If you really need to do this (and I definitely have doubts that it's a good idea at all), your extra javascript file idea isn't as bad as you think. Just use JSON notation to keep the data and it's pretty easy to load and unload as needed. If you keep in some well-thought-out logical divisions you should be able to update just parts of it on demand, as well.

Clouet answered 3/4, 2009 at 15:26 Comment(3)
@Itay I edited this question because it is being used as a duplicate target for new questions and I deemed it in need of some clean up and organization.Schleswigholstein
@TinyGiant Really? That's scary. The info in most of the answers here is kinda stale, given html5 local storage is now pretty safe to use.Clouet
@Joel which is why I expanded the Web Storage API answer. If you notice anything here that can be improved through editing and feel up to the task, please take the time to do so.Schleswigholstein
L
2

What about Google Gears. It is made for offline storage, but I think it might work. http://code.google.com/apis/gears/design.html

From the documentation:

Storing User's Data

Applications that are more than just static files have data that is typically stored on the server. For the application to be useful offline, this data must be accessible locally. The Database module provides a relational database for storing data. On the Architecture page you will find a discussion of strategies for designing the local storage that your application needs.

When an offline application reconnects, you will need to synchronize any changes made in the local database with the server. There are many different approaches to synchronizing data, and there is no single perfect approach. The Architecture page describes some strategies for synching.

An additional feature of the Gears database is Full-Text Search, providing a fast way to search text within a database file. Read the details here.

Lotuseater answered 3/4, 2009 at 15:51 Comment(2)
Requires an extra component installed in the browser, which breaks one of his requirements.Clouet
Wow, that's nice, just got downvoted for an 8 years old answer, which made sense when it was answered, but is completely out of track as of now.Lotuseater
B
0

The Web Storage API has a limit of 5MB for local storage, but it's possible to store greater amounts of data on the client-side using IndexedDB. In some newer browsers, it is also possible to cache data for offline use using Service Workers.

URL fragments can also store client-side data, though they can store only a few thousand characters in most browsers.

Client-side storage is usually limited to just one origin, though it is possible to share it between origins using postMessage().

Beanfeast answered 5/2, 2021 at 0:13 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.