2021年9月4日

[js]JSONっぽいデータをJavaScriptで読みたい

JSONのデータはこんな感じだ。

{
  "name": "Yoshio",
  "age": 92
}

 

JSONっぽいデータと書いたが、今回はこういうデータのことである。

{
  name: "Yoshio",
  age: 92
}

「key: value」と呼ぶとしたら、keyの部分にダブルクォーテーションがないタイプのデータである。
JavaScriptのコード中に書くようなデータと言えばよいか。

 

何でか知らんが、サーバがこういうデータを返してくるようなのだ。
それをJavaScriptで読んで処理をしたい。


一応取り込めたのだが、この方法はあまりよろしくないとさんざん書かれている。

const VALUE = "{name: 'Yoshio', age: 92}";
const result = eval(`(${VALUE})`);
console.log(JSON.stringify(result));

$ node ev.js
{"name":"Yoshio","age":92}

 

よろしくない理由は eval() を使うと危険なためである。

置き換えの例としてFunctionを使うよう書かれていた。

const VALUE = "{name: 'Yoshio', age: 92}";
const result = Function(`return ${VALUE}`)();
console.log(JSON.stringify(result));

$ node ev.js
{"name":"Yoshio","age":92}

 

このシンプルなデータだとFunctionで置き換えられたのだが、複雑になるとそうもいかないようなのだが、どうしたらよいかわからん。。。

2021年7月4日

[js]import * は普通

前回、namespace にして export default して import させていた。
namespace は無しにして import * でも同じことはできるのだが、わざわざ namespace にしてみたのだ。

その理由は「ワイルドカードよりも特定の namespace を使った方がよいのではないか」という気持ちがあったからだ。ほら、不特定なものよりも特定した方が好まれるじゃないか。

しかし。。。

TypeScript: Documentation - Namespaces and Modules
https://www.typescriptlang.org/docs/handbook/namespaces-and-modules.html

太字で

we recommended modules over namespaces in modern code.

最新のコードでは、名前空間よりもモジュールを推奨しました。
(Google翻訳)

と書いてある。
「最新のコードでは」だから将来変わるのかもしれんが、2021/07/04 19:23 ではそうなっていた。

 

なので、ワイルドカードで指定しているとかそういうのはあんまあり考えなくて良いんだろうね。変に気を回して時間を掛けてしまったよ。

[js]ファイルを分けたい

大きいプログラムを作ると、ファイルを分けたくなるだろう。そうじゃなくても、機能ごとにファイルを分けたいだろうし。
まあ、私が分けたいのだ。


index.ts

01: import * as greet from './greet';
02: 
03: const hello: greet.Greet = greet.hello();
04: if (hello != null) {
05:     console.log(`hello: ${JSON.stringify(hello)}`);
06: }

greet/index.ts

01: export type Greet = {
02:     greet: string;
03:     time?: string;
04: };
05: 
06: export function hello(): Greet {
07:     return {greet: 'hello', time: 'allday'};
08: }
09: 
10: export default {}
  • greet ディレクトリにファイルがあるので、 import の from はそこを指定する。
    • ファイル名が index.ts なのでディレクトリの指定だけで済んでいる。
  • greet/index.ts は export default {} としたので、ファイルの中にある export 指定したものは同じ名前で export される。

という理解で正しいだろうか?

 

import の from より前の部分があまりわかってない。
こうか?

  • 個別に import するなら、 import {個別にコンマ区切り} from '~~'
  • 全部 import するなら、 import 名前 from '~~'

 

greet/index.ts から個別に importすると、こうなる。

01: import {Greet,hello} from './greet';
02: 
03: const msg: Greet = hello();
04: if (msg!= null) {
05:     console.log(`hello: ${JSON.stringify(msg)}`);
06: }

列挙するのが面倒ではあるが、使用しているものがはっきりするので場合によってはわかりやすい。


じゃあ全部 import するので import Hello from './greet' でよいかというと、これはダメそうだ。
Hello.Greet や Hello.hello という指定ができなかったのだ。
「Cannot find namespace 'Hello'」というエラーになる。

namespace を使う場合はこういう書き方になるようだ。
import するときに「import Hello from './greet'」としたが、別に namespace名と同じにする必要はなさそうだった。

あと、namespace も export を指定しないと個別に import できない(個別の話。export default指定しているなら関係ない)。namespace を export しても、namespace の中身が全部 export されたことになるわけではなく、その中でも export を付けたものだけが外部から見えるようだ。

index.ts

01: import Hello from './greet';
02: 
03: const msg: Hello.Greet = Hello.hello();
04: if (msg != null) {
05:     console.log(`hello: ${JSON.stringify(msg)}`);
06: }

greet/index.ts

01: namespace Hello {
02:     export type Greet = {
03:         greet: string;
04:         time?: string;
05:     };
06: 
07:     export function hello(): Greet {
08:         return {greet: 'hello', time: 'allday'};
09:     }
10: }
11: export default Hello;

 

この greet/index.ts を import * した場合は namespace 名を使わなくても済むようだ。

index.ts

01: import * as Pochi from './greet';
02: 
03: const msg: Pochi.default.Greet = Pochi.default.hello();
04: if (msg != null) {
05:     console.log(`hello: ${JSON.stringify(msg)}`);
06: }

 

 

namespace を付けるなら、 export default ではなく個別にした方がよいのかな?と思ったが、そうすると import側でも個別にしないといけなかった。
1ファイルで複数の namespace を入れ込むことは(私の実装だと)やらないので、これは default のままの方が使い勝手がよいか。

index.ts

01: import {Hello} from './greet';
02: 
03: const msg: Hello.Greet = Hello.hello();
04: if (msg != null) {
05:     console.log(`hello: ${JSON.stringify(msg)}`);
06: }

greet/index.ts

01: namespace Hello {
02:     export type Greet = {
03:         greet: string;
04:         time?: string;
05:     };
06: 
07:     export function hello(): Greet {
08:         return {greet: 'hello', time: 'allday'};
09:     }
10: }
11: export {Hello};

 


import の後ろは、 * as xx だったり name だったり {name} だったりといろいろあるが、いったいなんなんだ。

ECMAScript 2015 Language Specification – ECMA-262 6th Edition
https://262.ecma-international.org/6.0/#sec-imports

たくさんあるので from を使うパターンだけ見ていこう。
以下、イタリック&下線の部分はさらに展開されるという意味である。

import ImportClause FromClause;

FromClause の方は種類がないので、先にそちらを。

from StringLiteral

順番に展開すると ModuleSpecifier → StringLiteral なのだが、まあよかろう。
つまり文字列だ。

ImportClause は5種類に分かれる。

  • ImportedDefaultBinding
  • * as BindingIdentifier
  • { ImportsList }
  • ImportedDefaultBinding , * as BindingIdentifier
  • ImportedDefaultBinding , { ImportsList }

たぶん BindingIdentifier は「勝手に割り当てて良い名称」だと思う。bind だから紐付ける名称になるのかな。

上3つが import でよく見る形式で、残り2つはその組み合わせだ。
使えるものを展開してるのはこちら。

import - JavaScript | MDN
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/import

まあ、こっちの方がわかりやすいな。日本語だし。


これで基本的なところはできたんじゃなかろうか。

もう1つやりたいのが、export するファイルとそうじゃないファイルを分ける作業だ。
実装を見られて困るとかではなく、C言語で言うところのヘッダファイルとソースファイルに分けたいというだけである。

できるのだろうか?
なお、tsconfig.js は isolatedModules:true を指定しているものとする。

 

re-export というのでやってみた。

 

greet/index.d.ts

01: export type Greet = {
02:     greet: string;
03:     time?: string;
04: };

greet/hello.ts

01: import {Greet} from './index.d';
02: 
03: export function hello(): Greet {
04:     return {greet: 'hello', time: 'allday'};
05: }

 

greet/index.ts

01: export {hello} from './hello';
02: export type {Greet} from './index.d';

 

index.ts

01: import {hello,Greet} from './greet';
02: 
03: const msg: Greet = hello();
04: if (msg != null) {
05:     console.log(`hello: ${JSON.stringify(msg)}`);
06: }

うーん、無理やりやりましたという感じが拭えない。
それに呼び出し元の index.ts の方に修正が入るのはダメだ。

 

これは書き方としてダメだった。namespace 内ではダメだそうだ。

01: export namespace Hello {
02:     export {hello} from './hello';
03:     export type {Greet} from './index.d';
04: };
05: export default Hello;

 

これならいけるようだ。

01: import {hello as myHello} from './hello';
02: import {Greet as myGreet} from './index.d';
03: 
04: export namespace Hello {
05:     export const hello = myHello;
06:     export type Greet = myGreet;
07: };
08: export default Hello;

うーん・・・。もっとよいやり方がありそうな気がする。

 

というわけで、あきらめて本を買うことにした。

O'Reilly Japan - プログラミングTypeScript
https://www.oreilly.co.jp/books/9784873119045/

本の中身は書かないのだが、私が import あたりをうまく理解できない理由が分かってきた気がする。

「JavaScript」とか「TypeScript」とかで検索しながらやっていたけど、import というかモジュールの扱いについて過去の経緯がいろいろあり、ネットで見つけた情報はどの時点の JavaScript について書いているかによって変わってくるからだと思う。そういうのを知らずにネットで調べていたので、あっちの情報とこっちの情報をまぜこぜにしてうまくいかなかったとか、そんな感じになったんじゃなかろうか。

本の内容で勉強することの利点は、よくも悪くも情報が混ざらないことだと思うので、あやふやな知識でふらふら調べるよりはましなんじゃなかろうか。せっかくお金出したんだから、ましであってほしい。

2021年7月3日

[js]nullチェックとtruthy

JavaScript で null チェックする際、私はこう書くことが多い。

let val;

...

if (val) {
  // not null
  ...
} else {
  // null
  ...
}

C言語だと 0 以外の値なら真なのでアドレス値が入っているかどうかを判定するし、 Java だとそういう書き方は興られたような気がする。

で、JavaScript の場合はどういう仕様なのか?

 

Truthy - MDN Web Docs 用語集: ウェブ関連用語の定義 | MDN
https://developer.mozilla.org/ja/docs/Glossary/Truthy

falsy として定義された値以外は truthy 扱いで、 truthy は boolean 判定するところに出てきたら true として扱うという仕様だった。

falsy はこれら。

  • false
  • 0
  • -0
  • 0n
  • ''(空文字列)
  • null
  • undefined
  • NaN

オブジェクトの場合は null か undefined かそれ以外になるはずなので、 if (オブジェクトの変数) だけで事足りるはずだ。


あとは、その書き方が一般的なのかどうか、だ。
私は if (変数) や if (!変数) の書き方で見慣れているのだが、一般的にそうでないなら使いどころは絞った方がよいと思うのだ。

nullとundefined - TypeScript Deep Dive 日本語版
https://typescript-jp.gitbook.io/deep-dive/recap/null-undefined

うーん「== null」って書いてあるな。

確かに、 != null だと null か undefined だけだが、変数名だけだと幅が広すぎるのか。
x && x.length > 0 とか x && x !== 0 だったら変数名だけでよいかもしれないが、やっぱりちゃんと書いた方が無難だろう。

 

というわけで、 null / undefined のチェックにはきちんと == null のように条件を書くことにしよう。


ついでに読んでいてわからなかったのがこちら。

ルートレベル(root level)のundefinedのチェック
https://typescript-jp.gitbook.io/deep-dive/recap/null-undefined#rtoreberuroot-levelnoundefinednochekku

null だろうと undefined だろうと、 x.y を参照するのに x が どこも指していないのだったらダメだろう。

undefined かどうかをチェックするには確かに typeof するしかないのだが、 null は別によいってことなんだろうか。

うーん、わからん。。。

 

ごにょごにょ考えたが、あれは x.y != null みたいなチェックをいきなりするのではなく、先に x をチェックしろということを言いたいだけなんだろうか。
それならわかるけど、やっぱり x != null だけでよいと思うのだ。

Checking for root level undefined
https://basarat.gitbook.io/typescript/recap/null-undefined#checking-for-root-level-undefined

原文も同じ。

まあいいや。
ルートレベルより下のプロパティやメソッドにアクセスする前にはルートレベルのチェックをするか try-catch を考慮するようにしておけば良かろう。

TypeScriptとnull/undefinedチェック

JavaScript のことを書いているサイトであればほぼ書かれていると思われる null/undefined チェック問題。問題というよりは FAQ なんだろうけど、私は何度やっても覚えられない。


まず、 null と undefined の型だが、これはオブジェクトではなくプリミティブ型とのこと。昔ちょっと JavaScript を書いたときは 'undefined' と文字列になっていたような気がするが、そう書いてある()からそうなんだろう。

にもかかわらず、 typeof null は "object" だ。 typeof undefined は "undefined" である。
nullは「プリミティブ値」と表現されていたし、undefined も同様だ。

Primitive (プリミティブ) - MDN Web Docs 用語集: ウェブ関連用語の定義 | MDN
https://developer.mozilla.org/ja/docs/Glossary/Primitive

undefinedはプリミティブデータ型なので typeof で "undefined" になるが、 null は「プリミティブに見える」と微妙な表現をされている特殊なオブジェクトだそうな。あらゆるオブジェクトは nullから派生するらしい。

 

等値演算子(==, !=)を使う場合、null と undefined は同類と見なされる。

01: let val = null;
02: 
03: if (val) {
04:   console.log('defined');
05: } else {
06:   console.log('undefined');
07: }

これはどっちを通ったかというと、"undefined" の方を通った。 1行目が undefined でも同じだ。

null と undefined を区別したいなら同値演算子(===, !==)を使う。

A user name of null?
https://developer.mozilla.org/ja/docs/Learn/Getting_started_with_the_web/JavaScript_basics#a_user_name_of_null

この例は (!myName || myName === null) となっているのだが、 !myName だけでよいのでは?
もし && だったら myName === null だけでよいだろうし。

 

  • undefined はプリミティブデータ型でありプリミティブ値である
  • null はプリミティブ値のようでありオブジェクトのようであり、特殊な扱い
  • undefined と null を同じ扱いにして良いなら等値演算子(==, !=)で扱える
    • x == null とか x == undefined とか
    • !x でもよい
  • undefined かどうかを調べたいなら typeof === 'undefined' にする
    • null の typeof は 'object' になる

 

ちなみに、変数に undefined を与えて console.log したのが上、 'undefined' を与えて console.log したのが下。

image

null だとどっちで与えても白い文字で出力された。 うーん。

console.log なのか JavaScript 全体なのか分からないけど、人間寄りになるように動いてしまうのが苦手意識を持ってしまう原因かもしれん(私がね)。


TypeScript は型定義があるため、もうちょっと複雑になりそうだ。

nullとundefined - TypeScript Deep Dive 日本語版
https://typescript-jp.gitbook.io/deep-dive/recap/null-undefined

等値演算子で null チェックすればよいよ、ということだ。

といっても、ここは TypeScript の仕様説明ではないので、もうちょっと確認しよう。

 

まず、 null が型の方として扱われるようだ。

let val: number = null;

これはコンパイルエラーだ。どうしても代入したければ、私は null も OKですよ、ということにするしかないのか。

let val: number | null = null;

ちなみに、これもダメだ。

let val: number = null as number;

 

null は型扱いなので、変数を null型で指定できるようだ。

let val: null = null;
val = 'hello';

こんなのは代入する行でコンパイルエラーになる。 undefined もそうだった。

let val: undefined;
val = null;

使い道はないけどね。

 

だから、 null や undefined を代入したいのなら型のところで | null のような形にすることになる。
なるのだが、 undefined はデフォルト値になるので、ちょっと特殊な扱いかもしれない。その代わり、代入しないまま使おうとしたら、 | undefined になっていない限りはエラーになる。型と異なる変数が入っている、という扱いかもしれないが、TS2454 コンパイルエラーは before being assigned なので別エラーにはなっている。


C言語をよく使う人からすると、使い終わった変数に null を代入したいという気持ちに駆られることがある。

開いたファイルを扱うオブジェクトの変数があって、その変数が null だったら先にオープンしてから処理を続ける、みたいな。それをやろうとすると、最初は undefined だからよいとして、一度オープンして、クローズしたら null にしたくなる。しかし null を代入させるなら | null で許容させる必要がある。

私の期分の問題かもしれないが、 | null というか、型を複数割り当てるというのがどうも苦手だ。 string | number とかされたら「どっちが入ってんだよ!」ってなるからやらないけど、似たような気持ちになってしまう。

なら指定しなければ良いのだが、そうじゃなかったら boolean の変数を用意して判断するみたいなことになるだろう。でも、そこまでするのはなんか大げさな気がしてしまう。

なので、あまり選びたくない2択のどちらかをせねばならぬ。
あるいは、そういう設計の仕方自体が JavaScript らしくないということかもしれない。

 

そういう、言語仕様ではなく、センスというかお作法というかがよくわかっていないというのが最大の悩みであった。

[js]Arrayと配列と型付き配列 (2)

こんな話を2回に分ける必要もないのだが、日記だから良いのだ。

Arrayクラスと型付き配列は別物っぽいという話だ。

JavaScript 型付き配列 - JavaScript | MDN
https://developer.mozilla.org/ja/docs/Web/JavaScript/Typed_arrays

型付き配列というのは、いわゆる C言語などでの配列に近いもののようである。ただ、C言語では単に型のデータを配列にするのだが、型付き配列は「xxx型の配列のクラス」であり、その型ごとにクラスが用意されているところが異なる。

なので、定義されたクラス以外は(デフォルトでは)存在しない。

  • Int8Array
  • Uint8Array
  • Uint8ClampedArray
  • Int16Array
  • Uint16Array
  • Int32Array
  • Uint32Array
  • Float32Array
  • Float64Array
  • BigInt64Array
  • BitUint64Array

まあ、こんだけあれば十分だね。

どうやら、JavaScript では最初に Arrayクラスがあって、その後で型付き配列ができたようだ。データがメモリとして連続しているという前提がないと高速化できないというのはよくわかる。

つまり、Arrayクラスとは別物であるし、成り立ちからしても Arrayクラスの派生ではないだろう。 ArrayBufferクラスというものがあるようなので、むしろそちらが基底クラスになっているだろうか? しかし分類としては Array側になっていた。まあ配列だしね。

索引付きコレクション
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects#indexed_collections

なんかこう、Java のドキュメントのように継承関係の図はないんだろうか。

2021年7月2日

[js]Arrayと配列と型付き配列 (1)

JavaScript というか TypeScript というか Node.js というか、とにかくその辺で実装をしている。

慣れない・・・。
同じことをするのに書き方がいくつかあるというのが混乱する。

特にアローね。

function x(val: number): number {
  return val + 2;
}

const x = (val) => val + 2;

アロー演算子でしか書けない場合があるのは良いとして、どっちでもよい場合が困るのだ。
function とか return とか、そこまで省略したいの??

ということを訴えてみたのだが、そういう言語だからしょうがないよな。
人間、あきらめも肝心だ。


今日は JavaScript で他のコードを読んでいて、知らない関数が出てきたので調べてみると、Arrayクラスの関数だったということがあった。
クラスだからメソッドだろうけど、そういうことではなく、import しないと使えないやつではない標準で提供されているものくらいは把握しておかないとつらいかろうということに気付いたのだ。

 

Array - JavaScript | MDN
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array

最初に書かれている解説で気になった言葉を箇条書きにする。

  • Arrayクラス
  • グローバルオブジェクト
  • 配列の構築に使用される
  • 型付き配列

まず、Arrayクラスはいいだろう。
「Arrayクラスはグローバルオブジェクト」と書いてあるので、importしなくても使えるのだろう。これもよい。
配列の構築に使用される、ということは、static関数みたいなのを持っていて、それで作ってあげたりするのだろう。

で、型付き配列とは挙動が異なるように読み取ることができる。

JavaScript 型付き配列 - JavaScript | MDN
https://developer.mozilla.org/ja/docs/Web/JavaScript/Typed_arrays

混同してはいけません、という文章があるので、ここに答があるに違いない!

が、今日は眠たいのでここまで。

2021年6月20日

[js]PouchDB

前回の RxDB は、PouchDB のアダプタが使えますよ、といっていた。
今回はその Pouch DB だ。

PouchDB, the JavaScript Database that Syncs!
https://pouchdb.com/

簡単に使えるならなんでもいいんだけどね。


find() は別になっているのでインストールがいるのだった。

npm i pouchdb pouchdb-find

01: const PouchDB = require('pouchdb');
02: PouchDB.plugin(require('pouchdb-find'));
03: 
04: const db = new PouchDB('kittens');
05: 
06: const fn = async () => {
07:     db.bulkDocs([
08:         {
09:             name: "yoshida",
10:             color: "green",
11:             healthpoints: 30,
12:         },
13:         {
14:             name: "yoshio",
15:             color: "blown",
16:             healthpoints: 33,
17:         },
18:         {
19:             name: "momo",
20:             color: "pink",
21:             healthpoints: 9,
22:         },
23:     ]);
24: 
25:     await db.createIndex({
26:         index: {fields: ['healthpoints']}
27:     });
28:     const resHealth = await db.find({
29:         selector: {healthpoints: {$exists: true}},
30:         sort: ['healthpoints'],
31:     });
32:     for (let lp = 0; lp < resHealth.docs.length; lp++) {
33:         console.log(resHealth.docs[lp].name);
34:     }
35:     console.log();
36: 
37:     await db.createIndex({
38:         index: {fields: ['color']}
39:     });
40:     const resColor = await db.find({
41:         selector: {color: {$exists: true}},
42:         sort: ['color'],
43:     });
44:     for (let lp = 0; lp < resColor.docs.length; lp++) {
45:         console.log(resColor.docs[lp].name);
46:     }
47: 
48:     await db.destroy();
49: };
50: fn();

createIndex()が、fields を列挙したらその分作られるのかと思ったのだが、それぞれ作ることになるようだ。戻り値で"created" か "exists" が取ってこれるが、存在するなら作らないと書いてあるので、そんなに気にしなくてよいのか。

また、createIndex() した後に put() したら再度 createIndex() がいるのかと思ったが、そうでもないようだ。今のコレクションに対してインデックスを作るという意味ではないのか。

 

TypeScriptの場合はこんな書き方で良いのかな?
find() したドキュメントがうまいことプロパティにアクセスできなかったので as を使ってキャストしてしまった。よいのかどうかわからん。

01: import * as PouchDB from 'pouchdb';
02: 
03: PouchDB.plugin(require('pouchdb-find'));
04: 
05: const db = new PouchDB.default('kittens');
06: 
07: type dbType = {
08:     _id: string;
09:     _rev: string;
10:     name: string;
11:     color: string;
12:     healthpoints: number;
13: };
14: const fn = async () => {
15:     db.bulkDocs([
16:         {
17:             name: "yoshida",
18:             color: "green",
19:             healthpoints: 30,
20:         },
21:         {
22:             name: "yoshio",
23:             color: "blown",
24:             healthpoints: 33,
25:         },
26:         {
27:             name: "momo",
28:             color: "pink",
29:             healthpoints: 9,
30:         },
31:     ]);
32: 
33:     let idxRes = await db.createIndex({
34:         index: { fields: ['healthpoints'] }
35:     });
36:     const resHealth = await db.find({
37:         selector: { healthpoints: { $exists: true } },
38:         sort: ['healthpoints'],
39:     });
40:     for (let lp = 0; lp < resHealth.docs.length; lp++) {
41:         const r = resHealth.docs[lp] as dbType;
42:         console.log(r.name);
43:     }
44:     console.log();
45: 
46:     idxRes = await db.createIndex({
47:         index: { fields: ['color'] }
48:     });
49:     const resColor = await db.find({
50:         selector: { color: { $exists: true } },
51:         sort: ['color'],
52:     });
53:     for (let lp = 0; lp < resColor.docs.length; lp++) {
54:         const r = resColor.docs[lp] as dbType;
55:         console.log(r.name);
56:     }
57: 
58:     await db.destroy();
59: };
60: fn();

[js]RxDB

JavaScript でデータベースを使う必要性が出てきてしまった。
練習してみよう。


Introduction · RxDB - Documentation
https://rxdb.info/

NoSQLデータベースだそうな。SQLite か LMDB かでいえば、LMDB 側ということになろう。
私はそんなにデータベースを使ったことがないので、比較できるのはその2つくらいなのだ。

npm i でインストールすれば使えるのだろうと思ったが、RxDB 以外にもインストールしないと使えないらしい。
adapter というものもインストールして設定しないと使えないっぽい。
今回は Node.js なので、adapter のページにあった leveldown というものを使ってみよう。 Level DBらしい。

npm i rxdb rxjs leveldown pouchdb-adapter-leveldb

 

メニューの順番からすると、 RxDatabase, RxSchema, RxCollection, RxDocument, RxQuery の順にやっていくのだろう。

SQL ではないからか、テーブルではなくスキーマと呼ぶのか? そこはまだよいのだが、コレクションとかドキュメントとかあるのだが、何なのかが分からん。。。

開発者が知っておくべき、ドキュメント・データベースの基礎:特集:MongoDBで理解する「ドキュメント・データベース」の世界(前編)(1/3 ページ) - @IT
https://www.atmarkit.co.jp/ait/articles/1211/09/news056.html

ドキュメントはデータベースに突っ込むデータで、コレクションはその集合・・・?

  • createRxDatabase()でデータベースを作る
  • データベースに突っ込みたいデータの構造を決めて addCollections() で追加する
  • insert() でデータを突っ込む
  • find() でデータを取り出す
01: import {
02:   createRxDatabase,
03:   addRxPlugin,
04: } from 'rxdb';
05: 
06: addRxPlugin(require('pouchdb-adapter-leveldb'));
07: const leveldown = require('leveldown');
08: 
09: const fn = async () => {
10:   const db = await createRxDatabase({
11:     name: 'heroesdb',
12:     adapter: leveldown,
13:   });
14: 
15:   const myHeroSchema = {
16:     "title": "hero schema",
17:     "version": 0,
18:     "description": "describes a simple hero",
19:     "type": "object",
20:     "properties": {
21:       "name": {
22:         "type": "string",
23:         "primary": true
24:       },
25:       "color": {
26:         "type": "string"
27:       },
28:       "healthpoints": {
29:         "type": "number",
30:         "minimum": 0,
31:         "maximum": 100
32:       },
33:     },
34:     "required": ["color"],
35:     "attachments": {
36:       "encrypted": false
37:     },
38:     indexes: ['healthpoints', 'color']
39:   }
40:   await db.addCollections({
41:     heroes: {
42:       schema: myHeroSchema
43:     }
44:   });
45: 
46:   await db.heroes.bulkInsert([
47:     {
48:       name: "yoshida",
49:       color: "green",
50:       healthpoints: 30,
51:     },
52:     {
53:       name: "yoshio",
54:       color: "blown",
55:       healthpoints: 33,
56:     },
57:     {
58:       name: "momo",
59:       color: "pink",
60:       healthpoints: 9,
61:     },
62:   ]);
63: 
64:   const query = await db.heroes.find();
65:   const resHealth = await query.sort('healthpoints').exec();
66:   for (let lp = 0; lp < resHealth.length; lp++) {
67:     console.dir(resHealth[lp].get('name'));
68:   }
69:   console.log();
70:   const resColor = await query.sort('color').exec();
71:   for (let lp = 0; lp < resColor.length; lp++) {
72:     console.dir(resColor[lp].get('name'));
73:   }
74: 
75:   await query.remove();
76: }
77: fn();


難しすぎでは!?と思ったが、SQL を使うタイプだと SQL文というテキストになっているだけであんまり変わらんか。

addCollections() の戻り値はコレクションではあるのだが、コレクションの集合のようなものが返ってくるようだ。
これに find() したかったら、今回だと .heroes.find() のように名前を挟まないといかん。
そうなると db.heroes.find() と変わらん気がする。

 

それとは別に気になったのは、RxDB はその下で動いているデータベースを隠蔽するような形で動いていると思うのだが、トランザクションがあるデータベースだとパフォーマンスが悪くならないだろうか。 bulkInsert() で全部放り込めるなら良いけれども、取得しては保存、取得しては保存、みたいな使い方をしたい場合もあるだろうし。

2021年6月19日

[js]非同期とコールバックとPromise

JavaScript で検索するとたくさん出てくる「コールバック Promise」。
この記事もその1つになるのだろう。自分の考えを整理するのに、どうしても文章に書かざるを得ない人たちの一人なので仕方がない。
ちなみに、ブラウザでの動作は考えておらず、Node.js から使うものとして書いている。


JavaScript はシングルスレッドだと言われている。仕様ではここになるのかな?

8.6 Agents
https://262.ecma-international.org/11.0/#sec-agents

An agent comprises a set of ECMAScript execution contexts,
an execution context stack,
a running execution context,
an Agent Record,
and an executing thread.
Except for the executing thread, the constituents of an agent belong exclusively to that agent.

【DeepL翻訳】
エージェントは、ECMAScript の実行コンテキストのセット、実行コンテキストスタック、実行中の実行コンテキスト、エージェントレコード、および実行スレッドから構成されます。実行スレッドを除き、エージェントの構成要素はそのエージェントにのみ属します。

実行しているコンテキストではスタックとかスレッドとかで構成されるけど、全部 a や an が付いているので1つしかないということなんじゃなかろうか。
「single thread」という単語は見つけられなかったのだよ。

解釈は間違ったかもしれんが、とりあえずシングルスレッドであることは信用しよう。


シングルスレッドなのに非同期ってどういうことじゃ、と思ったが、ここは割込みができるシステムと考えればよいと思う。

 

組み込み開発ではよくあることだが、CPU は実行状態として「通常モード」と「特権モード」のようなモードというか状態というかを持つことがある。電源を入れて起動直後は特権モードで、その状態じゃないとできない設定をいろいろやってから通常モードになって動き始める、みたいな感じだ。

通常モードで動いているけれども、例えば外部のセンサからINPUTピンに対して信号が来た場合には割り込んで良いようにする、という設定にしておくと、信号が来たら現在の状態をスタックに保存してから特権モードに切り替わり、特権モードで処理をして終わったらまた通常モードに戻る、というようなことができる。

こういう特権モードになるときは CPUとしてまるまる切り替わるので、スレッドとかそういうのはない。そして特権モードでの動作は通常モードとは異なるのでコンテキストが異なる。すなわち非同期だ。

 

私の場合は JavaScript の非同期をそんな世界観で眺めている。


非同期なところまではよいのだが、非同期で処理を何かしたいことがほとんどだろう。 setTimeout() みたいな遅延動作なんかはわかりやすい例で、何か動作を遅延させてから実行したいのだ。

しかし、実行し始めたコンテキストとは別のコンテキストで動作するので、素直に続きを行うわけにはいかない。コンソールにログを出す、みたいな影響を与えないものであれば気にしなくてよいのだが、変数に値を代入したりファイルに書き込んだりしたいことが多かろう。

グローバル変数みたいにスコープが広い変数であれば代入できると思うが、ローカル変数に戻したいという場合もあろう。そういうときは実行したい単位を関数にしてしまい、Promise<戻り値>を戻すようにして、asyncを付けておくと、呼び出し元はその関数を await つけて呼び出せば

 

例えば、このコードをそのまま実行すると、setTimeout()したログは一番最後に出力される。

01: console.log('hello');
02: setTimeout(() => { console.log('meme'); }, 1000);
03: console.log('world');

hello
world
meme

 

setTimeout()の後にworldを出したいだけなら、こんな感じか。
ちなみに TypeScript で書いていて、 tsconfig.json の "target" は "es2015" にしている。 tsc --init で作られたそのままだと怒られてダメだったのだよね。
vscode で実行していたのでデバッグ設定をしていたのだが、"Launch Program" で実行しても console.log の出力がどこにも出てこなくて悩んだ。実行するとタブが "TERMINAL" になるので、急いで "DEBUG CONSOLE"にすると出てきた。

01: async function setTimeoutPromise(msec: number): Promise<void> {
02:     return new Promise<void>((resolve: any, reject: any) => {
03:         setTimeout(() => { resolve();}, msec);
04:     });
05: }
06: 
07: const fn = async () => {
08:     console.log('hello');
09:     await setTimeoutPromise(1000);
10:     console.log('world');
11: };
12: fn();

なんかめんどくさいね。
await を使いたいがために async の関数が2つ必要になってしまった。

 

それはともかく、setTimeout() の第1引数は関数を受け取るタイプで、指定した時間後にこの関数を呼んでくれる。つまりコールバックだ。
これを呼び出し元で同期に見せかけたいので、Promise を使ってコールバックで resolve() を呼び出すようにしている。

 

自分で作った関数だけで非同期が発生することはなくて、そこからsetTimeout() なり npm でインストールしたライブラリなり、なんらかの外部に依存する場合しか非同期になることはないだろう。そして JavaScript で提供された関数を呼ばないで済むことはまずないので(たぶん変数の参照や代入だけか?)、前提条件はあまり考えなくて良いだろう。

 

非同期の基本的な処理完了通知はコールバックのはず。ただ、組み込み CPUでの割り込み処理で特権モードになったままになるのではなく、Node.js のコンテキストに戻されるはずだから、pthread の join で待って、戻ってきたらコールバック関数を呼び出す、みたいなことをやっているのか。

Promiseはその先の話で、いろいろ書き方はあるのだろうが、

  1. Promise を new するときにコールバックで結果を返す関数を最後に呼び出す関数を登録する
    1. 登録する関数の引数は (resolve, reject) にするのが一般的。
    2. コールバックが呼ばれるときに resolve() を呼び出す(失敗だったら reject() を呼び出す)。
    3. コールバックで結果を得てそれを次も使いたい場合は resolve() の引数にする。
  2. promise.then() を呼び出して、引数は resolve() の中身を実装するようなイメージの関数にする。
01: function setTimeoutPromise(message: string, msec: number): Promise<string> {
02:     return new Promise<string>((resolve: any, reject: any) => {
03:         setTimeout(() => { resolve(message);}, msec);
04:     });
05: }
06: 
07: console.log('hello');
08: setTimeoutPromise('world', 1000).then((msg: string) => {
09:     console.log(msg);
10: });

setTimeoutPromise()の引数をコールバック関数内の resolve()に渡せているのが面白いところだ。全然コンテキストが異なるならアクセスできないはずなので、うまいことやってるのだろう。深く探る必要もあるまい。

そして setTimeoutPromise() に async をつけて、呼び出すときに await をつけると、resolve() の引数がそのまま戻り値として使えるようになる。つまり同期になる。

 

なので、もうあまり難しいことは覚えずに async - await だけ覚えておけばいいかな、と思っていたのだ。


しかし、パフォーマンスを出さないといけないようになると、全部同期で済ませるのはもったいないこともある。非同期になる理由が「忙しいから」であれば待っていても良いのだが、「待ち時間が発生するため」の場合には、その間に他のことをやってしまいたいからだ。

 

まず、Promise.all()というものがある。

Promise.all() - JavaScript | MDN
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Promise/all

Promiseのインスタンスを配列で受け取って、then でも配列で結果を返している。面白い。
これを async - await で書くとこんな感じか。

01: const promise1 = Promise.resolve(3);
02: const promise2 = 42;
03: const promise3 = new Promise((resolve, reject) => {
04:     setTimeout(resolve, 100, 'foo');
05: });
06: 
07: const fn = async () => {
08:     const result = await Promise.all([promise1, promise2, promise3]);
09:     console.log(result);
10: }
11: 
12: fn();
13: 

all()以外にもいろいろある。

順番にやっていかないといけないものは async - await でつなげれば良いし、特に順番はどうでもよいなら Promise.all() でまとめてしまえばよい。本当にどうでもよいならコールバック関数が呼ばれておしまい、でよいのだが、そうもいかんことが多かろう。

 

これでなんとかなるかと思っているのだが、どうなんだろうね。苦労してみないと分からんのだろう。