第二版のレビュー

[azu]

• 第二版のレビュアーを募集 #1546

第二版のレビュー用のDiscussionです。
Issue/PRにするべきか判断できないものなどを書いて大丈夫です。

[kakts]

早速読んでいて気になる点があり、issueにするべきか判断できなかったのでこちらに記載します。

Objectの静的メソッドについて

「Objectの静的メソッド」について記述がありますが、ES2022でObject.hasOwn() が追加されたことにより、オブジェクトの静的メソッドの段落より前に静的メソッドについての言及されており、こちらは流れ的に問題ないかが気になりました。

https://jsprimer.net/basic/object/#static-method
↑より前に 静的メソッド についての言及がある
https://jsprimer.net/basic/object/#confirm-property

https://github.com/asciidwango/js-primer/releases/tag/v4.0.0

[azu]

Object.hasOwn静的メソッド[ES2022]

の部分ですかね?

[azu]

https://jsprimer.net/basic/object/#object-hasown-method
あー、この部分ですね。

確かに、静的メソッドとは何かという話の前にある感じですね。
ちょっと悩ましいですね。静的メソッドとは何かという説明を前に入れると長くなりすぎるので、あまり深く説明せずに判定方法のグルーピングを優先しておいた感じはしますね。

[kakts]

すいません遅れました。　↑https://jsprimer.net/basic/object/#object-hasown-method　ここの部分であっております。

初見からしたら、静的メソッドの説明が先にあった方がよいかなとおもったのですが、事細かに説明すると、長くなってて本筋とは離れるきがするので、このままで良いかもしれません

静的メソッドとは何かという説明を前に入れると長くなりすぎるので、あまり深く説明せずに判定方法のグルーピングを優先しておいた感じはしますね。

[morinokami]

https://jsprimer.net/basic/variables/#const-is-not-constant を読んでいて気になった点について記載します。

ここでは const で宣言したオブジェクトに関して、「オブジェクトという値そのもの」あるいは「オブジェクトそのもの」は変更できると述べられています。ただ、JavaScript の純粋な初学者がここまでの文章を頭から読んだと仮定すると、オブジェクトという概念についてはまだ説明されていないため、「オブジェクトそのもの」というのが何を指しているかイメージしづらいのではないかと思いました。詳細は後述すると述べられてはいるものの、ふわっとした理解だけでも得られるように、簡単にオブジェクトが key-value ペアの集まりであることなどについて触れてもいいかも？と思いました。

[2nofa11]

TypeScriptの記載について、 付録: 参考リンク集内での取り扱いのみなのは、
やはり「JavaScriptを学べる書籍」という立ち位置だからでしょうか。

2023年の段階では、TypeScriptがデファクトスタンダードなっている印象を受けます。
（多少のバイアスがかかっていることをご了承ください。）

TypeScriptとJavaScriptとの関係性を付録：参考リンク集のトランスパイラーの一部だけにとどめておくのは、「TypeScriptに入門したけど、そもそもJavaScriptがわからないから入門したい」層にリーチするためには、別章にしてもいいかもしれないな、と感じました。

[azu]

https://github.com/asciidwango/js-primer/tree/master/meetings/2022-11-10#%E3%81%9D%E3%81%AE%E4%BB%96
で同じことを話しました。
TypeScriptを本文でやるには重すぎるし、中途半端になる気がします。
章を作るにしても中途半端で、良くあるDOMの章やjQueryの章やReactの章みたいなものになると思います。
そういう網羅性は本書の目的ではないので、省いているという感じですね。
(書いてもサンプルコードレベルで終わってしまうというのが、主な問題点です、ECMAScript Proposalに触れないのも同じ理由です。実際にどう使われる、どう使うまで行かない)

TypeScriptへの導線はあってもいいと思います。

AsyncとPromiseと同じようにAsyncの方が現実ではよく使われますが、Promiseを知らないでちゃんと使えるかというと、そうではない感じはします。ここの順番は逆転しないと思います。

TypeScriptがJavaScriptのsupersetなのを強く意識してるのもありますが、この書籍で推奨してるコードは大体TypeScriptでもそのまま書けるようなコードになってる感じはします。(全体的にJSらしいダイナミックな書き方はあんまり推奨してないはず)

なので、この本に含めるよりは、別のTypeScriptの本やThe TypeScript Handbookを同時に読む方がいいんじゃないかなーという気がします。これをうまくやる方法を紹介する方がいい結果になりそうに思えます。
(機能紹介を追加するなら、TypeScript前提で全体を書いた方が統一感が出て良いと思います)

TypeScriptは結局はJavaScriptの上に作ってるので(TSはRuntimeではないので)、CSSを知らずにTailwindができるかというとそうではないのと同じで、結局はJavaScriptを知らないとできません。
TSからJSを見るのか、JSからTSを見るのかは、どっちがいいかは個人次第なので、中途半端に足すよりは全体の流れとして書かないとあんまり意味がないかなーという感じがします。

[2nofa11]

ご回答ありがとうございます。

他のプログラミング言語と比較するのが目的ではない

確かに「目的ではない」ことの上記に当てはまりますね。

TypeScriptがJavaScriptのsupersetなのを強く意識してるのもありますが、この書籍で推奨してるコードは大体TypeScriptでもそのまま書けるようなコードになってる感じはします。(全体的にJSらしいダイナミックな書き方はあんまり推奨してないはず)

azuさんのご意見の通り、私も実務で使用するときはTypeScriptはTypeScriptの専門書を、JavaScriptを学ぶ時にはJavaScriptPrimerを使用していますね。
ユーザ側からしても、専門書として特化したほうが使いやすさはありますね。

TypeScriptへの導線はあってもいいと思います。

あくまで付録の1アイディアとして参考にしていただければと思います。

[azu]

この動線が難しくて、おすすめです。デファクトです。って書くのはあまり意味がなくて、この本のスタンスともなんか違う感じはします。(なんで利用するかの説明になっていないため。デファクトだから は説明にはなっていないため。)

エディターやIDEの中にはセミコロンの入力の補助をしてくれるものや、ESLintなどのLintツールを使うことで、 セミコロンが必要なのかをチェックできます。
セミコロンが必要か見分けるにはある程度慣れが必要ですが、ツールを使って静的にチェックできます。 そのため、ツールなどの支援を受けて経験的に慣れていくこともよい方法と言えます。
https://jsprimer.net/basic/statement-expression/

とかみたいに、アプリケーション開発時には型があると、典型的なミスが減るとか、そういう話とセットな気がします。

• Fast and precise type checking for JavaScript | the morning paper
• To type or not to type: quantifying detectable bugs in JavaScript | the morning paper

この辺の論文とかみたいに、なぜにあたる部分が大事かなーという感じがします。(今の付録は物理本にも入ってないほんとにおまけぐらいな感じのやつなので、ちゃんと入れようと思うなら、TODOの最後に入れるとかになるような感じします)

[2nofa11]

[ES2015] for...of文内にgeneratorへの言及についての記載が一部存在します。
こちらは意図的に生かしているのでしょうか。

iterableについてはgeneratorと密接な関係がありますが、ここでは反復処理時の動作が定義されたオブジェクトと認識していれば問題ありません。

ほかの章でgeneratorへの言及がない、かつ、過去のMTGで言及しないことも検討していることからご質問させていただきました。

[azu]

iterableについてはgeneratorと密接な関係がありますが、ここでは反復処理時の動作が定義されたオブジェクトと認識していれば問題ありません。

は

iterableは反復処理時の動作が定義されたオブジェクトの総称です。

とか Iterableを説明するだけでもいいのかもしれませんね。
(次の文と被ってるので、まとめた方が良さそうではあるけど)

---

多分最初はGeneratorも入れようとして書いてて、Generatorは結局出てこなかったので、こうなってる感じはします。

iterableはprototypeと同じように根幹にある要素なので紹介しないと進まないと思うのですが、
generatorは使わなくても済んでしまってるという感じで省かれているという感じですね。
ユースケースとして使う話が出てくれば、Generator Functionを紹介するものが基本の章に入ると思うのですが、
ユースケースとして出てくる場面がなくて省かれてしまってます。

実際にGeneratorを使わないと書けない場面が、スクレイピング中にページングしながらダウンロードするとか、パーサを書くときとか、ストリーミング処理を扱いたいときとか少し難しめというか、無限に続く処理(終わりが見えない処理)な気がするんですよね。
それ以外だと配列で書いた方がわかりやすいので、Generatorを使うユースケースが自然に登場してないというのが紹介してない理由ですね。(無限長のものと紙面というのが相性があんまり良くない感覚もあります。無限を仮に定義してしまうと有限になるのでそれ配列でいいのではとなってしまう)

[2nofa11]

背景について理解できました。
はじめて書籍のレビューに携わらせていただいていますが、ここまで深く対象読者の範囲やユースケースを考えているのですね。
JSPrimerの使いやすさやわかりやすさの理由が少しだけわかりました。

第二版でもGenerator Functionは追加しない、かつ、Generator Functionを使ったユースケースの登場機会は優先度が低いと判断したため、別途issueを起票させていただきました。
#1559

[nikukyugamer]

2023/02/02 時点での内容になりますが、 noeversion は 18.13.0 が、付属の npmversion は 8.19.3 が最新版かと思いますがいかがでしょうか。

https://github.com/nodejs/node/releases/tag/v18.13.0
nodejs/node#45322

js-primer/book.json

Lines 24 to 25 in 251c2e0

	"nodeversion": "18.12.0",
	"npmversion": "8.19.2",

厳密に追従しても際限がないとは思いますが、パッチバージョンの違いであることと、出版前提のレビューということで挙げさせていただきました。

[azu]

#1545 の更新待ちです

[nikukyugamer]

ありがとうございます。承知いたしました。

[azu]

• refactor: Update to Node.js 18.14.0 and npm 9.3.1 by azu · Pull Request #1567 · asciidwango/js-primer

でアップデートしました。

[kakts]

演算子 の章について

https://jsprimer.net/basic/operator/#bit-not
こちら感想レベルですが、下記2点気になりました。

1: ビット否定演算子の説明とindexOfの関連性について

下記の箇所で ビット否定演算子がビット演算以外でも使われることがあるという説明でindexOfの事例が取り上げられていますが、初心者の方だとindexOfがどうビット否定演算子を使っているのかを読み解くのが難しいように感じました。

~x のようにxをビット否定演算子で演算した結果は、-(x + 1)となります。 この性質を利用する形で、ビット否定演算子（~）はビット演算以外でも使われていることがあります。

という説明の後に、

文字列（Stringオブジェクト）が持つindexOfメソッドは、マッチする文字列を見つけて、そのインデックス（位置）を返すメソッドです。 このindexOfメソッドは、検索対象が見つからない場合には-1を返します。

の所になります。

指定した文字が文字列の中から見つからない場合は、内部でインデックスの値が0となり 、 ~0 = -1 と評価されるみたいな説明が追記されると理解の助けになると感じました

2: 否定演算子のところで書かれている 1の補数について

否定演算子（~）は1の補数を返すため、~(-1)は0となります。

ビット演算子で2の補数表現についての説明がありましたが、1の補数表現について詳細でなくとも軽く説明があると良いと感じました。

[kakts]

indexOfのところは内部実装見ていなかったのですが、後ほど調べて見ます

[kakts]

2: 否定演算子のところで書かれている 1の補数について

こちらの1の補数に関しては、本筋から外れると思うので必須でなく、
あくまで追加で補足あれば初学者に助かるなと思った次第です。

[haruguchi-yuma]

値の評価と表示について

https://qiita.com/masakura/items/5683e8e3e655bfda6756
少し気になりがあったので書いておきます。

デバッグという用語の説明順序(箇所)について

「Console API」の項で以下のようにデバッグという用語が使われ、

Console APIは原始的なプリントデバッグとして利用できます。 「この値は何だろう」と思ったらコンソールに表示すると解決する問題は多いです。

このプリントデバッグという用語には特に説明がないのですが、少し読み進めて、
「コードと評価のエラー」の項の実行時エラーの箇所で以下のようにデバッグという用語の説明がなされています。

このようなエラーの原因を特定し、修正する作業のことをデバッグと呼びます。

厳密にはプリントデバッグとデバッグで区別されていると思われるのですが、

1. プリントデバッグの時点で少し補足を入れる
2. プリントデバッグという用語を使わず、平易な言葉で置き換える

あたりを検討しても良いのかなと思いました。

[azu]

どちらかという後者かなという気がしますね。

「この値は何だろう」と思ったらコンソールに表示すると解決する問題は多いです。

だけでいいかなという感じもします。

「この値は何だろう」と思ったらコンソールに表示すると解決する問題は多いです。
コンソールに表示された値が想定と異なるなら、書いたコードに何かしら問題があることがわかります。

次の文に加えるなら理由ですが、あんまりしっくりは来てないかも

[haruguchi-yuma]

「この値は何だろう」と思ったらコンソールに表示すると解決する問題は多いです。
コンソールに表示された値が想定と異なるなら、書いたコードに何かしら問題があることがわかります。

個人的に特に違和感は感じていませんが、デバッグが主題というわけでもないのでさらっと流すというのも判断の一つかなと思い始めました。

[morinokami]

https://jsprimer.net/basic/function-declaration/#rest-parameters の Rest parameters の記述について思ったことを以下に書きます。

まず、Rest parameters に対応する引数が与えられなかった場合の説明を追加するといいのではないかと思いました。たとえば、

function fn(arg1, ...restArgs) {
    console.log(arg1); // => "a"
    console.log(restArgs); // => ["b", "c"]
}
fn("a", "b", "c");

というプログラムの例が書かれていますが、ここで fn("a") とした場合に restArgs がどうなるか（空配列 [] となる）について、一言触れるとよいのではないかと思いました（そこまでの記述から、「undefined となるのでは」と考える読者もいるかもしれないため）。

また、Rest parameters を複数定義できない（たとえば function fn(...a, ...b) { /* */ } とはできない）ことについても触れられていないため、この点についてもどこかに追記するとよいのではないかと思いました。

[azu]

Rest parameters に対応する引数が与えられなかった場合の説明を追加

こちらはあっても良いかもしれないですね。

JavaScriptでは定義した仮引数をよりも少ない引数で関数を呼び出すことができます。
呼び出し時の引数が少ない場合、通常の仮引数には`undefiend`が入りますが、Rest Parametersは必ず配列となるため、空の配列が入ります。

```js
function fn(arg1, ...restArgs) {
    console.log(arg1); // => undefined
    console.log(restArgs); // => []
}
fn();
```

また、Rest parameters を複数定義できない（たとえば function fn(...a, ...b) { /* */ } とはできない）ことについても触れられていないため、この点についてもどこかに追記するとよいのではないかと思いました。

これは文としてはここですかね。この間違い方はあんまりみたことがないのでinvalidなcodeを紹介するのは冗長な気はします。
どちらかというと末尾ということを印象に残すような書き方にした方がいいかなという気がします。

Rest parametersは、通常の仮引数と組み合わせても定義できます。 ほかの仮引数と組み合わせる際には、必ずRest parametersを末尾の仮引数として定義する必要があります。

[morinokami]

ありがとうございます！前者に関しては、書いていただいた説明でバッチリと思います。（これに関して Issue を立てたりは不要ですかね？）

また、後者について

これは文としてはここですかね。この間違い方はあんまりみたことがないのでinvalidなcodeを紹介するのは冗長な気はします。
どちらかというと末尾ということを印象に残すような書き方にした方がいいかなという気がします。

確かに、間違え方としてはあまり多くないかもしれませんね。また、必ず末尾に置くということが書かれていれば、複数定義した時点で末尾に置かれていないものがありダメだということがわかる、ということも納得です。これについては書かなくてもよい気がしてきました。

[azu]

Issue作ってしまって問題ないです。

[staticWagomU]

https://jsprimer.net/basic/
の説明について気になった点です。

配列の説明についてですが、

また配列における破壊的なメソッドと非破壊的メソッドの違いについても紹介します。

にて、破壊的なメソッドという書き方をされているので、非破壊的なメソッドという書き方のほうが統一感が出て良いのではと思いましたが、如何でしょうか。

---

次に、関数とスコープの説明についてですが、

ブロックスコープや関数スコープなどがどのような働きをしているのかや複数のスコープが重なったときにどのように変数の参照先が決まるのかを紹介します。

にて、かやの部分に少し違和感を感じたので、

ブロックスコープや関数スコープなどがどのような働きをしているのか、また複数のスコープが重なったときにどのように変数の参照先が決まるのかを紹介します。

または、

ブロックスコープや関数スコープなどの動作原理や、複数のスコープが重なったときにどのように変数の参照先が決まるのかを紹介します。

という書き方は如何でしょうか。

[azu]

そのままPull Request作って問題ないですよ。

ブロックスコープや関数スコープなどがどのような働きをしているのか、また複数のスコープが重なったときにどのように変数の参照先が決まるのかを紹介します。

の方がいいですかね。

[staticWagomU]

承知いたしました。
Pull Request作成いたします。

[morinokami]

typo なのか判断しかねたためこちらで質問します。

「文と式」の中の https://jsprimer.net/basic/statement-expression/#function-statement-and-function-expression において、節のタイトルが「function宣言（文）とfunction式」となっています。このこと自体は問題ないのですが、この節の中では一度も「function宣言（文）」や「function式」という言葉は登場せず、代わりに「関数宣言（文）」や「関数式」という言葉が使われています。他の節ではこのようなタイトルと説明文での用語の使い分けはされていないようなため、統一性の観点から、どちらかというと文章中で使われている「関数宣言（文）と関数式」のようにタイトルを変更してもいいのではないかと思ったのですが、いかがでしょうか？（問題なければ PR を作成します）

[azu]

関数宣言（文）と関数

に統一でよさそうですね。
英語表記はカッコ書き(補足的表記)なので、セクションタイトルは漢字に統一していいと思います。
https://jsprimer.net/basic/statement-expression/#statement-and-expression

[morinokami]

ありがとうございます、こちら https://github.com/asciidwango/js-primer/pull/1578/files にて PR を作成しました。

[morinokami]

「プロトタイプオブジェクト」の章 https://jsprimer.net/basic/prototype-object/ 冒頭に

「オブジェクト」の章では、オブジェクトの処理方法について見てきました。 その中で、空のオブジェクトであってもtoStringメソッドなどを呼び出せていました。

const obj = {};
console.log(obj.toString()); // "[object Object]"

という記述がありますが、実際には「オブジェクト」の章で空のオブジェクトに対して toString メソッドを呼び出している例は存在しないようです。よって、上に引用した箇所の記述は何らかのかたちで更新する必要があると思いましたので、ここで報告しておきます。

[azu]

あ、でもtoStringの呼び出しありましたね。
https://jsprimer.net/basic/object/#toString-method

"空のオブジェクト" は
"toStringを定義していないオブジェクト" ぐらいの意味合いなので、

- 「オブジェクト」の章では、オブジェクトの処理方法について見てきました。 その中で、空のオブジェクトであってもtoStringメソッドなどを呼び出せていました。
+ 「オブジェクト」の章では、オブジェクトの処理方法について見てきました。 その中で、`toString`メソッドを定義していないオブジェクトでも`toString`メソッドを呼び出せていました。

とかなのかな。少し冗長なので、もう少し短くは書けそう

「オブジェクト」の章では、オブジェクトの処理方法について見てきました。 その中で、メソッドを定義していないオブジェクトでもtoStringメソッドを呼び出せていました。

「オブジェクト」の章では、オブジェクトの処理方法について見てきました。 その中で、オブジェクト内には書かれていないtoStringメソッドを呼び出せていました。

「オブジェクト」の章では、オブジェクトの処理方法について見てきました。 その中で、オブジェクトのtoStringメソッドを呼び出していました。

[2nofa11]

配列部分のMapに関して、改めて読み返しました。
配列に関して明快かつ体系的に理解ができて好きな章です。

2点、気になったことあったため私の意見になりますが、記載させていただきます。

1. 「まとめ」に記載の以下内容ですが、2項目目以降が章後半の説明になっています。
   書籍としたときに、『まとめ→各段落の内容』の順に確認する人も一定数いるため、まとめに前半の内容（例：配列から指定した要素を検索するビルドインオブジェクトが存在する）を一部含めてもいいかもしれません。

この章では配列について学びました。

• 配列は順序を持った要素を格納できるオブジェクトの一種
• 配列には破壊的なメソッドと非破壊的なメソッドがある
• 配列には反復処理を行う高階関数となるメソッドがある
• メソッドチェーンは配列のメソッドが配列を返すことを利用している

2. 「[ES2019] 配列をフラット化」について、flatMapの説明は意図的に省いている認識です。
   （Array.prototype.flat と Array.prototype.flatMap  #847 を確認しました。）
   こちらの方針は、2版でも共通でしょうか？
   2019年からしばらくたち、実務でもflatMapを使用する機会が増えたため、追加するかの再考をしてもいいのかもしれないなと思いました。

以上2点、かなり主観が入っていますが、ご一考していただければ幸いです。

[azu]

メソッドを乱雑に説明してるという感じなので、

配列は順序を持った要素を格納できるオブジェクトの一種

を

配列は順序を持った要素を格納できるオブジェクトの一種でさまざまなメソッドを持つ

とするぐらいなのかもしれません。(あんまり詳細書いても共通点がないなーという感じがしました)

flatMapはやはり応用的な側面があって、そもそもmapが便利だと思ってないと、flatMapの便利さがわからない感じがするんですよね。flatMapならではのわかりやすいユースケースが必要な感じがしますね(filterでできなくて、reduceでやるとものすごい複雑なような。TypeScriptだとfilterの型が微妙なのでflatMapというパターンもありますが)

js-primer/meetings/2019-07-01/README.md

Line 94 in 9a9bea4

## ES2019

あとは、ES2023で配列に非破壊的なメソッドが入るので、おそらく配列の章は書き直しになると思います。
その時に再検討になる気がします。

• Change Array by Copy to stage 4, per 2023.01.30 TC39 · tc39/proposals@ad4df84
  • tc39/proposal-change-array-by-copy: Provides additional methods on Array.prototype and TypedArray.prototype to enable changes on the array by returning a new copy of it with the change.

[KeisukeKudo]

@azu

第一部 ｢暗黙的な型変換｣ の ｢NaNはNot a NumberだけどNumber型｣ の解説に Number.isNaN() メソッドが出てきますが､グローバルオブジェクトの isNaN() メソッドに言及していない理由ってありますか?
｢JavaScriptのすべての文法や機能を網羅するのが目的ではない｣ というのは理解していますが､型について解説する章ということもありますし､ ｢同じ名前の関数があるが､挙動が異なるため注意が必要｣ 程度の注釈と isNaN() メソッドの MDN リンク はあってもいいのかなと思いました｡
以前にそういった議論がされていて､結論が出ているのであればスルーしていただいて構いません｡

[azu]

https://efcl.info/2016/09/06/nan/ では触れていたので、本文でも書いた気になってたのかもしれません。

js-primer/source/basic/function-scope/README.md

Line 291 in ea42edb

1つ目はECMAScript仕様が定義する`undefined`のような変数（「[undefinedはリテラルではない][]」を参照）や`isNaN`のような関数、`Array`や`RegExp`などのコンストラクタ関数です。2つ目は実行環境（ブラウザやNode.jsなど）が定義するオブジェクトで`document`や`module`などがあります。

でisNaNの存在に触れているので、1行ぐらいの注意書きで増えても良い気はしますね。

[KeisukeKudo]

ブログ記事の方で触れていたんですね｡
失礼しました｡
こちら PR 出したいと思うのですが問題ないでしょうか?

PR を出すとして､文章は以下のようなものを考えています

注記: isNaN()というグローバル関数もありますが、こちらは引数を暗黙的にNumber型へ変換してからNaNかどうかを判定します。意図しない挙動を引き起こすため使わないようにしましょう。

また､差し込み位置ですが､
ブログ記事と同じならここ (L397)ですが

js-primer/source/basic/implicit-coercion/README.md

Lines 395 to 398 in ea42edb

	Number.isNaN(NaN); // => true
	```
	`NaN`は暗黙的な型変換の中でももっとも避けたい値となります。

JavaScript Primer と少し構成が異なるので､以下の位置 (L392)が自然ではないかと思うのですがいかがでしょうか?

js-primer/source/basic/implicit-coercion/README.md

Lines 390 to 393 in ea42edb

	同様の処理をする方法として`Number.isNaN(x)`メソッドがあります。
	実際に値が`NaN`かを判定する際には、`Number.isNaN(x)`メソッドを利用するとよいでしょう。
	{{book.console}}

[azu]

この流れだとisNaN関数が示している場所がわからなくなる感じがしますね。

NaNしか持っていない特殊な性質として、自分自身と一致しないというものがあります。
この特徴を利用することで、ある値が`NaN`であるかを判定できます。

{{book.console}}
```js
function isNotaNumber(x) {
    // NaNは自分自身と一致しない
    return x !== x;
}
console.log(isNotaNumber(1)); // => false
console.log(isNotaNumber("str")); // => false
console.log(isNotaNumber({})); // => false
console.log(isNotaNumber([])); // => false
console.log(isNotaNumber(NaN)); // => true
```

同様の処理をする方法として`Number.isNaN(x)`メソッドがあります。
実際に値が`NaN`かを判定する際には、`Number.isNaN(x)`メソッドを利用するとよいでしょう。
また、`isNaN`関数というよく似たグローバル関数もあります。しかし、`isNaN`関数は値が`NaN`かを正しく判定できない場合があります。
そのため、`NaN`の判定には`Number.isNaN(x)`メソッドを利用することを推奨します。

{{book.console}}
```js
Number.isNaN(NaN); // => true
```

となる気はしますが、グローバル関数とは何かという話がない気がするので、置きにくい気がしますね。

脚注でもいい気がしてきましたが(本文ではコードとして紹介してないので参考程度の扱い)、 #1547 (reply in thread) の方が困るかも。
isNaNを #1547 (reply in thread) から消すだけでもいいが…(グローバル関数として使って良いものってコンストラクタぐらいしかほぼないので、グローバル関数の存在がほぼ触れないようにしている感じもする)

[KeisukeKudo]

確かにそうですね……
ただ､ビルトインオブジェクトの説明としては妥当だと思うので､個人的には残していいんじゃないかと思っています｡

脚注にて

isNaN関数というよく似た関数もあります。

のように､ ｢グローバル関数｣ という言葉を使わないのはどうでしょうか
説明として間違いではないですし､ Number.isNaN 以外に isNaN という同名のメソッドがあるが､利用は推奨されない､というのは十分伝わる気がします｡

[azu]

それで良いかもですね。

Issue作りました
#1602

[haruguchi-yuma]

文と式の文の項でvarを使ったサンプルコードがあるのですが、何か意図があるのでしょうか？

var forIsNotExpression = if (true) { /* ifは文であるため式にはなれない */ }

代入演算子の右辺で例外が発生するので、何かまずいというわけでもないのですが、JS Primer では varよりもlet やconst を使うというスタンスだと解釈しているため const で良いのではないか？と思った次第です。

[azu]

特に理由はないですね

• 変数名に使える名前のルール: varではなくletに変更する #1388 (comment)

の名残なのではないかなと思います

[haruguchi-yuma]

特段の理由がないとのことなのでconstを使った例に修正してもよろしいでしょうか？

[azu]

変更していいと思います。

[haruguchi-yuma]

どこまで網羅的に記述するのかという話にはなってくるのですが、
「関数と宣言」の[ES2015] デフォルト引数の項で

デフォルト引数を使って書くことで、このような挙動は起きなくなるため安全です。 デフォルト引数では、引数が渡されなかった場合のみデフォルト値が入ります。

function addPrefix(text, prefix = "デフォルト:") {
    return prefix + text;
}
// falsyな値を渡してもデフォルト値は代入されない
console.log(addPrefix("文字列")); // => "デフォルト:文字列"
console.log(addPrefix("文字列", "")); // => "文字列"
console.log(addPrefix("文字列", "カスタム:")); // => "カスタム:文字列"

とありますが、デフォルト引数に明示的にundefinedを渡したときはデフォルト値が代入されると思いますが、記述は不要でしょうか？

引数を渡さない = undefinedを渡すと捉えると問題はなさそうですが念の為に記載しておきます:bow:

[azu]

undefinedの例を追加するだけでは、結果だけ書かれていて中途半端な感じがしました。
メンタルモデル的に、引数にundefinedを値として渡したか、引数が指定されてないからundefinedになったかを区別が難しいので、そこだけを変に説明しても中途半端な感じがします。(argumentsを使わないとできないので、Arrow Functionではできない)

実際に undefined を値として書いて明示的に渡すユースケースは、引数の順番が重要な関数で、optionalな引数の後ろに指定しないと行けない引数があるケースとか少し特殊なんですよね。

// これは書けない
const fn = (a?:string, b: boolean) => {
    console.log(a,b);
}
// のでこうした場合に　fn(undefined, true);
const fn = (a: string|undefined, b: boolean) => {
    console.log(a,b);
}

Document.evaluate()とかそういうのは昔ありましたが、今だと引数をオブジェクトにしてしまうので、このケースはかなり少ない気がします(エラーコールバックとかも似た話がある)

どちらかというと、暗黙的にundefinedを渡して、それによってデフォルト値が採用されるという流れを説明するのがいいのかなーという感じもします。今の説明だと、次のようなケースでinnerFlagのデフォルト値を採用するにはどうすればいいかというのが説明できない。nullではダメなの?とか。

const innerFn = (innerFlag = false) => {
  console.log(innerFlag); // デフォルトはfalse
}
const fn = (options) => {
  const innerFlag = options?.innerFlag; // オプションがない場合はinnerFnのデフォルト値を尊重したい
  innerFn(innerFlag);
}
fn();

仕様の歴史とかを見ても undefined がデフォルト値をトリガーするのは、オプションのデフォルト値の決定権を別の関数に移譲するために入った変更に見えます。なので、「undefinedを渡した場合にデフォルト値が採用されます」だけだと中途半端に感じました。(リファレンス的なので本書の目的ではないこと)
「関数のデフォルト値を実行する関数に任せたい場合はundefinedを渡します。そうすることで関数のデフォルト値が採用されます」のような話がセットで必要かなという感じがしました。

• 11. Parameter handling
  • tc39-notes/july-24.md at master · rwaldron/tc39-notes · GitHub

ただ、それをやると今の関数と宣言 · JavaScript Primer #jsprimerにネストした関数がないので説明のための説明っぽくてちょっと応用な扱いですね。なのでundefinedを明示的に渡すケースだけ書くのはちょっと微妙だと感じています。

関連してちょっと気になったのは、undefinedはfalsyなので、デフォルト引数では、引数が渡されなかった場合のみデフォルト値が入ります。という記述は微妙にこの例外になってしまっていて、そこを直したい感じはします。

この両方を綺麗に解決できる方法があれば、入れるのが良い気がします。

• undefinedを渡すとデフォルト値がトリガーできる委譲の使い方
• デフォルト引数では、引数が渡されなかった場合のみデフォルト値が入ります。の記述の問題
  • こっちは別問題として直しても良い気がする
  • undefinedは例外としてって書くと微妙かもしれない。言いたいことは || はデフォルト値にはつかにくいという話だけなので

[haruguchi-yuma]

仕様の歴史とかを見ても undefined がデフォルト値をトリガーするのは、オプションのデフォルト値の決定権を別の関数に移譲するために入った変更に見えます。なので、「undefinedを渡した場合にデフォルト値が採用されます」だけだと中途半端に感じました。(リファレンス的なので本書の目的ではないこと)

なるほどです。理解しました。確かに明示的にundefinedを渡したときの説明のために移譲を持ち出すのは、この時点で過剰ですし、単純に使用の説明になるとリファレンスになってしまうというのは納得です。

• undefinedを渡すとデフォルト値がトリガーできる委譲の使い方
• デフォルト引数では、引数が渡されなかった場合のみデフォルト値が入ります。の記述の問題

後者に関しては「のみ」だけ削除してしまうというのはどうでしょうか？
デフォルト引数では、引数が渡されなかった場合にデフォルト値が入ります
となります。

[azu]

👍 良さそうですね。

デフォルト引数では、引数が渡されなかった場合にデフォルト値が入ります。

のみは確かに不要そうですね

Issueにしました

• 関数と宣言: "デフォルト引数では、引数が渡されなかった場合のみデフォルト値が入ります" から "のみ" を外す #1605

[nikukyugamer]

私自身が不慣れなことに基づくご提案なのですが、付録のチートシート に falsy な値の一覧があると嬉しいなと思いました。

一度覚えてしまえば不要なのだと思いますが…。

[kakts]

0除算の結果について

こちらも演算子について気になった点を書きます

除算する際、 Javascriptにおいては0で除算すると 0除算エラーでなく、無限大を表す Infinity として評価されます。
他の言語では0除算時にエラーとなることがありますが、Javascript初学者向けにこのあたりの説明を軽くでもあると良いなと思いました。
除算のところに一部説明追記しても良いでしょうか。
https://jsprimer.net/basic/operator/#division-operator

Infinityについての記述

上記の0除算の結果とからむところですが、Infinityについては下記の項目で軽く記述がありますが、詳細な説明は不要でしょうか。
https://jsprimer.net/basic/array/#flat

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Infinity

[azu]

確かにあって良さそうですね。
0除算でInfinityに触れるのは良い気がします。
詳細をやるならMathのようなNumberの章ですが、そこまでではないので、ゼロ除算に触れる形でInfinityを出すのは自然な気がします。

• Number.POSITIVE_INFINITY - JavaScript | MDN

Issueを作って進めて良いと思います

メモ

• IEEEの範疇ではないことは一応確認する
• Nagative Infinityが自然に出るケースがあるかを考える(多分あんまり自然にはない)

[kakts]

承知しました! INIFINITYに関してissue起こして対応いたします

[kakts]

詳細をやるならMathのようなNumberの章ですが、そこまでではないので、ゼロ除算に触れる形でInfinityを出すのは自然な気がします。

今回は0除算のところでInifinityについて言及する形で進めようと思います

[kakts]

#1616 issue追加しました

[morinokami]

「非同期処理」の章の https://jsprimer.net/basic/async/#promise-then-and-catch の冒頭パラグラフに

thenメソッドのエイリアスでもあるcatchメソッド

という表現が出てくるのですが、この「エイリアス」という表現が適切なのかという疑問を少しもちました。

「エイリアス」というと、同じ実体を指す別名という感じのニュアンスの語だと思うのですが、そのような前提でこの箇所を読むと

• then と catch は機能的に等価

のように誤読される可能性を孕んでいると思います。よって、エイリアスという語を別の語に置き換えたほうがいいのではないかと思ったのですが、いかがでしょうか？

[morinokami]

あー、でも、シェルの alias のニュアンスみたいなイメージであれば、それほどおかしくはない気もしてきました（あらかじめ then の引数の一部を埋めておいてたものを指している、という感じで）。

[azu]

エイリアスの概念を知らない人もいるとは思うので、エイリアスじゃない言い方があればそれでもいいですね。

catchは、内部的にはthenを使ってるので、
https://tc39.es/ecma262/#sec-promise.prototype.catch
包含とか内部的にthenを呼ぶとだとちょっと長いので、ちょうどいいものがあると良いのですが。
部分適応とかbindとかではありますが。

[KeisukeKudo]

thenメソッドのエイリアスでもあるcatchメソッド

この時点では誤読の可能性はありますが､ Promiseと例外まで読み進めれば then と catch は機能的に等価ではないとわかるのではないでしょうか｡
また､実際に内部的に then が呼ばれているのであれば､厳密ではないですが､ ｢エイリアス｣ で間違いはないと思います｡
ちなみに MDN には Promise.prototype.then(undefined, onRejected) の省略形 と書かれていますね｡

個人的には現行のほうが好みですが､読者的には then と catch の文法と､どういう用途で使われるのかを理解できればいいと思うので､ ｢エイリアス｣ 自体を削除して

Promiseのようにコンストラクタに関数を渡すパターンは今までなかったので、thenメソッドとcatchメソッドの使い方について具体的な例を紹介します。

のような記載でも十分ではないかと思います｡

[morinokami]

上と同様「非同期処理」の章の https://jsprimer.net/basic/async/#top-level-await-in-module を読んでいて感じた些細な点について質問なのですが、ここでは Module や Script という語がダブルクオーテーションに囲まれて何度も "Module" などと表現されていますが、これには意図があるのでしょうか？自分が読んでいた限りでは、" を外してそのまま Module などと書いてしまっていいのではないかと思いました。また、https://jsprimer.net/basic/introduction/#script-module でも同様の書き方がされており、同様に外してしまってもいいのではないかと思いました。

[azu]

https://jsprimer.net/basic/introduction/#script-module がものすごい初期に書かれてたと思うので、その名残りな気はします。
https://tc39.es/ecma262/#sec-execution-contexts
実行コンテキスト自体は仕様にあるのですが、"Module"はModule Recordsのことを指して書いていた気はします。
ただここでModule Recordsとか言っても謎になるので(Recordsがちょっとふわっとしてる)、独特な言葉だということを示すためにQuoteで囲んでいたんだと思います。

Module だけにすると、実行コンテキストじゃなくてECMAScript Moduleのことになってしまわないか(ES ModuleはModule Recordsなので実質は同じですが。Scriptはちょっと実装環境でズレがある用語かな。NodeはデフォルトがScript Records相当)はちょっと気になるポイントですかね。

外しても問題はない気はしますが、置き換えできる言葉があると用語がconflictしなくなるのでいいですね。

[morinokami]

ありがとうございます。正確性を重んじてそうした区別がされていたとのことで、勉強になりました。

確認した感じでは、https://jsprimer.net/basic/introduction/#script-module では、"Script" や "Module" などと書かれるときは必ず「"Script"の実行コンテキスト」のように「実行コンテキスト」という語が添えられていました。この場合は、実行コンテキストであることが常に明示されているため、そのままクオートを外してしまってもよさそうに見えます。

一方、https://jsprimer.net/basic/async/#top-level-await-in-module では、ほとんどは「"Script"として実行」や「"Module"として実行」のように書かれており、実行コンテキストであることが読み取れるためこちらも外してよさそうな気がします。最後の一文

しかし、ES2022ではTop-Level awaitが利用できるようになったため、"Module"においてはこのような即時実行関数は不要となります。

についてのみ「"Module"においては」となっていますが、ここは「の実行コンテキスト」などを補ってあげればよいのかなと思いました。

ただ、このスレッドを書いたときには気付かなかったのですが、おそらく ECMAScript Module の意味でクオートなしの Module という書き方も https://jsprimer.net/basic/async/#top-level-await-in-module では使われており、"Module" などから単純にクオートを外すと両者が同じ見た目になり都合が悪そうです。どうしようか悩んだのですが、https://jsprimer.net/basic/module/ を確認したところ、どうやら ECMAScript Module の意味での Module はこの章ではカタカナの「モジュール」に統一されているようでした。よって、https://jsprimer.net/basic/async/#top-level-await-in-module では

• "Module": 「"Module"として実行」のように書かれてるものについてはクオートを外す、最後の一文についてのみ「の実行コンテキスト」を補ってクオートを外す
• Module: ECMAScript Module の意味であるため「モジュール」へと変更する

のようにするのが落とし所かなと思いましたが、いかがでしょうか。

---

ごちゃごちゃしてしまいましたのでまとめますと、

• https://jsprimer.net/basic/introduction/#script-module
  • " をそのまま外す
• https://jsprimer.net/basic/async/#top-level-await-in-module
  • "Module" については、「"Module"として実行」のように書かれてるものについてはクオートを外す、最後の一文のについてのみ「の実行コンテキスト」を補ってクオートを外す
  • Module については https://jsprimer.net/basic/module/ に合わせ「モジュール」とする

これによるメリットとしては

• "Module" と Module という微妙な表記の違いを読者が意識しないでよくなる
• 表記ゆれの解消（「Module」と「モジュール」）

あたりかと思います。

[kobakazu0429]

[ES2015] ECMAScriptモジュール

https://jsprimer.net/basic/module/

JavaScriptにおいては、1つのモジュールは1つのJavaScriptファイルに対応します。

こちら受け取り方によっては1ファイル中に1つのみしかエクスポートできないように感じてしまったのですがいかがでしょうか？

---

また「名前つきエクスポート／インポート」について、どちらが良いということはないと思いますが、その旨を一行書いてあると別言語から来た方にとっては良いかなと思いました。

両方蛇足的ではあるかもしれません

[kobakazu0429]

非同期処理:Promise/Async Function

https://jsprimer.net/basic/async/#sync-processing

拙い図で申し訳ないのですが、下記のようにタスクBと非同期タスクの間に隙間があると良いかなと思いました。
ここではタスクA,Bは同期タスクですがconsoleに出力するのみで体感では一瞬です。
つまり登録→B実行→少し待つ→非同期タスク実行となるはずです。

[haruguchi-yuma]

オブジェクトの[ES2020] Optional chaining演算子（?.）

Optional chaining演算子（?.）は左辺のオペランドがnullish（nullまたはundefined）の場合は、それ以上評価せずにundefinedを返します。一方で、...

という説明があるのでundefinedやnullを?.で繋げているところは?.は1つのチェーンの方がそれ以上評価せずという説明がわかりやすくなると思うのですがどうでしょうか？

<変更前の引用>

// undefinedやnullはnullishなので、`undefined`を返す
console.log(undefined?.notFound?.notFound); // => undefined
console.log(null?.notFound?.notFound); // => undefined

<提案>

// ↓ 各文最後の?.を.のチェーンに変更しています
console.log(undefined?.notFound.notFound); // => undefined 
console.log(null?.notFound.notFound); // => undefined

[haruguchi-yuma]

配列の[ES2019] 配列をフラット化で

また、Arrayのflatメソッドは必ず新しい配列を作成して返すメソッドです。 そのため、これ以上フラット化できない配列をフラット化しても、同じ要素を持つ新しい配列を返します。

という説明がありサンプルコードが以下のようになっています。

const array = ["A", "B", "C"];
console.log(array.flat()); // => ["A", "B", "C"]

このサンプルコードの場合、新しい配列を返している様子が分かりにくいので以下のようなコードサンプルにするのはどうでしょうか

<提案>

const array = ["A", "B", "C"];
const newArray = array.flat()); // => ["A", "B", "C"]
console.log(array === newArray); // => false

[yumetodo]

横からですが
https://jsprimer.net/use-case/setup-local-env/#open-js-primer-local-server

@js-primer/local-serverってメンテされているんでしたっけ、していないのだとすると #433 では不採用にした http-server とかを使うことを再考してもいいのかもしれません。

[azu]

基本的にはCLIのインターフェースを変えないため(文面を変えないため)に別途作ってるので、一応してます。
インストール時にWarningとか出たり、Node.js側で挙動が変わったりしたら対応する感じです。

パッケージのアップデートとかはしてもいいかもですね。(ESMが必要になるけど、改訂でNode 14.x以降にはなるので)

• 対象の環境をNode.js 14.13.1 || >=16.0.0 にする js-primer/local-server#13

[azu]

jsprimerの書籍の方も校了し、あとは発売日(2023/6/9)を待つだけになりました。
改めてレビューありがとうございました！

https://github.com/js-primer/review/discussions/1
レビューアー向けの連絡事項をこちらのDiscussionに記載しています。
レビューアーの方はこちらを確認していただけると助かります。