Best practice around checking for localStorage access while using the persist plugin

[treyhunner]

In my Sentry logs I see that accessing localStorage raises an exception in some browsers. In that case let storage=localStorage raises an error:

Failed to read the 'localStorage' property from 'Window': Access is denied for this document.

And I also see that sometimes localStorage is null. In that case accessing storage.getItem in the storageHas function raises an error:

Cannot read properties of null (reading 'getItem')

What's the best practice for falling back to either non-persistent storage or no storage (it doesn't much matter for my use case)?

And should the persist plugin be modified to work without raising an error by default even if/when localStorage is non-functional?

[ekwoka]

🤔 I would suspect that localStorage being disabled would really be down to that user using some kind of privacy browser, or it's traffic from a non-browser environment that hasn't added the full browser APIs.

All major browsers since like 2009 support localstorage.

I don't know if it's work having Alpine do it's own check and just silently passing through? or maybe warning?

But for now you can shim it. It just needs getItem and setItem so you could run code before Alpine does that stuff that just does like

window.localStorage = window.localStorage ?? {
  getItem() { return undefined },
  setItem() { }
}

[treyhunner]

thinking I would suspect that localStorage being disabled would really be down to that user using some kind of privacy browser, or it's traffic from a non-browser environment that hasn't added the full browser APIs.

All major browsers since like 2009 support localstorage.

I agree that this seems like users disabling localStorage in their own browsers. I have a couple users each week who seem to visit my site with this situation.

I just disabled localStorage in Chrome to test out your shim and it unfortunately doesn't work. accessing localStorage raises an error, but even when catching that error window.localStorage fails to be overwritten (assignments are ignored and subsequent localStorage accesses continue to raise an exception).

This patch seemed to fix all errors when testing locally in Chrome and Firefox with localStorage manualy disabled:

@@ -3,7 +3,13 @@
   function src_default(Alpine) {
     let persist = () => {
       let alias;
-      let storage = localStorage;
+
+      try {
+        let storage = localStorage;
+      } catch (e) {
+        storage = undefined;
+      }
+
       return Alpine.interceptor((initialValue, getter, setter, path, key) => {
         let lookup = alias || `_x_${path}`;
         let initial = storageHas(lookup, storage) ? storageGet(lookup, storage) : initialValue;
@@ -37,13 +43,15 @@
     };
   }
   function storageHas(key, storage) {
-    return storage.getItem(key) !== null;
+    return storage && (storage.getItem(key) !== null);
   }
   function storageGet(key, storage) {
     return JSON.parse(storage.getItem(key, storage));
   }
   function storageSet(key, value, storage) {
-    storage.setItem(key, JSON.stringify(value));
+    if (storage) {
+      storage.setItem(key, JSON.stringify(value));
+    }
   }

[ekwoka]

The try catch breaks the initialization of storage though.

Since let is block scoped.

You should initialize it outside the try catch.

Maybe move that to a function even.

If you want to make it a PR.

I'd probably also prefer a situation that the persist short circuits if there is no storage (either the default or one used for that persist) and doesn't hook up any of the reactivity. Just does normal value only.

No reason to keep checking if storage exists if we can learn early that it doesn't and skip all the logic entirely.