localStorage ist...
- Gut! Es ist eine unglaublich einfach zu bedienende API.
localStorage.setItem('name', 'Chris'); let name = localStorage.getItem('name');
localStorageist eine synchrone API, die den Haupt-Thread blockiert, und jedes Mal, wenn Sie darauf zugreifen, verhindern Sie potenziell, dass Ihre Seite interaktiv wird.
Chrome hat eine Idee (hier ist der Vorschlag) für deren Neuerfindung. Letztendlich ist die API sogar noch einfacher.
import { storage } from 'std:kv-storage';
storage.set('name', 'Chris');
storage.get('name');Aber! Sie ist asynchron, daher kann ich await davor verwenden, diese Dinge zu tun, ohne etwas zu blockieren. Diese Demo funktioniert derzeit in Chrome Canary.
Siehe den Pen
eXadrq von Chris Coyier (@chriscoyier)
auf CodePen.
Was zum Teufel ist mit dieser Zeile los?
import { storage } from 'std:kv-storage';Sie nennen es ein „eingebautes Modul“. Mit anderen Worten, etwas, das Sie importieren können, das aber keine Netzwerkanfragen stellt, da es in den Browser integriert ist. Ein ziemlich interessanter Ansatz.
Philip fährt fort
Das Nicht-Exponieren von eingebauten Modulen global hat viele Vorteile: Sie fügen keinem neuen JavaScript-Laufzeitkontext (z. B. einem neuen Tab, Worker oder Service Worker) Overhead beim Start hinzu und sie verbrauchen keinen Speicher oder CPU, es sei denn, sie werden tatsächlich importiert. Darüber hinaus besteht nicht die Gefahr von Namenskollisionen mit anderen in Ihrem Code definierten Variablen.
Dies ist auf indexedDB aufgebaut. Wenn Sie also damit experimentieren und die Werte löschen müssen oder Ähnliches, tun Sie dies dort (DevTools > Application > Storage > IndexedDB). Es wird faszinierend sein zu sehen, ob sich das durchsetzt und ob neue JavaScript-Funktionen als eingebaute Module ausgeliefert werden. Ich habe keine Ahnung, ob andere Browser dies für eine gute Idee halten oder nicht.
localStorage macht also keine Netzwerkanfrage... also, es sei denn, Ihr Computer ist extrem langsam, würden Sie den Verzögerung überhaupt bemerken?
Und da die Begründung für localStorage als Problem aus dem Jahr 2012 stammt, hier sind einige andere Informationen aus dem Jahr 2012, die dies zu widerlegen scheinen. Was würden die Benchmarks jetzt sagen?
https://www.webdirections.org/blog/localstorage-perhaps-not-so-harmful/
Wie wird es sich im Inkognito-Modus unter iOS verhalten?
(um nicht in die gleiche Falle wie LocalStorage zu tappen: https://stackoverflow.com/questions/14555347/html5-localstorage-error-with-safari-quota-exceeded-err-dom-exception-22-an)
Hier ist also ein großes Problem mit localStorage, das mich absolut wahnsinnig macht: Viele, viele Entwickler greifen darauf zu, ohne einen try/catch-Block zu verwenden. Das passiert überall, oft auch in Frameworks und Polyfills. Das muss aufhören.
Ich weiß nicht, ob das strikt ein Firefox-Ding ist, aber Firefox wird mit einem Sicherheitsfehler abstürzen, wenn Sie versuchen, auf localStorage oder indexedDB auf einer Website zuzugreifen, die keine Cookies verwenden darf. Für die extrem sicherheitsbewussten Benutzer, die nur Cookie-Domänen zulassen und den Rest deaktivieren, bricht dies viele Websites. Die meisten dieser Websites werden überhaupt nicht gerendert, da der Sicherheitsfehler das Laden anderer wichtiger Komponenten unterbricht.
Die Moral: Versuchen Sie niemals, niemals auf localStorage, sessionStorage oder indexedDB zuzugreifen, ohne einen try/catch-Block zu verwenden. Dasselbe gilt für zukünftige Entwicklungen, die vielleicht kommen. Immer umhüllen.
funktioniert auch nicht in Canary
Fehler
Mixed Content: Die Seite „https://css-tricks.de/“ wurde über HTTPS geladen, hat aber ein unsicheres Skript „std:kv-storage“ angefordert. Diese Anfrage wurde blockiert; der Inhalt muss über HTTPS geladen werden.
Wie löse ich das?