Catch exceptions when accessing `indexedDB` and `localStorage`

gruns / ImmortalDB

:nut_and_bolt: A relentless key-value store for the browser.

MIT License

3.05k stars 61 forks source link

Catch exceptions when accessing `indexedDB` and `localStorage` #43

Closed joneschrisg closed 4 years ago

joneschrisg commented 4 years ago

In some browsers in some contexts, just accessing window.indexedDB and window.localStorage can throw exceptions. Ignore those exceptions so that ImmortalDB continues to work.

Here's the QA procedure I ran on this PR:

npm run format
npm run lint: result was clean
npm run build
npm run start
Checked that setting, getting, and removing a key works across cookies, IndexedDB, and localStorage.

I committed the artifacts produced by npm run build --- let me know if that's done by a separate release procedure.

Thanks!!

gruns commented 4 years ago

Right on, brother. Awesome PR.

For my own notes, which browser(s) raise on just touching window.indexedDB and/or window.localStorage? Brave with the latter?

joneschrisg commented 4 years ago

Definitely Brave with window.localStorage. Upstream Chrome can be configured similarly. I don't recall whether window.indexedDB raised too, or we added it defensively; I believe it was defensive.

gruns commented 4 years ago

Merged! This will roll out in the next version.

One note: of

Here's the QA procedure I ran on this PR:

npm run format
npm run lint: result was clean
npm run build
npm run start

Checked that setting, getting, and removing a key works across cookies, IndexedDB, and localStorage.

what could have been better explained or better? Or, in other words, how would you improve the dev + testing loop (beyond automated tests)?

Thank you again, Chris. Don't hesitate to let me know if there's anything else I can do for you.

joneschrisg commented 4 years ago

Thanks!!

what could have been better explained or better? Or, in other words, how would you improve the dev + testing loop (beyond automated tests)?

Automated tests are always great, of course :). Here are two smaller suggestions:

Create GitHub actions to automate the lint and build checks. That's not full automated testing of course, but pretty good effort/reward tradeoff because they're low effort.
For the remaining manual checks, and general style and process guidelines, create a CONTRIBUTING.md. I would recommend listing the manual QA procedure explicitly as a sequence of steps contributors should follow, with expected results.

[Edit: even better, create a PR template.]