Use alternative for localForage
Closed this issue · 1 comments
This is an issue for the far off future.
So far, in Cocoda and in cocoda-sdk, we've been using localForage for persisting data locally in the browser. We don't particularly care about what it is actually doing, as long as it finds a solution for each browser that works.
It's not like we had any issues with localForage, but it is pretty big for what it does (8.5 kB minified + gzipped), I guess because it supports different drivers and makes sure it works in any browser. But since we're targeting only fairly modern browsers, we might not actually need such a solution.
One alternative that only uses local storage (localForage uses IndexedDB in modern browsers, I think) is store2. It is only 1.5 kB minified + gzipped, so less than 20% if localForage's size. However, there might be disadvantages of using it; I haven't looked into it extensively. Also, we would need to transition users from whatever localForage was using to this one.
If we focus on IndexedDB, there is also idb. It is only 1.3 kB minified + gzipped and simply a wrapper to makes IndexedDB more usable.
I mean, we could also just use native browser APIs, but from what I've gathered, both of them don't see to be very developer-friendly.
Anyway, something for the future.
Edit: A good article about this issue: https://mattwest.design/choosing-the-best-client-side-storage-technology-for-your-project/
However, that article also just recommends using localForage.
I'm closing this in favor of making the local mappings provider a separate package with #28.