Speichern und Abrufen von JavaScript-Objekten in localStorage

Geschrieben von Nelson Michael✏️

Anmerkung des Herausgebers: Dieser Artikel wurde zuletzt am 7. August 2024 von Rahul Chhodde aktualisiert, um eine tiefergehende Untersuchung der Speicherung von Objekten in localStorage zu bieten, beispielsweise Techniken zur Serialisierung von JavaScript-Objekten mithilfe von JSON.stringify. und Situationen, in denen das Arbeiten mit und das Speichern mehrerer Objekte in localStorage erforderlich ist.

Die Web Storage API bietet JavaScript-basierte Mechanismen zum sicheren Speichern und Zugreifen auf Daten als Schlüssel-Wert-Paare im Browser des Clients. Dies ist nützlich, um nicht vertrauliche Daten wie Benutzereinstellungen, Anwendungsstatus und in einigen Fällen sogar API-Antworten zu speichern.

Die beiden Mechanismen der Web Storage API, localStorage und sessionStorage, ermöglichen es Entwicklern, Daten dauerhaft und temporär zu speichern. Diese gespeicherten Daten können später leicht abgerufen und zur Erleichterung des Benutzers verwendet werden.

In diesem Artikel erfahren Sie, wie Sie JavaScript-Objekte in Strings umwandeln und in JSON-Strings analysieren, um sie in localStorage zu speichern, und dann den Vorgang umkehren, um die Daten abzurufen. Außerdem gehen wir kurz auf die wichtigsten Unterschiede zwischen localStorage, sessionStorage und HTTP-Cookies ein und heben die Vor- und Nachteile der Verwendung von localStorage gegenüber den beiden anderen hervor.

Was ist localStorage?

Das localStorage Objekt ist einer der beiden Mechanismen von Web Storage, die es Entwicklern ermöglichen, Daten im Browser des Clients zu speichern, die auch nach dem Schließen des Browserfensters bestehen bleiben. Auf diese gespeicherten Daten kann in einer bestimmten Domäne mithilfe benutzerfreundlicher API-Methoden zugegriffen werden, von denen einige unten aufgeführt sind:

localStorage.setItem("myDataKey", "My data");
localStorage.getItem("myDataKey"); // "My data"
localStorage.removeItem("myDataKey");

Beachten Sie, dass auf die im localStorage-Objekt einer Domäne gespeicherten Daten nur von Seiten desselben Ursprungs zugegriffen oder diese geändert werden können, was in diesem Fall gemeinsam für Protokoll, Domäne und Port steht. Sie können dieses Verhalten mithilfe dieser Methoden in der Entwicklerkonsole Ihres Browsers überprüfen.

Laut W3Schools speichert das localStorage-Objekt die Daten ohne Ablaufdatum. Die Daten werden auch dann nicht gelöscht, wenn der Nutzer die Seite verlässt oder das Browserfenster schließt; Es wird für zukünftige Sitzungen verfügbar sein. Diese Fähigkeit, die Daten zu speichern, wird in der Software- und Webentwicklung als Datenpersistenz bezeichnet.

Verwendung von sessionStorage vs. localStorage

Der zweite Web Storage-Mechanismus, sessionStorage, ist nahezu identisch mit localStorage, unterscheidet sich jedoch in zweierlei Hinsicht: Er speichert vorübergehend Daten für die angegebene (oder aktuelle) Registerkarte und tut dies nur für einen begrenzten Zeitraum.

Das sessionStorage-Objekt bleibt aktiv, solange die entsprechende Registerkarte geöffnet ist, und speichert die Daten auch beim erneuten Laden und Wiederherstellen der Seite. Wenn eine Webseite in einen Browser-Tab geladen wird, erstellt sessionStorage, falls verwendet, eine neue Seitensitzung und weist sie diesem Tab zu. Diese Seitensitzung ist nur für diesen bestimmten Ursprung gültig, auf den in dieser bestimmten Registerkarte zugegriffen wird.

Hinweis: Die in jeder Art von Webspeicher gespeicherten Daten sind für jedes Protokoll einer bestimmten Seite unterschiedlich. Dies bedeutet, dass Daten, die auf einer Site gespeichert sind, auf die über HTTP zugegriffen wird, in einem anderen sessionStorage-Objekt gespeichert werden als Daten, die auf derselben Site gespeichert sind, auf die über HTTPS zugegriffen wird.

Hauptunterschiede zwischen sessionStorage und localStorage

localStorage und sessionStorage funktionieren ähnlich, der Hauptunterschied besteht jedoch darin, dass die in localStorage gespeicherten Daten persistent sind, zwischen Registerkarten desselben Ursprungs gemeinsam genutzt werden und für diesen bestimmten Ursprung ewig bestehen bleiben, es sei denn, der Speicher des Browsers wird gelöscht oder wir löschen localStorage mithilfe von JavaScript oder manuell.

Mit Chrome DevTools können Sie die Daten sowohl in localStorage- als auch in sessionStorage-Objekten anzeigen und die soeben behandelten Unterschiede beobachten. Hier ist ein Screenshot, der das Auffinden beider Objekte auf der Registerkarte „Anwendung“ von DevTools zeigt:

Um Informationen wie Benutzereinstellungen, Anwendungszustände, API-Antworten und größere Datenmengen zu speichern und wiederzuverwenden, um die wahrgenommene Leistung zu verbessern, wählen wir localStorage gegenüber sessionStorage, da diese Informationen bestehen bleiben sollten, um gelegentlich zur Personalisierung und Aktualisierung der Benutzererfahrung verwendet zu werden .

Hinweis: Wenn der letzte private Tab geschlossen wird, werden die im localStorage-Objekt einer in einem privaten Tab oder im Inkognito-Modus geöffneten Website gespeicherten Daten gelöscht, was sinnvoll ist, da es sich um eine private Browsersitzung handelt.

Web Storage vs. HTTP-Cookies

HTTP-Cookies sind ein herkömmlicher Mechanismus zum Speichern kleiner Datenbits, die während jeder HTTP-Anfrage zwischen dem Client und dem Server ausgetauscht werden.

Sobald eine Verbindung zu einem Client besteht, generiert der Server bestimmte Informationen, speichert sie in einer Cookie-Datei und sendet sie an den Browser des Clients. Diese Informationen sind mit einer eindeutigen ID für jeden Benutzer und seinen Computer gekennzeichnet, die dem Server hilft, den Benutzer zu identifizieren, wenn eine Verbindung hergestellt wird.

Cookies enthalten Informationen wie Authentifizierungs- und Sitzungsdaten, CSRF-Tokens, Tracking-Daten und kleine, standortspezifische Benutzereinstellungen, um die Benutzererfahrung zu personalisieren. Sie können jedoch ein Albtraum für die Privatsphäre sein. Wir werden dies im folgenden Abschnitt besprechen.

Warum und wann werden Cookies verwendet?

Cookies sind nicht die empfohlene Lösung zur Speicherung größerer Datenmengen auf Client-Seite. Sie eignen sich besser für die Sitzungsverwaltung und sind eine der am weitesten verbreiteten Lösungen dafür.

Bei jeder Anfrage werden Cookies in den HTTP-Headern vom Browser an den Server gesendet, im Gegensatz zur Verwendung von localStorage oder sessionStorage, auf die die Anwendung nur als clientseitiger Datenspeicher zugreift und die anfällig für Schwachstellen sind.

Für die Sitzungssicherheit können als „Secure“ und „HttpOnly“ gekennzeichnete Cookies die Wahrscheinlichkeit eines Sitzungs-Hijackings minimieren und XSS- (Cross-Site-Scripting) und CSRF-Angriffe (Cross-Side-Request-Forgery) auf den Browser des Benutzers während der Sitzung begrenzen.

Wann Sie keine Cookies verwenden sollten

HTTP-Cookies sind seit langem ein Standard und es ist nicht immer möglich, Ihre Apps zu 100 % frei von Cookies zu halten. Es gibt jedoch einige Fälle, in denen Sie sie möglicherweise vermeiden möchten:

• Cookies sollen bei jeder Anfrage an den Server übertragen werden, weshalb sie klein gehalten werden und keine Daten mit mehr als 4 KB enthalten können. Dies macht sie ungeeignet für die Zwischenspeicherung großer Werte wie riesiger Benutzerpräferenzdaten, Anwendungsstatus, vom Benutzer erstellter Dokumente usw.
• Cookies von Drittanbietern stellen ein ernstes Datenschutzrisiko dar, da die von Ihnen besuchte Website sie weder erstellt noch besitzt. Solche Cookies sind normalerweise mit der Verfolgung von Benutzerdaten verbunden, was sie verdächtig macht, und viele Browser bereiten sich darauf vor, sie einzuschränken, um die Privatsphäre der Benutzer zu schützen

Diese Punkte ermöglichen es uns, unsere Unmengen an nicht sensiblen Daten in localStorage zu speichern. In solchen Situationen ist es oft erforderlich, komplexe Daten wie JavaScript-Objekte lokal zu speichern, was einen etwas anderen Ansatz erfordert.

So speichern Sie ein JavaScript-Objekt in localStorage

Moderne Web-Apps erfordern oft das lokale Speichern von JavaScript-Objekten, um Offline-Zugriff zu ermöglichen, den Anwendungsstatus wiederherzustellen oder eine API-Antwort zwischenzuspeichern, um wahrgenommene Leistungsvorteile zu erzielen.

Beachten Sie, dass solche Daten keine vertraulichen Informationen enthalten sollten, da sie nach der Speicherung im Web Storage für jeden JavaScript-Code zugänglich sind, der auf demselben Ursprung ausgeführt wird.

Beginnen wir damit, ein grundlegendes Verständnis für die Arbeit mit localStorage zu erlangen, indem wir seine Methoden und Eigenschaften für verschiedene Anwendungsfälle untersuchen:

• setItem(): Fügt Daten zu einem Web Storage-Objekt hinzu, indem es seine beiden Argumente, einen Schlüssel und einen Wert verwendet: localStorage.setItem("key", "value")
• getItem(): Gibt den Wert des Schlüsselnamens zurück, der an ihn übergeben wurde: localStorage.getItem("key")
• **removeItem()**: Entfernt einen Schlüssel, der ihm mit seinem entsprechenden Wert übergeben wurde: localStorage.removeItem("key")
• clear(): Löscht alle Schlüssel-Wert-Paare im zugehörigen Speicher und sollte mit Vorsicht verwendet werden: localStorage.clear()
• **key()**: Gibt den Schlüssel am angegebenen Index im Speicher zurück: localStorage.key(0)
• length: Gibt die Gesamtzahl der im zugehörigen Speicher gespeicherten Schlüssel-Wert-Paare zurück: localStorage.length

Weitere Informationen zu diesen Methoden finden Sie in den Web Storage API-Dokumenten von MDN.

Das folgende Beispiel zeigt die Datenpersistenz, die mit einigen dieser Web Storage-API-Methoden erreicht wird. Klicken Sie auf die Schaltfläche Aktuelle Zählung, führen Sie den CodePen erneut aus und sehen Sie, wie die Zähldaten mit localStorage:

bestehen bleiben

Sehen Sie sich den Pen localStorage in Aktion von Rahul (@_rahul) auf CodePen an.

In der Demo oben werden jedes Mal, wenn Sie auf die Schaltfläche „Zählen“ oder „Löschen“ klicken, mehrere localStorage-Elemente erstellt, gelesen oder geändert, und die Änderungen an den entsprechenden Werten werden im Frontend widergespiegelt.

Serialisierung von JavaScript-Objekten

Das Speichern von JavaScript-Objektdaten im Web Storage ist etwas knifflig, da Sie nur Zeichenfolgenwerte speichern können. Wenn wir versuchen, ein JavaScript-Objekt zu speichern, ohne es zuerst in einen String umzuwandeln, erhalten wir eine [object Object]-Antwort, wie im Bild unten gezeigt:
[Objekt Objekt] ist eine Zeichenfolgendarstellung einer Objektinstanz, deren Wert zum Zeitpunkt der Speicherung der Daten nie gelesen wurde, was zu Datenverlust führt.

The correct way to store object data to localStorage is to first convert it to a string. Then, we can move on to the storage procedure.

This object-to-string conversion of object data is known as serialization, and turning this converted string back to object data is called deserialization. Let’s briefly discuss two important JSON methods that are responsible for object data serialization and deserialization:

• JSON.stringify: Converts any object value into a string JSON (serialization)
• JSON.parse: Turns a JSON string into its corresponding object or value (deserialization)

Now, utilizing the setItem method with JSON stringify, we can easily convert a JavaScript object to a JSON string and push it to the localStorage object. Here’s a quick example to demonstrate this:

const userObj = {
  name: "John Doe",
  age: 32,
  gender: "Male",
  profession: "Optician" 
};

localStorage.setItem("userObj", JSON.stringify(myObject));

Now, if we try to retrieve the object data without deserializing it, we will receive a JSON string instead of an object, which makes sense, as it is what we stored to localStorage.

We need to deserialize this JSON string data using the JSON parse method to turn it back into a JavaScript object:

let newObject = localStorage.getItem("myObject");
console.log(JSON.parse(newObject));

Here, we retrieved our previously set JavaScript object using the getItem method on the localStorage object and saved it into a variable. Next, we parsed that string into a JavaScript object and finally logged it to the console:

More examples of storing objects in localStorage

• Storing Date objects: Constructing an object using the current timestamp using the Date object and a random value, and saving it to or clearing it from the localStorage using button inputs
• Persisting remote data: Fetching remote data from a dummy API and storing it in localStorage; the network fetch in this example is only triggered when no associated data in localStorage is found

Storing multiple objects in localStorage

Let’s say we have a bunch of similar objects, and we want to group all of them and store them as one JSON string in the localStorage. We can turn them into an object array and then serialize them as shown below:

const todos = [todo1, todo2, todo3];
localStorage.setItem("todos", JSON.stringify(todos));

If you have bigger chunks of data to work with, you might want to store each of them with separate keys, but accessing all of them quickly can be done using this namespace approach:

// Storing
localStorage.setItem('todos:1', JSON.stringify(todo1));
localStorage.setItem('todos:2', JSON.stringify(todo2));

// Retrieving
const keys = Object.keys(localStorage).filter(key => key.startsWith('todos:'));
const todos = keys.map(key => JSON.parse(localStorage.getItem(key)));

Limitations of storing objects to localStorage

localStorage is one of the mechanisms of the Web Storage API. The API provides 5-10MB of storage per origin, and the exact storage may vary depending on the browser. Respecting this size limit, you should avoid storing more than 3-4MB of data per origin in Web Storage objects.

Keep in mind that Web Storage API operations are synchronous and block the main thread, therefore performing heavy operations using it may block other resources from loading in the browser.

Types of data that can be stored as a JSON string

Primitive data types like numbers, Booleans, and strings are JSON-safe, while values like functions, undefined, symbols, and Date objects are not JSON-safe. If no JSON-safe values are found during conversion, they are either excluded from an object or changed to null in an array.

Note: Some of these such values can be made JSON-safe, for example, we used the toISOstring method with the Date object in this example to make it JSON-safe before pushing it to Web Storage.

Conclusion

In this article, we learned a useful technique for storing multiple bits of information in a single localStorage key and using the JSON stringify and parse methods. We also covered some working demonstrations that apply this approach to different tasks, as well as storing and retrieving multiple JavaScript objects from localStorage.

In summary, we should be mindful of the data we store locally, and take advantage of the localStorage object to store JavaScript objects by first converting them to JSON strings with the JSON.stringify method and then turning them back to objects with the JSON.parse method.

---

LogRocket: Debug JavaScript errors more easily by understanding the context

Debugging code is always a tedious task. But the more you understand your errors, the easier it is to fix them.

LogRocket allows you to understand these errors in new and unique ways. Our frontend monitoring solution tracks user engagement with your JavaScript frontends to give you the ability to see exactly what the user did that led to an error.

LogRocket zeichnet Konsolenprotokolle, Seitenladezeiten, Stack-Traces, langsame Netzwerkanforderungen/-antworten mit Header-Körpern, Browser-Metadaten und benutzerdefinierten Protokollen auf. Es wird nie einfacher sein, die Auswirkungen Ihres JavaScript-Codes zu verstehen!

Probieren Sie es kostenlos aus.

Das obige ist der detaillierte Inhalt vonSpeichern und Abrufen von JavaScript-Objekten in localStorage. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!