feat: IndexedDB prototype#18
Conversation
| name: "womens-running-shoes", | ||
| date: Date.now(), | ||
| expire: Date.now() + (30 * 86400000), | ||
| }); |
There was a problem hiding this comment.
when we use this for real we should generate our own id, probably something like ${owner}-${name} for quick lookup and to enforce the requirements.
There was a problem hiding this comment.
Yeah, I agree we should sit down and figure out a new schema for this now that we have a dB.
There was a problem hiding this comment.
my suggestion is for the primary key to be named key if possible and for it to be ${owner}-${name}.
In addition, we should have an index on the _expires key so we can easily find articles that have expired:
store.createIndex('_expires', '_expires');
Basically we use what is described here: https://github.com/MagniteEngineering/fledge.polyfill/blob/main/specifications/interest-groups.md but make it a flat structure instead of the owner -> group hierarchy.
- Update `id` field as key to `_key` - Create an index on `_expires` #18 (comment)
This is required because IndexedDB will error if you try to write over the key with the same key that already exists in the dB, thus since we're using the `owner-name` as the key, we need to stop trying to overwrite the dB entry each time the page is refreshed.
The concept here is to showcase that browser support for
IndexedDBis widespread and will work as a mechanism for storing Interest Groups and other auction data.This shows
IndexedDBworking locally and presumably in production, but from the same domain. It's currently using a wrapper library from Jake Archibald calledidb.Resources
To Do
IndexedDBprototype #18 (comment))Fixes: #16