Daxie.js(IndexedDB)を利用しての感想
Dexie.js - Minimalistic IndexedDB Wrapper
The easiest way to use IndexedDB. A lightweight, minimalistic wrapper that provides a straightforward API for developers using IndexedDB.
v3.2.2で利用。
Daxie.jsの良い点
- (今となっては当然だが)PromiseによるAPIと型定義がある。
- React(等)のビルトインサポートがある
- TypeScriptのサポートがそこそこある
- トランザクションがシンプル、必要最低限で使いやすい
- 基本的には競合しうるのは、async/awaitでの並行した処理、他タブの並列した処理、かな?
- あとは worker を使うと他タブと同様のことが起こるのかな?
- バージョンとマイグレーションのシステム
- マイグレーションは命令的に記述できる。
- テーブルはバージョンを持ち、それまでのバージョン上の変更をすべて適用する、という挙動をさせることができる。(そのためには、過去のマイグレーションはすべて保持したままにしておく、いじらない、などを守る必要があるが)
LocalStorageとIndexedDB、どちらを使うべきか
個人的な感覚の部分もある。
- 一般的にまず言われるのは容量。 5MBで足りないのであればIndexedDBの方が良いとされる。
- 例えば平均50文字1000行のレスポンスを保存すると、localStorageだと100個程度が上限となる(ブラウザごとに5MBなので実際はもっと少ないだろう)
- SetやMap、RegExpなど、JSのいくつかのビルトインオブジェクトをそのままを保存したい場合
- 固定個の設定ではなく、可変個のデータを保存したい場合
- 例えば、選択したカラーテーマ、文字の大きさ、言語等を保存するだけならlocalStorageが良いだろう。
- 上記と似ているが、繰り返し構造を保存したい場合
- DBのテーブルで表現するのが自然な場合
- 他のタブとリアルタイムに同期したい場合
- 物によっては同期されると一気に体験が良くなると思う
改善が欲しい点
- TypeScriptのサポートの強化
- primary keyがnumberならば .add 等の返却もnumberになってほしい
- primary keyをrequiredにすると (
Table<{id: number, name?: string}>
のような) .add 等の自動でincrementされる状況でも指定しなければならない。optionalにすると、存在するprimary keyに対しoptionalなので対応が必要になる。
- デフォルト値
- これは完全に、自分でdaxieを作る場合にどうするか、という感覚の話。
- 個人的には primary key 以外すべて optional にしてフォールバックするようにするのがJS的で良いかなと思った。
- 加えて、zodで型を指定して、検証成功しなければそれもデフォルト値にするとか。
追記
The pain and anguish of using IndexedDB: problems, bugs and oddities
The pain and anguish of using IndexedDB: problems, bugs and oddities - indexeddb-problems.md