gdotdesign
commented
2 years ago The best solution would be to create an IndexedDB module like LocalStorage and then stores and providers could use that. But for your current use case I would create a wrapper for localForage https://localforage.github.io/localForage/ in a package with the same API that we have now for LocalStorage.
Hi folks! I think I'm going to want to migrate an app to use IndexedDB API fairly soon, right now I'm using LocalStorage but I'll want better performance so I'm getting the itch to plan next steps.
I have various
stores which at present persist data using different in LocalStorage. Where I'm getting anxious is that the values for some of these keys are getting large, and on every update I serialize an in-memory object and write it to LocalStorage again. These values will just keep getting larger and more frequent, and I can't afford to repeatedly pause for O(n) time as n grows larger.So the solution I'm picturing is to migrate these stores to keep their data in an IndexedDB, and then every update just creates a record in a table which should take O(log n) time to update an index. To use that API, you make a request to open a database and eventually get back an object representing your connection to that db, which you want to reuse. You may also receive
IDBVersionChangeEvents signaling that the schema has changed & a migration is necessary.These seem like a good use case for a
Provider.IndexedDBin Mint. But unfortunately for how my app is designed, you can't make use of a provider in a store. It doesn't make sense to me to tie an IndexedDB table to a single component either. How do you picture I might structure this system? Is there a particular way you'd like to see it done in order to create the potential for it to become part of the Mint standard library?