前: JavaScript中級者になろう 13章を読んだ (通信) - t_hazawaの日記
経緯
- JS力をつけていっている
十四章第一回 Storage
https://uhyohyo.net/javascript/14_1.html
cookieとの違いは、「データがサーバーへ送られるか送られないか」です storageはサーバー側からは参照できません。javascriptからのみです 基本的にはこちらのほうが便利
一つはlocalStorageであり、もうひとつはsessionStorageです
- window.localStorage, window.sessionStorage
localStorageは同じオリジンなら、違うページからでも同じ内容を共有できる
- sessionStorageはタブごとにことなる 2021/12/09 0:05
基本は、storageのプロパティに値を入れるとそれがそのまま保存されます。実は、保存できる値は文字列に限ります。オブジェクトとかを保存したい場合はjsonにしましょう
localStorage.foo="bar"; localStorage.setItem("foo","bar");
- getItem もあるが普通にプロパティ参照でいける
- removeItem
- clear そのStorageのデータが全て消える
- length
var key=localStorage.key(0); //0番目のキーを取得
window.addEventListener("storage",function(e){ },false);
- Storageに変更があったら window に storage イベントが発生するらしい
- ev.key ev.oldValue ev.newValue ev.url ev.storageArea
- 大体は自分で変更したものだろうどイベントがくるんだなあ(?) ←これは違うらしい
- 共有しているStorage (localStorage)で変更があると、他のタブでイベントがくるらしい
clearメソッドの場合は、key,oldvalue,newvalueが全てnullになっています。
- コンソールで localStorage.clear() してもイベントは飛ばないようだ
- Storageは expireしないのね (便利)
- sessionStorage は、一度タブを閉じると1からになってしまいますね
- sessionStorageには、一時的なデータを入れるといいね (session認証情報ではないね)
十四章第二回 Indexed Database
https://uhyohyo.net/javascript/14_2.html
- IndexedDBだけで4回ある (使わなさそうだけど、使わなさそうなのはこれだけなのでまぁ全部読んでいいか)
通称IndexedDBは、前回のStorageが進化したようなもの ある種のデータベースをjavascriptから作ってブラウザに保存しておいてもらえる
オブジェクト等を保存できる点や検索機能がある
ひとつひとつのデータはレコード(record)といい、レコードはkeyとvalueを持つ
データベースはオブジェクトストアを保持して、レコードはオブジェクトストアの中に保存される レコードはオブジェクトストアの中に保存されていて、1つ以上のオブジェクトストアをまとめたものがデータベース
- ?
- データベースのなかにオブジェクトストア(MySQLのテーブルみたいなもの?)があるらしい
IDBRequestというオブジェクト IndexedDBに対して何か操作を行った時の結果を表すオブジェクト
- このオブジェクトでsuccess イベントや error イベントが発生する 結果はresultプロパティに入ってる
- この下位は 8800文字ある 前回は 4900字
- IDBRequestのreadyStateプロパティ でも終わったかわかるぞ "pending" "done"
- error, source, transaction プロパティもあるぞ
- window.indexedDB でアクセス
- windowのプロパティはグローバル変数でアクセスかのうなので indexedDB でもいける
- open() がまずいる
openはデータベースを開くメソッドですが、そのデータベースが存在しない場合は作ってくれます。つまり、とにかくデータベースを使いたければopenということです。
- 気軽なJS
引数で指定したバージョンが開こうとしたデータベースより低い場合(すなわち、保存されているデータベースのバージョンが高いのにそれより低いバージョンのデータベースを要求した場合)、このアプリは新しいデータベースに対応していなくて誤動作を起こす可能性があるということなので、エラーを起こしデータベースは開けません。
- openのバージョン番号を上げればバージョンが上がる
- バージョン番号は省略可能(うひょさん非推奨)
無事データベースを開けた場合は、IDBOpenDBRequestのresultプロパティには、IDBDatabaseのインスタンスであるオブジェクトが入っています これを用いていよいよデータベースの中身をいじることができます
var request = indexedDB.open("test",1); //testというデータベースをバージョン1で開く。openの返り値はIDBOpenDBRequest
- データベースが処理中で待つ時は blocked イベントが発生する
データベースの名前は一度作ったら変えられない
- close すると多分親切 しなくてもいいのかも?
基本的に一つのアプリケーションなら一つのデータベースで完結するのがよいのではないでしょうか。
createObjectStoreの返り値は、IDBObjectStoreというオブジェクト
- あと39回でおわり (全部で121回 2/3終わってるね)
versionchangeトランザクション 実はcreateObjectStoreはversionchangeトランザクション中しか使えないメソッドなので、必然的にこれを使うことになります。
- バージョン変わるときにしかオブジェクトストアは作成できないのだ
versionchangeトランザクションが発動した場合、openの返り値であるIDBOpenDBRequestにおいて、upgradeneededイベントが発生します
- このイベントの中で createObjectStore とかするらしい
db.createObjectStore("foo", { keyPath:"hoge", autoIncrement:true });
- keyについては次回
十四章第三回 Indexed Database 2
https://uhyohyo.net/javascript/14_3.html
- オブジェクトストアごとにキージェネレーターを設定できる auto increment
- 配列、文字列、dateオブジェクト、数値(0以下の数や小数も含む) をキーに使える
keyというのは順番に並べることができなければいけません。これは並び替えやインデクシングなどの機能を提供するためです。
異なる種類の値については、大きい方から、配列、文字列、date、数値の順になっています 文字列は文字コード順、Dateは日付順、数値は大きさ順
2つの配列の、0番目、1番目、・・・どうしの要素を比較して、どちらかが大きければ、そちらの配列が大きくなります 長いほうが大きくなります。長さまで同じ場合は配列が完全に同じなので、同じ
- key の種類が混在しててもOKらしい (フランクなJS)
keypathにはkeyのプロパティ名を文字列で指定します 省略すると out-of-line key になる(目に見えないどこか)
- 自動で key になったりしないのね
- userid も key にできて便利なのだ
- "foo.bar"がkeyPath だと、 foo オブジェクトの中の bar がキー 。 柔軟
キージェネレータを使うことのメリットは、一意な連番を勝手にレコードに割り振ってくれることです
- 結構使われるらしい
データベースを操作するにはまずトランザクション(transaction)を作ります read でも必要 IDBDatabaseのtransactionメソッド 返り値としてIDBTransactionオブジェクト これがトランザクションを操作するオブジェクト
- トランザクションをつくるときにオブジェクトストアを指定しないといけないので、joinとかはなさそう
- トランザクションを "readonly" にしてデータを守ろう というか、複数同時にデータを読めるぞ
- "readwrite"だと順番待ちになる
第2引数が省略された場合はreadonly
配列を用いて複数のオブジェクトストア名を同時に指定することが可能です。この場合ひとつのトランザクションで複数のオブジェクトストアを同時に扱えます
- joinありそう
- abort()で強制的にtransaction失敗
- IDBObjectStore というオブジェクトを取得してデータを読み書きしよう IDBTransactionのobjectStoreメソッド
versionchangeトランザクションはreadwriteトランザクションの上位互換で、データベースへの読み書きが行えるほか、オブジェクトストアを作ったり消したりすることまでできます(
データベースに入れることができるものの幅はけっこう広いです。 さらにdateオブジェクトや正規表現オブジェクト、fileやblob、filelist(十二章第五回)やimagedata(これはまだ解説していませんが、canvasを扱うときに出てきます)もokです
以上のものを要素としてもつ配列やオブジェクトもokです
入れることができないのは、関数や、nodeのようなdom関係のオブジェクトです。。。また、オブジェクトについたゲッタやセッタや、enumerableなどのプロパティの属性はコピーされず、デフォルトの状態になる
in-line keyの場合には、keyはオブジェクトのプロパティとなります。つまりプリミティブなどはプロパティを持てないのでレコードとしては不適で、エラーになります。
- 配列はin-line key だとだめよ オブジェクトじゃないから
逆にout-of-line keyの場合には、レコードそのものはkey情報を持たないので、レコードにこれ以上の制限はありません。
- オブジェクトには代入してもかえられないプロパティがあるよ
- add, putでれこーど追加
第1引数が追加するレコード、第二引数がそのレコードにつけるkeyです。。。ただし、第2引数のkeyというのは、out-of-line keyのときしか使えません ii
- キージェネレーターがアッテョ inline-key のときはkeyをレコードにするオブジェクトからしョう略デキる
- addは重複エラー、putは上書き
keyとして正の数値を指定した場合で、かつその値がキージェネレータから発生する次の数値以上の場合、キージェネレータの数値が「その値より大きい最小の整数」に変更されます。
- 便利
オブジェクトストアに対するひとつひとつの操作をリクエストと呼び、その結果を知らせてくれるのがidbrequestです。
- requestへの結果だけど request
- IDBRequest.result だからよさそう .error とかあるし
idbrequestではイベントが発生する可能性があります。成功したときはsuccessイベント、失敗したときはerrorイベント
successイベントは次の処理に進むためによく使いますし、errorイベントは、前述のように、中途半端に失敗したらトランザクションを中断して無効にするというときに、失敗の検出をするために使えます
addやputの場合には、idbrequestのresultは追加されたレコードのkey
- あれもこれも request と名前つけるのはわかりにくそう。。
ちなみに、データベースの中身は、Chromeの場合だとDeveloper toolsのApplicationsから見ることが可能です。試しに見てみましょう。
- あまり使われてるシーンに遭遇しないから実感がない感じ。。
十四章第四回 Indexed Database 3
https://uhyohyo.net/javascript/14_4.html
- .get() なかったら undefined
- .delete() resultは特にありません
- .clear() オブジェクトストアのレコードを全部消す
- Key Range でまとめて取得や削除ができるぞ
key rangeは2つの端点によって定義されます。範囲の中で最小の点と最大の点ですね。 key rangeは、IDBKeyRangeというオブジェクトで表されるのですが、作り方がほんの少し特殊
var range=IDBKeyRange.bound(3, 5, true, true); 開いてればtrue 閉じてれば false つまり 3< x < 5
範囲の上限を指定しないkey rangeを作るには、lowerBoundメソッド upperBound only
さて、そうして得られたidbkeyrangeには、lower,upper,loweropen,upperopenという4つのプロパティがあります
このようにして作ったidbkeyrangeは、keyのかわりにgetやdeleteの引数として使えます。ただし、getにidbkeyrangeを渡しても、レコードが複数得られるわけではありません。当てはまる最初の一つのレコードのみ帰ってきます。一方deleteの場合は、当てはまるレコードを全部消去してくれます。
- count にこのkey range を渡すとレコード数がかえってくる
- .getAll とか .gets() みたいなのはなさそう
そこで登場するのがカーソル(cursor)です
- "next" とか "prev" とか動く順番を指定できる
"nextunique"。nextと同じですが、重複するkeyをもつレコードは最初のものだけ見ます。。"prevunique"
- key は重複できたんだ?
これは次回の話に関わってきますので、今は深く考える必要はありません。惑わされず、keyは重複しないということは覚えておいてください。
- 奥深い Indexed DB でも、だいたいサーバにデータを保存するからあまり使われてなさそう
- まぁ、使わなさ層のは、この講座でこのindexed db が最後だからまぁいいかな(?)
openCursorの返り値も、例のごとくIDBRequestです。resultプロパティの値として、カーソルを示すIDBCursorWithValueオブジェクト カーソルが現在いる位置のレコードの内容を示す、keyとvalueというプロパティを持ちます
advance(susumu_kazu) 戻れない
- IDBRequst の success に通知がくるのこと
- 最後はresult が null になるとのこよ
- countinue(key_name) そこまですすむ
- getAll がほしそう
updateです。これは、現在の位置のレコードを書き換えるというメソッド key はかえられない deleteもある
- とても手順が大変な indexeddb
十四章第五回 Indexed Database 4
https://uhyohyo.net/javascript/14_5.html
12600文字
- id, name, age がある場合
そのときには、このオブジェクトストアに対して、新たにageをkeypathとするインデックスを作ってそれを使えばいいのです 実はインデックスは自身のkeypathを持ちます インデックスは基本的に、レコードがオブジェクトでないと効果を発揮しません
- 複数のインデックスを晴れるのね
- versionchange トランザクションでしか新インデックスはれないよ
IDBObjectStoreのメソッドであるcreateIndex uniqueとmultiEntry
multiEntryがtrueになると、検索時の配列の挙動が変わります。配列の要素のうち、どれか一つでも条件を満たせば当てはまるようになるのです
- deleteIndex
- IDBIndexのgetとかでレコードを取得してね
実はインデックスのkeyPathには、文字列の他に、複数のkeyPathを並べた配列も許可されています
もしインデックスのkeyPathが次のような配列だったとします。
- ["party","age"]
- このとき、このインデックスにおけるさっきのレコードのkeyは次の配列になります。
- ["自民党",72]
さらに、範囲指定の例も紹介しておきます。今回の場合、政党名を1つに絞ったうえで年齢の範囲を指定することができます。
範囲指定では使いにくいかもしれませんが、並び替えのためなら配列のkeypathも使い道があるかもしれません。
終了してすることが何も無くなった状態を、イベントループに戻ったなどといいます。この状態になって、なおかつもう処理すべきリクエストが残っていないときが、トランザクションが終了したときです。
複数のカーソルを同時に動かしたりした場合など、どちらが先に終わるのかわからないので面倒です。その場合はcompleteイベントが役に立ちます。。
検索条件として範囲指定しかできませんし、複数の条件を同時に指定するのは難しいです
実際には、スケールにもよりますが、とりあえずkey rangeで一次的に絞り込んで、その後は検索結果に対してif文などで絞り込んでいくことも
- 操作がめんどそうだった
感想
- localStorage は使いそうだった
- IndexedIndexはとても煩雑そうで使いにくそうだった
時間まとめ
- 2021/12/9-14
- 10 + 44 + 30 + 30 + 32 + 14(ブログ) = 160分
- 累計: 1601分 (= 26.7時間)