オフライン日記はロマン。現実は IndexedDB と殴り合い（途中）

「オフラインでも書ける日記」は聞こえが良すぎる。でも現実は、キュー、リトライ、重複、競合、添付画像が一気に襲ってくる。daily-snap では、まずロマンを捨てずに、足場から入った。Service Worker と IndexedDB、同期のルールを先に決めないと、あとで「データが二重に…」が始まる。

方針としては、追記中心の日記なら append 前提で衝突を減らすのが筋がいい。それでもズレる。だからユーザー回答としても「履歴を保持して UI で復元できる」方向を採用した。LWW だけだと、人間の記憶とログの記憶が食い違ったときにキツい。

オフラインキューを設計するときの「最低限の決めごと」

実装の細部はリポジトリの進行に合わせて変えてよいが、決めないと後で地獄になる項目は先に言語化しておきたかった。

1. 冪等性: 同じ追記が二回送られたとき、サーバー側で二重登録にならないキーは何か（クライアント生成 ID、ハッシュ、タイムスタンプ＋本文）。
2. 順序: オフライン中に A→B と追記したとき、復帰後も A→B の順を保証するか。保証しないなら UI でどう見せるか。
3. 失敗の見せ方: リトライ中 / 永久失敗 / 競合の 3 状態をユーザーにどう出すか。無言の失敗だけは避けたい。
4. 画像: テキストのみ先に送るか、画像付きは別キューに分けるか。後者は 04-15 のストレージ抽象と直結する。
5. Service Worker 更新: 新しいバンドルが来たとき、ユーザーに「更新があります」をどう見せるか（04-14 の別セクションでも触れたが、オフラインほど効く）。

ただし、現状は開発途中。ここは盛らない。理想の節目（インストール可能、オフライン追記、復帰同期）と、いま動いている範囲を分けて書くのがこの記事の目的だ。未完成を隠すと、読者も未来の自分も騙すことになる。

画像のオフラインは特に難しい。テキストよりサイズが増え、失敗時のリトライも重い。だから MVP では「テキスト優先」で割り切る判断もありうる。それでもストレージ抽象（後述の GCS 本番）とセットで考えると、**「いったんローカルに置いて、あとでアップロード」**の設計に寄せやすい。

途中でも書く価値

未完成の機能ほど、設計意図が消えやすい。だから「恥ずかしいから書かない」をやめる。オフラインは特に、ユーザー体験の期待値が高い分、言葉を選ばないと誤解が増える。ここは丁寧に、できている/できていないを分ける。

小さな結論

オフラインは「保存」じゃなくて、あとで直す権利の設計だと思う。履歴と UI はそのための保険。完成まで行かなくても、方針は先に言語化する価値がある。

次の自分へ

オフラインのバグは再現が難しい。飛行機モードの手順、二端末同時、寝る前の追記、みたいな現実のシナリオをメモしておくと助かる。

スクショで残すなら

PWA インストール促し、オフライン時のエラー表示、オンライン復帰後の同期結果。開発途中でも「いまの挙動」のスナップショットは後で比較に効く。

Service Worker は更新の罠も運ぶ

キャッシュ戦略を誤ると、古いバンドルが残って「直したのに直ってない」が起きる。オフラインほど、更新の見せ方がユーザー体験になる。だから途中実装でも、リロード手順やバージョン表示をどうするかはメモしておきたい。

この回のまとめは、オフラインは 同期の美学が必要で、ロマンだけだとユーザーが裏切られる。だから履歴と UI を保険にする。完成度より、誠実な期待値調整を優先した。

補足として、オフラインの敵は「失敗」より 無言の失敗だ。UI に状態を出せるかどうかが、信頼の大半を決める。

もう一つだけ。オフライン対象をテキストに絞るのは割り切りだが、割り切りを プロダクトの説明に書くのは割り切りじゃない。誠実さの方がずっと難しい。

開発者向けのメモ

キューのデータ構造（どのフィールドで重複判定するか、リトライの指数バックオフを入れるか）は、最初は雑でいい。でも 冪等性の方針だけは早めに決める。決めないと、オンライン復帰のたびに世界が増殖する。

次は、画像パイプライン（圧縮と保存先）の話。ここは実装が進んでいる分、具体コードに寄せられる。

---

daily-snap 開発ログ
前: ローカルでは SSE が笑う…
次: 画像は AVIF/WebP で殴って、本番の置き場所は GCS に寄せた
索引: 04-02 · … 04-30