メインコンテンツへスキップ

データは、どこに残るのか

画面に本が並んだら、次は閉じた後を確かめます。同じブラウザに残す、別の端末でも開く、壊れたときに戻す。それぞれに必要な保存の仕組みを選びます。

  • レッスン 7 / 12
  • 19分

このレッスンで

終わる頃には、次ができるようになります

  • localStorageとデータベース:保存先を選ぶ
  • CRUD、変更、復元:データを育てる手順

画面に本が並んだら、次は閉じた後を確かめます。同じブラウザに残す、別の端末でも開く、壊れたときに戻す。それぞれに必要な保存の仕組みを選びます。

この回は、しくみを読むことと、実際の結果を確かめる練習を組み合わせます。付属見本はブラウザーだけで保存する一人用の版です。アカウント・データベース・共有は拡張課題として扱います。

画面に本が並んだら、次は閉じた後を確かめます。同じブラウザに残す、別の端末でも開く、壊れたときに戻す。それぞれに必要な保存の仕組みを選びます。
概念を表す生成挿画。製品の実画面ではありません。

練習用の「まちの読書メモ」を開く。見本には追加・読書状況の変更・JSONの書出があります。編集・削除・検索・復元・共有は、依頼文を使って追加する拡張課題です。練習用データを使い、一つのタブで操作してください。

localStorageとデータベース:保存先を選ぶ

付属の読書メモは、HTTPのlocalhostまたはHTTPSで開く練習用の見本です。追加、読書状況の変更、JSONの書出を試せます。この章の編集、削除、検索、並べ替え、読込による復元は、読者がAIへ頼んで追加する拡張課題です。見本に未実装の操作を試した結果を、保存の不具合と取り違えないようにしてください。

まちの読書メモに一冊追加して、ページを再読み込みします。本が消えたら、表示中のデータだけを変え、残る場所には保存していなかったかもしれません。画面に見えている状態と、閉じた後に取り出せる状態は違います。最初の保存テストは、追加した後にもう一度開いて読むことです。

ブラウザのlocalStorageは、そのサイトのデータをブラウザの保存領域に残す仕組みです。通常の利用では、タブを閉じた後も取り出せます。データはサイトの出所で区別され、同じ名前のサイトでもHTTPとHTTPSでは別の保存領域になります。試作から公開へ移るとき、この違いで空に見える場合があります。資料 STORAGE

一人用の保存と、端末をまたぐ保存

localStorage版は同じブラウザの保存領域を使います。アカウント付きの版は、通信先のデータベースで利用者と記録を対応させます。

同じブラウザのlocalStoragelocalStorageは、別のブラウザや端末へ自動同期しません。
認証とデータベースデータベース版にはownerIdとアクセスの確認が必要です。
localStorage版は同じブラウザの保存領域を使います。アカウント付きの版は、通信先のデータベースで利用者と記録を対応させます。

一人で使う最初の版では、localStorageに読書記録を保存できます。アカウントやサーバーを増やさず、追加、読書状況の変更、削除を試せます。ただし別のブラウザ、別の端末へ自動で同期する仕組みはありません。パソコンで入れた本がスマートフォンにないのは、この版では予定した動作です。

localStorageが受け取るのは文字列です。本の一覧をJSONの文字列に変えて保存し、取り出したら一覧に戻します。同じ保存名に書けば、その値は更新されます。容量不足などで保存が失敗する場合もあるので、画面を変えただけで保存完了と扱わず、失敗を伝える処理を用意します。資料 STORAGE_SET

保存する一件の形も決めます。この本の例では、固定のid、必須のtitle、任意のmemo、status、createdAtを持たせます。書名は120字まで、メモは1000字まで、状態は未読、読書中、読了のいずれかです。idは書名の変更や並べ替えでも変えません。同じ書名を二件入れても、別々に扱えるようにします。

このブラウザの記録が、いつまでも残るとは約束できません。利用者がサイトのデータを消す場合や、プライベート閲覧を終える場合があります。ファイルを直接開くfileのURLではlocalStorageの挙動も保証されません。保存の検証はローカルのWebサーバーを使い、必要な記録は書き出せるようにします。資料 STORAGE

外部に送らないメモでも、秘密の保管庫とは考えないでください。サイトで動くJavaScriptから読み取れるため、不正なスクリプトが動けば保存した内容に触れる可能性があります。最初の版には公開して差し支えない練習文だけを入れます。認証のための秘密の値を読書データと一緒に保存しません。資料 STORAGE_SECURITY

別の端末で自分の一覧を開きたいなら、サーバー側のデータベースを使う版を別の段階として考えます。テーブルは項目ごとの列と、一件ごとの行でデータを持てます。一件を区別する主キーにidを使えば、同じ書名でも対象を識別できます。この段階ではownerIdも加え、誰の記録かを扱います。資料 DB_TABLES

データベースを付けると、通信、アカウント、権限、運用も考える必要が出てきます。まず一人用の版で必要な操作を確かめ、端末間の利用が必要になったら進みましょう。保存先を選ぶ基準は、道具の評判より、誰がどこから使い、消えたときにどこまで戻したいかです。

一件のデータを決める

idは追加時に決め、編集しても変えません。titleは必須で120字までです。
memoは任意で1000字まで、statusは未読・読書中・読了から選び、createdAtは追加時刻を残します。
まずlocalStorage版を作ります。端末間の同期とownerIdは、アカウント付きの拡張で扱います。

手を動かす順番

  • 再読み込みして記録が残るか試す
  • 保存先と、その利用範囲を説明する
  • 一件の項目とidの扱いを決める
  • 消える条件と書き出し方法を確かめる

CRUD、変更、復元:データを育てる手順

データを扱う基本操作は、作る、読む、更新する、消すの四つです。英語の頭文字からCRUDと呼びます。読書メモなら、一冊を追加する、一覧を開く、状態を読了に変える、一件を削除する操作が対応します。ボタンの数をそろえるより、この四つが同じ記録に対して正しくつながるかを見ます。資料 CRUD

更新や削除では、書名だけで対象を選ばないようにします。同じ書名の本を二件登録し、片方だけを読了に変える。この試験が役立ちます。画面の並び順で対象を決めていると、検索や並べ替えの後に別の記録を変えるおそれがあります。表示される順番と、固定のidの役割を分けましょう。

入力の約束も毎回確かめます。空の書名は追加せず、120字を超えたら直す理由を伝えます。メモを空にする編集は許し、状態は決めた候補から選びます。アカウント付きの版では、画面がチェックした後も、受け取る側で同じ条件を確認します。APIへ直接送られても、同じ約束が守られるためです。

構造を変える前に、戻す道を確かめる

今あるデータを書き出し、練習環境で変更と復元を試します。コードの履歴、データベースの構造、保存した記録はそれぞれ確認します。

  1. 記録と構造を確認
  2. バックアップ
  3. 練習環境で変更
  4. 古い記録も確認
  5. 復元して照合
  • 項目追加は、項目のない古い記録でも試します。
  • データベースと別に保管した画像は、復元対象を別に確認します。
今あるデータを書き出し、練習環境で変更と復元を試します。コードの履歴、データベースの構造、保存した記録はそれぞれ確認します。

次に項目を増やすとき、古い記録が読めるかを考えます。たとえば読了日を追加しても、前の記録にはその項目がありません。未設定として表示するのか、入力を求めるのかを決めます。新しい項目を付けた一件だけを試していると、既存データが開けなくなったことに気づけません。

データベースの構造を変える手順は、マイグレーションとして記録できます。テーブルや列を作る、型を変えるなどの変更を順番付きのファイルに残し、各環境で同じ順に適用します。コードの履歴と、データベースに適用済みの履歴は別です。Gitを更新しただけで保存先の構造まで変わったとは判断しません。資料 DB_MIGRATE

変更前には、使われている記録を残せる方法を決めます。列を消す、型を狭める、全件を書き換える変更は、とくに扱いを考える必要があります。まず練習用の環境で、古い記録と新しい記録を混ぜて試します。コードを前の版へ戻しても、消したデータや適用した構造の変更が自動で戻るとは限りません。

バックアップは、何を、どの時点で残し、どう取り出せるかまでが一組です。localStorage版なら書き出したJSONを別に残し、別の練習環境で読み直します。取り込みでは一件の形を確かめ、追加するのか置き換えるのかを決めます。壊れたファイルを取り込んだとき、今ある記録まで消さないかも試します。

サービスのバックアップを使う場合も、対象を読みます。Supabaseのデータベースバックアップには、Storage APIで保管した実ファイルは含まれません。また、以前の時点へ戻すと、その後に入れた記録を失う場合があります。書影の画像を別に保存するなら、その保管と復元も別に計画します。資料 DB_BACKUP

復元できるかは、保存済みという表示だけでは分かりません。練習用の三件を書き出し、別の場所へ取り込み、件数、書名、メモ、状態、idを照合します。本番の記録を消して試す必要はありません。小さいデータで戻る経路を確認しておけば、項目を増やすときも、何を守ればよいか話し合えます。

読了日を足す前の依頼

既存の読書メモに読了日を足したいです。古い記録では未設定として扱います。
id、書名、メモ、状態、追加時刻を変えず、古い記録と新しい記録を混ぜて検証してください。
変更前の書き出しと、練習環境での復元方法を先に示してください。本番データは変更しません。

手を動かす順番

  • 一件のCRUDをidで追う
  • 入力条件と既存データへの影響を決める
  • 構造の変更を手順として残す
  • 別の練習環境で復元し内容を照合する

演習:同じ書名を二件登録し、一件だけ変える

一人用の版で、追加、再表示、更新、削除と書き出しを試します。アカウント付きのデータベース版は、必要になったときの拡張として設計を分けます。

  • 同じ書名でメモの違う二件を追加し、idが別であることを確かめる。
  • 検索や並べ替えの後に片方だけを読了へ変え、再読み込みして結果を照合する。
  • 三件を書き出し、別の練習環境へ取り込み、項目と件数を確認する。
  • 読了日のない古い記録と、日付のある新しい記録の表示方法を書く。
解答例を読む

書名の一致だけで同じ記録と判断しません。別のidを持てば、同じ題でも一件だけを扱えます。

操作の対象は固定のidで特定します。再読み込み後も、変更した一件だけが読了なら、表示と保存のつながりを確認できます。

書き出せただけで終えず、取り込んだ内容を照合します。不正な形式では今ある記録を保ち、失敗を伝えるようにします。

古い記録に日付がなくても読み込めるよう、未設定の表示を用意します。データベースを使う場合は構造変更の適用も別に確かめます。

この回で確かめること

  • 同じ書名でメモの違う二件を追加し、idが別であることを確かめる。
  • 検索や並べ替えの後に片方だけを読了へ変え、再読み込みして結果を照合する。
  • 三件を書き出し、別の練習環境へ取り込み、項目と件数を確認する。
  • 読了日のない古い記録と、日付のある新しい記録の表示方法を書く。

次の回:ログインの先で、権限を確かめる

参考資料

このレッスンは役に立ちましたか?