Closed caffodian closed 8 years ago
We currently use store.js
. so one initial take on this would be to determine if the store wrapper is present, if so, use that. else use the localstorage API directly, and try to handle errors properly.
This will be quite difficult to test.
I'm not convinced that disabling DOM Storage is actually the same as disallowing it. Disabling DOM Storage makes localStorage
null
. But the production stacktrace has something like Access is denied
By spec,
it actually throws an exception:
https://mathiasbynens.be/notes/localstorage-pattern#comment-9
So one thing to verify is whether or not store.js uses this pattern.
If so, great, let's just swap.
If not, this plugin needs to keep a state of whether or not localStorage is available, based on the results of that ugly try/catch idea.
Not currently a huge fan of the existing "roll your own suggestions by just putting everything into a string, separated by nbsps" implementation...
Possible way to manually test it: go into private browsing mode in Chrome?
Found #23 while testing this, which makes manual testing quite annoying, since you can't consistently typo a word without the wrapped nbsps.
Next problem: how to properly mock the different localstorage states. sinon doesn't seem very happy with me attempting to mock localStorage.getItem, but I may be doing something wrong. error message very cryptic.
Possible way to test this: customers reported it when we were not a trusted site in IE.
fixed in #24
Some of our customers have LocalStorage disabled as an IT policy, which results in a trace like this: