azu
リリースノートに入れるものはラベルをつけていくとかのほうが管理しやすいかもと思った。 PRに結構意識して変更点書いてるので
リリースノート - page - issue - pr を書いていく感じ。 大体リリースするの、major udpateのみなきがするので、逐次PRでCHANGELOG書いたほうがいいのかな
コミットログ自体はやっぱりいらない感じがする
- Major updateはCHANGELOGを書く - ちょっとしたアップデートはコミットログでやる のがいいのかな
> a. `typeof` 演算子で関数を評価すると `function` が返ることについて文中で補足する 関数も ここの流れに入れるのが自然な感じがしますね。 関数もオブジェクトですが、特別扱いされるので、プリミティブとオブジェクト(関数とその他)という感じで > データ型を細かく見ていくと、7つのプリミティブ型とオブジェクトからなります。
厳密にはそうだと思いますが、`-0` 自体を説明してないので、入れるのが適当かは微妙な気がしますね。 (厳密には区別されますが) `0` が + と - を包含してるとも読めます。 Falsyという用語自体がECMAScriptの仕様にあるわけではなく、あくまでよく言われる程度の言葉なので厳密な定義がない状態です。 `-0` を区別して網羅するべきユースケースがあるなら、一覧として明示するべきだと思います。 ただ、この書籍で`-0`を区別して紹介してるところがないので、ここで `-0` をいきなり出すと混乱しないかなという懸念があります。 Related: - https://exploringjs.com/impatient-js/ch_booleans.html#falsiness-truthiness `0` のみ - https://learning.oreilly.com/library/view/javascript-the-definitive/9781491952016/ch03.html#conversionsandequality `-0` を挙げている
`7種類` という言葉が限定してるように見えるので、次の値は〜 ぐらいで具体例としてリストアップする書き方もありそうですね。 または - `0` (`+0` と `-0`) 📝 ここでリストアップしてる主な理由は、trueとなる値を覚えるのが難しいので、falseとなる値だけを覚えれば逆はtrueになるということを知るという点にあります。なので、直感的に理解するためのリストという側面が強いので、少ない方がノイズが減って直感的になりやすい。厳密にリストアップするように直すよりは、直感的に理解するためのリストという方向で直した方が良さそうだとは思っています。
``` 次の値は、暗黙的な型変換をすると `false` となることが仕様で決まっています。 ... これらの値のことをfalsyな値と呼びます。 ```
falsyは仕様的な定義があるわけではないのに、 仕様的な定義っぽく書かれていたので、もう少し通称的な意味として読めるように変更。 `-0`と`+0`については、特に言及しないままの形にしました。 https://github.com/asciidwango/js-primer/pull/1482
これES Modulesの章も、実際に動く感じに書き直せるかも