基本文法 #17

事前にリテラル #27 で少し触れる

• 正規表現オブジェクト
• 正規表現リテラル
• コメントとの被る http://www.ecma-international.org/ecma-262/6.0/#sec-literals-regular-expression-literals
  • /(:?)/

スクリーンショットの撮影方法と、サイズ・形式について

実行環境との一貫性を考えてFirefoxで撮影したい
サイズ固定はレスポンシブモードでよさそう？スクリーンショット機能もある。
形式はpngで問題ない？オンラインで見られるならjpgにしておくほうが親切か？

懸念点：

• ブラウザ以外のスクリーンショットはどうするか
  • ターミナル
  • 開発者コンソールを含めたブラウザ全体

連絡用のIssueを立てておきます。

さて、３月になったのでまたミーティングを行いたいと思います。
皆さんのご予定はいかがでしょうか？

基礎文法 #17
#27 型/リテラルの続き -> #32 演算子 -> 型変換

異なるデータ型の変換をするにはどうやるのかを学ぶ。
また暗黙的な型変換はなぜ避けるべきなのか、明示的な変換のやり方について書く。
明示的な型変換には演算子を使ったハック的な方法があるが、そうではないやり方の方がいいこと、またなぜそういう傾向があるのか(早いとか)についてを簡単に書く。

• 異なるデータ型を演算
• 暗黙的な型変換
• 明示的な型変換
• 型変換で何でも解決するな
• コラム: 推測するな、計測せよ

参考

• You-Dont-Know-JS/ch4.md at master · getify/You-Dont-Know-JS

アウトライン

• 目的
  • 暗黙的な型変換を避けるべき理由を知る
  • 代わりの方法として明示的な型変換の方法を知る
    • 暗黙的な型変換を利用するにはまずは、それを知ってから考えよう
• なぜ暗黙的な変換を避けるのか
  • 型のエラーが暗黙的な変換によって隠されてしまう
    • +演算子による意図しない文字列 [Object Object]
    • + - で結果が異なる
      • toStringなのかvalueOfなのかが異なる
      • 2 - "1" !== 0 + "1"
  • これによりバグを見つける事が難しくなる
    • コンソールに警告もでない
  • 動いてるけどどこかおかしいという状況が生まれるため
• 暗黙的な変換とはどのようなものか
  • 型が異なる場合に、その型へ強制的に変換されてしまうこと
    • 具体的には
      • 演算子
      • isNaN
      • 真偽性
    • がある
    • 演算子については覚えて避けるのが難しい = 組み合わせ問題であるため
    • 真偽性については覚えたほうが簡単に書ける
• 暗黙的な変換とは次のようなものこと
  • +"string" という + 演算子がアルゴリズムステップの過程で ToNumberをするという副作用を期待しての変換
  • 演算子でオペランドを処理する過程で、オペランドがコンテキストにおいて自動で変換されること
  • オペランドがどの型へと変換されるかは演算子ではなく、対象のオペランドによって異なる変換のこと
• 暗黙的な型変換の例
  • 1 == "1"
  • 1 + "1"
  • 1 + true
  • 1 - undefined
• 明示的な型変換の例
  • 文字列 => 数字
  • 数字 => 文字列
  • Symbol => 文字列
  • Any => Number
    • Date -> Number
    • Any -> NaN
    • 明示的に変換すればいいというわけではない
  • Any => 真偽値
    • 真偽性(truthiness)と呼ばれる by Effective JavaScript
    • https://github.com/getify/You-Dont-Know-JS/blob/master/types%20&%20grammar/ch4.md#implicitly-----boolean
• 型変換では解決しないこと
  • 何でも明示的な型変換をすることで解決するわけではない
  • NaN
  • オブジェクト
    • toString()
    • valueOf ? これはいる?
• シナリオ
  • 暗黙的な変換による意図しない挙動
  • 予測できない挙動が多く含まれる
  • そのため暗黙的な変換は避けたほうが良い。
  • 特に == については問題ある挙動が多すぎる
• 余白
  • [型変換] || は 0 がfalsyであることに気をつける必要がある
  • [型変換] 比較演算子の==はほぼ使わない
  • [型変換] 例外は == null のみ
  • [型変換] 基本的には === のみを使う方が安全
  • [型変換] JavaScriptには暗黙的な型変換があるため
  • [型変換] ! は評価した値を反転ので、暗黙的な型変換が行われる
  • [型変換] 演算子はなんだかんだと勝手に型変換が行われる
  • [型変換] 同じ型以外を安易に比較してはいけない
  • [型変換] どうやって同じ型だけに限定するかというのも考える必要がある
  • [比較] プリミティブに落として比較するよりオブジェクトかどうかの真偽値を取る方法[比較] Array.isArray、Object.isなど、Object.shallowEqualなど
  • [[class]]とtoStringの問題
  • [型変換] 型変換は明示的に行う
  • [型変換] 暗黙的な型変換を避ける
  • [型変換] Symbolは暗黙的な型変換を潰している
  • [型変換] JSDocを使うことでコーディング時の型違反エラーに気付く
  • [アンチパターン] 一つの関数で型ごとに処理を分けるのは避けたい
  • [アンチパターン] jQueryで行われている
  • [アンチパターン] 言語レベルのサポートがないため難しい書き方になる
  • [型変換] JavaScriptには静的型ではないのた、間違った演算ができる
  • [型変換] NaN、無限などが生まれる
  • [型変換] これが生まれる前提のコードをかいては行けない
    • ゆーざーの任意入力を直接扱う場合ぐらい?
    • 入力を受け取る前に弾いたほうがいいのではないかな
• 暗黙的な型変換
  • "演算子の演算途中での型変換を期待したイディオム的な書き方"といえる気がする
  • なぜ暗黙的な型変換を避けたほうが良いのか?
  • 暗黙的な型変換は予期せぬ副作用を含んでいる可能性がある。
  • ダメなケース

"0" == false;           // true -- UH OH!
false == 0;             // true -- UH OH!
false == "";            // true -- UH OH!
false == [];            // true -- UH OH!
"" == 0;                // true -- UH OH!
"" == [];               // true -- UH OH!
0 == [];                // true -- UH OH!

[] == ![];      // true
var a = 42;
var b = [ 42 ];

a == b; // true

+ -

var a = {
    valueOf: function() { return 42; },
    toString: function() { return 4; }
};

a + "";         // "42"

var a = "3.14";
var b = a - 0;

b; // 3.14

toString/valueOfどちらを呼び出すというのかという違い。

基本文法 #17 というよりは事前の注意事項に近い気がする

ES6において、Strict modeはデフォルトであるという認識。(Module空間ではStrict Modeではないいけない)
逆にこれは var なしの変数宣言がstrict modeではできないなどの説明をするための事前情報として触れるべきものであるという認識。

• http://www.ecma-international.org/ecma-262/6.0/#sec-strict-mode-code
• http://www.ecma-international.org/ecma-262/6.0/#sec-strict-mode-of-ecmascript

なので、strict modeの存在は書くべきで、書籍中のコードは書かれてないけどstrict modeがデフォルトであるという話が必要そう
#46

コードはMITでいい気がするけど、文章のライセンスは特に決めてない。
Pull Requestする時とかに決めてないと問題になりそうだから、そのうち決める必要ありそう。

基本文法 #8
#15 変数 <- ここ -> #27 値/リテラル

• 値が評価されることについて
• REPLでの値の評価と結果
• console.log で値を出力できる

const str = "striing";
console.log(str); // => "string"

という他を説明するときに便利な項目を紹介する。
値に入る前に Console APIについてを出す。
デバッグするのに最も基礎的なものなので、目が止まるような形にしたい。

Markdown中に出てくるコードブロックもLintをしているつもりだったけど、

npm run eslint:md のglob指定は間違っているので修正する

summary-to-path | xargs eslint -c .md.eslintrc --ext .md

にすれば、文章を対象にできる。

• //
• /* */

正規表現とのリテラルの話は一行程度で触れたいけど、ここでは本質できないのでふれない。

値の評価 #14 の次あたりにさっと混ぜておくと説明がスムーズにできそう。
他の言語やってる人前提なら、単純にこう書くぐらいなので基本文法の中でもかなり短い

この本について 📖

この書籍はES2015以降をベースとしたJavaScript入門書となる予定です。
基本的なStableのECMAScriptのバージョンを扱います。

プログラミングをやったことがあるが、今のJavaScriptがよくわからないという人が、
今のJavaScriptアプリケーションを読み書きできるようになることを目標にする内容です。
(プログラミングが初めてという人が対象ではないです)

この本は、主に次の2種類から構成される予定です。

• 基本文法
• (応用)ユースケース

また、書籍として出版予定があります。

このIssueについて

新しいユースケースが思いついたら、新しいIssueを作ってここにまとめる。
Issue切るほどでもないアイデアを思いついたら、とりあえずここに書いておく形で利用しています。

その他全体的な構成についての意見を募集しています。 ✋

• こういう話も必要なのでは?
• JavaScriptを書いてていてこれを理解するのが難しかった(重点的にするべき)
• こういうユースケースがあるともっといいのでは?
• この本が分かりやすかった
• この機能の使いみちがよくわからない

といったようなコメントを書いてくれると参考になります。

基本文法

• 基本文法 #17

ユースケース一覧

• TODOアプリ #4
• Ajaxで何か #9
• Node.js CLIアプリ #7

#78 (comment) より。

node-static が広く使われているようなので、全体を通して統一したほうがよさそう。
各ユースケースのpackage.jsonで依存するか、ルートでインストールしてpeerDepsにしておくかなど決めたい。

#13 これもCONTRIBUTING.md関連になります。

用語の統一などは後から修正がしやすいですが、
文体的な、面は後から揃えるのが大変なのでIssueとして立てておきます。

文体的な話としてどちらで書いていくかというのを話し合うIssueです。
(本文と箇条書きは別の文体というのは問題ないと思います)

• 敬体(ですます調) ですます
• 常体(である調) である、だ

textlint-rule-no-mix-dearu-desumasuを設定すれば、どちらに統一するかというのはチェックできるようになっているので、どちらかに決めるというのはある程度自動的に決められます。

• 敬体(ですます調)と常体(である調)の表記を統一するtextlintルール | Web Scratch

が、文体は多分書籍の雰囲気とかどういう人向けに書いてるかというのにも影響がありそうなので、どういう雰囲気を目指すのかという話になるかもしれません。

いくつか書いてみて、次回のミーティングとかで方針を決められるといいかもしれません。

ユースケースのひとつ
Ajax通信を行ってデータを表示する簡単なアプリケーション

GitHubのAPIを使ってユーザーIDからプロフィールを出す

URLにsourceという名前が出てくるのはちょっと嫌であるため。
#55

話しておきたいことなどを書く場所です。

基本文法 #17

これやっかいな概念で2-3箇所にまたがったものになってる。

• ブロックスコープの機能 - 定義は #31 の手前で
• 変数宣言 #15
• 関数宣言 #20 (これは宣言についてのみ)
• for + let
• hoisting
• TDZ

これだけで一つのまとまりとして振り返る形でやったほうが理解がし易い(スコープってどこに書いてあったけ? みたいなときに、この辺かというまとまりが見える)ような気がする

この節では、JavaScriptのFunctiuonコンストラクタ的な話。
#20 関数宣言では、宣言方法、呼び方、値の返し方について学ぶ。

ここでは、 #20 では解説してない、スコープやクロージャーなどの挙動的な動作が中心になる。

Let’s Learn JavaScript Closures — Free Code Camp
この記事、クロージャーとArrow Functionを理解するのにすごくよく書けてる

Module内では動かないし、普通は使わないし、最近そこまで見ない。
なので外してしまうのがいいと思う。

コミットするときのルールはCONTRIBUTING.mdを作ってそこにまとめておくといい気がしていますが、必要になるであろうコミットメッセージのルールはどうしようかというIssueです。

多分AngularJS Commit Conventionで大丈夫ですよね?

• Git Commit Message Format

                       component        commit title
        commit type       /                /      
                \        |                |
                 feat(rule-context): add template url parameter to events

        body ->  The 'src` (i.e. the url of the template to load) is now provided to the
                 `$includeContentRequested`, `$includeContentLoaded` and `$includeContentError`
                 events.

 referenced  ->  Closes #8453
 issues          Closes #8454

• commit type: feat | fix | docs | style | refactor | perf | test | chore

Promise本の時に同じルールを参照してて、typeにwriteとか欲しくなりましたが、featで代用できると思うので、その辺の読み替えが必要になりますが、CONTRIBUTING.mdにその事をかいておけばいいとは思ってます。

• https://github.com/azu/promises-book/blob/master/CONTRIBUTING.md#git%E3%81%AE%E3%82%B3%E3%83%9F%E3%83%83%E3%83%88%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8

#17 基本文法

=> 変数 #15 => 値の評価 #14 => ここ

変更を定義して、その変数から値を取り出す/評価するという話をした後に、
「そもそも値とはどういうものがあったどうやって定義するのでしょうか?」という流れ。

この節は普通にやっても結構膨大なので、上手い見せ方が必要な気がする。

目的

JavaScriptは動的型付け言語だが、データには型があり典型的なプリミティブの型について理解する。
またプリミティブの型の多くにはリテラル表現が存在する。
このデータ型とtypeofの関係についてを解説する。

• データ型
• typeof

typeofでちょっと変なnullの例を見たところで実際のタイプ別に見ていく。
JavaScriptのデータ型はそれぞれリテラルをもっている。
実際にもっと詳細な形を見たい場合は、そのTypeごとに定義されている方法を使う。

• ECMAScript Language Types

実際にプリミティブな値を書くときは殆どのケースでリテラルを利用します。
既に書いていますが、改めてリテラル表現を見ていきます。

• リテラル - Literal
• Primitive
  • Number
    • 0x, 0b
  • String
    • エスケープ
    • Unicode \u{}
    • Template String
  • Boolean
  • null
• オブジェクト
  • オブジェクト
  • 配列
  • 正規表現
• おまけ: undefinedとnullはリテラル?

最後にオブジェクトについてです。
JavaScriptは全てがオブジェクトと言われているぐらい重要な概念です。
もちろんオブジェクトにもリテラルがありますが、{}と[]についてをまず見ていきます。

• Object
  • ObjectLiteral
  • ArrayLiteral

実際の色々なオブジェクトについては次の章で見ていきましょう

JavaScript文法の基本（フラナガン本の目次より抜粋）
・字句構造
・型、値、変数
・式と演算子
・文
・配列
・オブジェクト
・関数
・クラスとモジュール
・正規表現パターンマッチング

ユースケース解説に入る前に、ES2015に則った形で上記の簡潔な解説を入れてはどうか？

現在は特にないが、ウェブサイトとして公開した時に、リリース情報の通知を受け取れるフォームを用意する。
メールアドレスを入れてもらって、リリース時に通知する形での利用。

letやconstはコンソール内だと、二重定義することができないためコピペして確認するのは不向きとなっている。

やること

そのため、 #17 基本文法は var を利用するということを明記する。
逆にユースケースでは積極的に const を使うということを明記する。
#15 の該当記述を修正する。

この本のURL として示しやすいページが欲しいので用意する。
合わせて #33 のフォームを配置する。

このリポジトリはtransferしたり、リポジトリ名を変更したりする可能性があるから、URLが一番問題になりそう。(少なくてもリポジトリ名は変更が必要…)

• gh-pagesはリポジトリをtransfer/renameしても追従されない
  • About repository transfers - User Documentation
• リポジトリ自体( https://github.com/asciidwango/ES6book/ )は追従される

とりあえずな感じだとgh-pagesで用意しておいて、ちゃんとタイトルとかが決まったらそっちにリダイレクトする感じになる気がする。(transferしないでgit的に移すだけ)

JavaScript Plugin Architectureで試した感じでは、多くの人は一番ランディングページっぽいページをブクマとかする傾向があった。
GitHub.com はCSPが有効でFirefoxだとブックマークレットとかも使えないとかそういう要因もありそう。

• JavaScript Plugin Architectureというプラグイン設計について学ぶ無料の電子書籍を書いた | Web Scratch
• azu/JavaScript-Plugin-Architecture: JavaScriptプラグインアーキテクチャの本
• JavaScript Plugin Architecture - GitBook <= ランディングページっぽい
• この書籍について · JavaScript Plugin Architecture

📝

ドメインを使う場合はOrganizationを作って、Organizationにドメイン設定したほうが楽(リポジトリ単体だと扱いにくくなる)
複数リポジトリが必要になる可能性としては、ユースケースのサンプルを見られるURLを用意したい場合とかはリポジトリを複数作ってそこのgh-pagesに公開すると楽。

ドメインはJS.ORG | DNSのサブドメインという選択肢もあるけど、名前決めないと行けない問題は同じ

---
description: This is a short description of my page

---

GitBookとGitHubはFront Matterをサポートしているので、そこにメタ的な情報を入れておくと便利かもしれない。

その章のサマリとかタグとかがあると機械的なチェックに役立つ可能性がありそう。
すぐに役立つものではないので、将来的にあったほうがいいものを考えておくといいかもしれない。

http://azu.github.io/promises-book/ でも実装したもの。
コードをその場で実行できるものをウェブ版で見られるようにしたい。

推奨ブラウザを設定すれば、殆どそのまま実行できるような仕組みだけでも良い気がする(Babelのような変換を挟まなくていい)

実行しながら読むと理解の補助になるというのは、Promise本の感想やオンライン勉強会でやった時に感じているので、この機能は結構重要になりそう。

類似する仕組みをもっているもの

• http://azu.github.io/promises-book/
• http://mohayonao.github.io/web-audio-lesson/
• http://eloquentjavascript.net/

基本文法 #14

• グローバル変数 ( without var - #25 strict modeに依存 )
• var
• let
• const
• 変数名に使える文字 mothereff.in/js-variables
• プロパティ #27

変数とプロパティは一緒に説明すべきかは微妙そう。
オブジェクトの説明のあとになりそう。

この書籍のユースケースでは prefer-const ではいいと思ってるけど、REPLで確かめて見て！ みたいなケースだとletの方が繰り返し定義できて便利である。

ここではなぜ複数あるのかとその意味の違いについてだけ簡潔にやる

jsprimer

• GitBookのボタン
• Twitterボタンを設定する

サンプルコードのテストを常に回しておきたい

#8 で基本文法の章を書くことになったので、基本文法に関するメタIssueです。

Issueの目次のような感じ かつ 基本文法の章にあったほうがいいものをメモって置くIssueです。

• JavaScriptの導入 #18
  • JavaScriptって何?とこの章の目的
• JavaScriptの概要 #87
• コメント #16
• 変数宣言 #15
• 関数宣言 #20
• 値の評価方法、コンソールへ出力 #14
• リテラル/値/Primitive #27
• 式(Expression)と文(Statement) #70
• 制御構文 if/switch/block/space #31
• ループ: for/for in/for of/while/do while #68
• 演算子 #32
• 型変換 #53
• エラー
• try...catch文 #93
• ビルトインオブジェクト
  • Object #126
  • String
  • Math/Number #100
  • Array #49
• 関数 #112
  • 関数宣言、関数式、Arrow Function #20 #119
  • スコープ/クロージャー #277
• class #39
• Promise #94

この辺でもうある程度書ける

その他の書く候補

• 基礎文法
  • #112 関数のまとめ
  • Destructuring
  • 関数/Arrow Function
  • Spread Operator
  • Error/Throw
  • クラス
  • 正規表現
  • Generator/Iterable/Iterator
• ビルトインオブジェクト
  • JSON
  • Date
  • Map/WeakMap
  • Set/WeakSet
  • Symbol
  • Promise
• Note
  • ECMAScript策定プロセス
  • Reflect API - Proxyとセット
  • Proxy - むずかしそう
  • Unicode - サロゲートペアとか
  • Intl - やるか微妙

これ先に配列とオブジェクトのデータへのアクセス方法をちゃんと書いた方が良さそう。
(ユースケースにかなり触れにくい)
オブジェクトは データ型とリテラルで書いているので、配列も同じ場所に array[index] でアクセスできるというのを書いたほうがよさそう。

• https://github.com/asciidwango/js-primer/blob/master/source/ch1/data-type/README.md#%E9%85%8D%E5%88%97%E3%83%AA%E3%83%86%E3%83%A9%E3%83%AB

via #68 (comment)

リテラルのところで、配列へのアクセス方法と 0-based indexであることは書いたほうが他の章的に解説しやすいので、簡単に触れる(2-3行程度)

TODOアプリをユースケースとして作ってみようと言う話があったので。

TODO

• Todoアプリにタイトル変更機能はいらないことする
• Todoアプリに最低限のスタイルを当てる #432
• クラスのEventEmitterをTodoアプリの方に移動する
  • #424
• Todoアプリのソースは最終形と断片を読み込んで書く
  • 分割するラインを決めていく
• ES moduleのネットワークエラーについてを書く
• Todoアプリにフィルターをいれる
  • 独立して追加できるので「やってみよう」に落とすかも
  • ボリューム的に最初は落とす
• セクションまとめはチェックボックスへ
• スクリーンショットを取り直す
• ローカルサーバの立て方の変更 #462
• イベントの用語統一 #455
• タイトルを動詞(目的)に変更

アウトライン

• https://github.com/asciidwango/js-primer/blob/master/source/use-case/todoapp/OUTLINE.md

セクションまとめのチェックボックス

• セクションごとでやったことをチェックボックスにする

#17 基礎文法/オブジェクト

配列についての章。

アウトライン:

• https://github.com/asciidwango/js-primer/blob/master/source/OUTLINE.md#%E9%85%8D%E5%88%97

基本文法 #17

関数 #112 の続き

目的

• class構文の基本的な使い方について学ぶ
• JavaScriptのクラスの性質についての概要
  • prototype、関数との関係について

目的ではないこと

• オブジェクト指向のパターンなど考え方に近い部分
• 型としてのクラス
• 現在のProposalの詳細(privateとかpublic fieldの詳細、こう書けるようになるかも的な話)

アウトライン

• https://github.com/asciidwango/js-primer/blob/master/source/basic/class/OUTLINE.md

関連

• #345 プロトタイプ(大きくなったのでIssueとして分けた)

参考文献

• 14. New OOP features besides classes
• クラス - JavaScript | MDN

基本文法だとユニットテストを書くまでではない(逆に書きにくい)ものが多い。
以下の形式でdoctestライクのテスト方法を追加する。

• 25.2. doctest — 対話的な実行例をテストする — Python 2.7.x ドキュメント

let a = 42;
console.log(42); // => 42

これにより、サンプルコードのコメントに書いた評価結果と実際の出力が一致するかをテストできる。

サポートする形式

評価したい式; // => 期待する評価結果

or

console.log(評価したい式); // => 期待する評価結果

• power-assertを使ったDoctestツール power-doctestを書き直した | Web Scratch
• JavaScriptでdoctestを行う power-doctest を作った | Web Scratch

関連

#14 #36

Node.jsのCLIアプリで何か一つユースケースがあるといいのではないという話が #5 ででた。
具体的に何かは出てなかったので、考える必要がありそう。

/cc @laco0416

#17 基本文法

演算子について

• 一つの節に演算子をまとめるの目的
• 演算子は検索がしにくいため、知らない記号がでてきたらここを見てという意図
• 型変換の詳細は別にする
• 二項演算子
  • プラス （+）
  • マイナス （-）
  • 乗算 （*）
  • 除算 （/）
  • 剰余 （%）
  • 指数演算子 （**）
• グループ演算子
• 単項演算子（算術）
  • 単項プラス （+）
  • 単項マイナス （-）
  • インクリメント （++）
  • デクリメント （--）
• 比較演算子
  • 等しい （==）
  • 等しくない （!=）
  • 厳密に等しい （===）
  • 厳密に等しくない （!==）
  • より大きい （>）
  • 以上 （>=）
  • より小さい （<）
  • 以下 （<=）
• ビット演算子
  • ビット論理積 （&）
  • ビット論理和 （`|&）
  • ビット排他的論理和 （^）
  • ビット否定 （~）
  • 左シフト（<<）
  • 右シフト（>>）
  • ゼロ埋め右シフト（>>>）
• 代入演算子
• 条件（三項）演算子
• 論理演算子
  • AND(&&)
  • OR(||)
  • NOT(!)
• 文字列演算子
• コンマ演算子
• 余白
  - [ ] 単項演算子（特殊）
  - delete演算子
  - typeof演算子
  - void演算子
  - [ ] 関係演算子
  - in演算子
  - instanceof演算子
  • [仕様] 演算子の優先度
  • [構文] typeofは typeof()とかけるとけど、これは()という演算子とtypeof演算子が組み合わさっているだけ = 関数ではない
  • [仕様] NaN
    • *でNaNになる仕組み
    • IEEE 754で決められた仕組み
    • Infinity
  • [演算子] 優先度の調整をするには () を使う
  • [演算子] 四則演算はどの言語でも同じ
  • [演算子] ビット演算子は使うひとは使うという感じ
  • [演算子] andとor演算子は、四則演算/比較以外だと多用される
  • [Tips] ショートカット的な使い方をすることが多い
  • [型変換] || は 0 がfalsyであることに気をつける必要がある
  • [型変換] 比較演算子の==はほぼ使わない
  • [型変換] 例外は == null のみ
  • [型変換] 基本的には === のみを使う方が安全
  • [型変換] JavaScriptには暗黙的な型変換があるため
  • [演算子] == null は === null && === undefinedという意味
  • [演算子] ++と--は実はここまで使って来なかった? forで使ってるかも
  • [演算子] ++はインクリメンタル += 1
  • [演算子] --はデクリメンタル -= 1
  • [演算子] + は文字列結合としても使える
  • [仕様] JavaScriptに演算子overloadはない
    • 一時期提案されてたけどどっかいった
  • [演算子] + は数字と文字列のみとする
  • [型変換] + は文字列を数字に変換する
  • [型変換] + は Number(string) にする
  • [型変換] - は数字に変換する
  • [型変換] - を文字列に使うのはハック的なやりかた
  • [演算子] ! は真偽値を反転させる
  • [型変換] ! は評価した値を反転ので、暗黙的な型変換が行われる
  • [型変換] 演算子はなんだかんだと勝手に型変換が行われる
  • [型変換] 同じ型以外を安易に比較してはいけない
  • [型変換] どうやって同じ型だけに限定するかというのも考える必要がある
  • [比較] プリミティブに落として比較するよりオブジェクトかどうかの真偽値を取る方法[比較] Array.isArray、Object.isなど、Object.shallowEqualなど
  • [[class]]とtoStringの問題
  • [型変換] 型変換は明示的に行う
  • [型変換] 暗黙的な型変換を避ける
  • [型変換] Symbolは暗黙的な型変換を潰している
  • [型変換] JSDocを使うことでコーディング時の型違反エラーに気付く
  • [アンチパターン] 一つの関数で型ごとに処理を分けるのは避けたい
  • [アンチパターン] jQueryで行われている
  • [アンチパターン] 言語レベルのサポートがないため難しい書き方になる
  • [構文] /と正規表現リテラルとコメントは紛らわしいという問題がある
  • [構文] パースするのが難しかったがsweet.jsのやつで解決できてた
  • [演算子] newとかin、...演算子はどうするか?
  • [演算子] in演算子はプロトタイプチェーン
  • [演算子] ...はspread の話でまとめたい
  • [演算子] 演算子の話を演算子の話でまとめるのは難しい
  • [演算子] 助詞みたいな話なので、演算子だけどうこうできることは少ない
  • [演算子] 論理演算子はできるだけ簡潔に
  • 複数の方向の条件を一つの文でまぜない
  • [Tips] ベン図を書いて解決してみる => リーダブルコードに載ってる
  • [Tips] 演算子の間違いはバグを起こしやすい
  • [Tips] テストしたい条件分岐
  • [型変換] JavaScriptには静的型ではないのた、間違った演算ができる
  • [型変換] NaN、無限などが生まれる
  • [型変換] これが生まれる前提のコードをかいては行けない
    • ゆーざーの任意入力を直接扱う場合ぐらい?
    • 入力を受け取る前に弾いたほうがいいのではないかな
  • [Number] +0と-0は異なる
  • [判定] Object.isでは判定できる
  • [判定] +∞なのか-∞なのかという違いがでる
  • 仕様での分類
  • [判定] 複雑な例 Rule no-mixed-operators - ESLint - Pluggable JavaScript linter
  • [分類] 12.4 Update Expressions
    • ++

      ---

  • [分類] 12.5 Unary Operators
    • delete
    • void
    • [登場済み] typeof
    • [型変換] +
    • [型変換] -
    • ~
    • !
  • [分類] 12.6 Exponentiation Operator
    • **
  • [分類] 12.7 Multiplicative Operators
    • [登場済み] *
    • [登場済み] /
    • [登場済み] %
  • [分類] 12.8 Additive Operators
    • [登場済み] +
    • [登場済み] -
  • [分類] 12.9 Bitwise Shift Operators
    • <<

  • [分類] 12.10 Relational Operators
    • <
    • <=

    • =

    • instanceof
    • [登場済み?] in
      • for in
    • true or falseを返す
  • [分類] 12.11 Equality Operators
    • ==
    • !=
    • [登場済み] ===
    • [登場済み] !==
  • [分類] 12.12 Binary Bitwise Operators
    • &
    • ^
    • !
  • [分類] 12.13 Binary Logical Operators
    • &&
    • ||
  • [分類] 12.14 Conditional Operator
    • [登場済み] ? :
  • [分類] 12.15 Assignment Operators
    • *=/=%=+=-=<<=>>=>>>=&=^=|=**=
  • [分類] 12.16 Comma Operator
    • [登場済み] ,
  • MDNの分類
    • Expressions and operators - JavaScript | MDN
  • 分類

演算子はJavaScriptの歴史が詰まった感じなので、色々だけここでまとめられるものはまとめたい。
演算子は検索がしにくいのもあるため、このページに書いてあったような気がするという感じにまとめたい

#17 基本文法
#112 関数のうち "関数宣言" について

• function declaration
• function expression
• Arrow function
• その他
  • 関数宣言
    • 関数宣言はセミコロンがいらない
    • セミコロンは文を区切るための構文
    • 関数宣言自体は文で終わっているワケではないため
  • 関数式
    • 関数は値である
    • ファーストクラスである関数
    • const fn = function(){}ができる
  • Arrow Function
    • 関数式の現代版といえるもの
    • 関数式を利用する場合は多くのケースでこちらを使ったほうが良い
    • this(see スコープ)の問題などがおきにくいため
    • また、Arrow Functionに名前を付けるにはletやconstを使わないと行けない。
    • そのためvarはやっぱりダメ
    • 短く誤解がない表現なので、function式よりはArrow Functionを使いましょう
  • メソッド
    • ES2015まではメソッドはただの関数が値として入ってるプロパティの事だった(定義は今も同じ)
    • JavaScriptのメソッドは var obj = { method(){} } で定義できる
    • var obj = { method : function(){} } と書くこともできるがこれは関数式と同じ
    • なので現在的にはメソッド定義をする方法はメソッド定義の記法でやる

GitBookのページ上からGitHubの編集画面に飛ぶリンクが欲しい。

https://github.com/rtCamp/gitbook-plugin-edit-link を使い、
ページからGitHubの編集画面へ直接飛べるようにする。

#42 の議論の結果

• リポジトリ名 = URLなので大文字は使いたくない
• ES6のような時間をふくめたくない

ので、 js-primer にリネームする。

• リポジトリ名
• packge.json
• URL
• mail form #48

#31 制御構文からの分離
#31 制御構文 -> iteration(ココ) の順番

• while
  • 原始的なループ処理
  • 使い道が不定の長さの処理を扱う時
  • 無限ループとなる事が多いので慎重になる
  • for(;condition;) と同じ
  • JavaScriptだとbusy loopは基本使わない
  • 無限長のループはGeneratorでできる
• do while
  • whileとの違いは最初の１回が実行されること
• for文
  • 最も使われてる繰り返し文
  • Array#forEach
  • forEachも中身はfor文
  • [ユースケース]値の合計を計算する
• break
  • forループ中に処理を中断する
  • [ユースケース] 配列から要素を探索
  • 先頭一致で探索終了
  • Array#someが実装できそう
• continue
  • forループ中に次のループへ処理を飛ばす
  • [ユースケース] 配列から要素のフィルタリング
  • 要素が見つかった => 次のループへ
  • 要素が見つかった => 回収
  • Array#filterが実装できそう
• for...in
  • [仕組み] for...inはオブジェクトのキーを列挙する構文
  • [Bad] for...inはオブジェクトである配列にも使えるが間違い
  • [Bad] for...inはbadパーツ
    • prototypeの仕組みや細かい罠が多いため理解するまで避ける事を推奨する
    • prototypeについて意識しないと書くことができないもの
  • [仕組み] for文 + in 演算子
  • [仕組み] in 演算子について学ぶ必要がある
  • [仕組み] 詳しくはprototypeチェーンの話が必要
  • [使い方] hasOwnPropertyと組み合わせる必要がある
    • for...in - JavaScript | MDN
  • [使い方] Object.create(null)で作られたものだと簡単に崩壊する
  • [代用] Object.keys()/Object.values()で代用できる
• for...of
• 未使用
  • label
    • breakとcontinueと組み合わせる
    • goto文
    • 深いループから抜ける用途
    • 現代的に使ってたらおかしい
    • 関数で抽象化すればreturnで代用できる
    • 一般に使わないし、目にすることもないので必要な知識
    • http:// がなぜvalidかという豆知識
      • 0-9, JSでラベルがサポートされ続けなければならない理由
  • while
    • whileの変数宣言はwhileの外側
    • パースとかでは使ってる印象がある
    • whileは常に副作用を期待してる
    • 回数未定のループ処理 while文とdo...while文 | JavaScript入門編
    • trueを書いてしてる間ずっと続く
    • 副作用only
    • WebWorkerであってもbusy loopは微妙
    • while(regexp.exec("test")) でマッチング
    • nullを返すのはexecとObject.getPrototypeOfだけ
  • for in
    • 実際に有用な使い道がない気がする
    • すべての他の手段で代用できる
    • 逆にでてきた瞬間マイナスから始まる
    • leobalter/object-enumerables: Object.enumerableKeys / Object.enumerableValues / Object.enumerableEntries
  • for...of
    • Iteratorという概念がJavaScriptにある
    • Arrayはもちろん、 Map, Set, String, TypedArray, 引数オブジェクト
    • さらにDOM NodeListもIterable
    • for...of - JavaScript | MDN
    • forとは違うのは next() を呼ぶことに次の値を得ることができるリンクリストであること
    • 無限リストや遅延評価的なことに利用できる
    • 今後の使い道的にはかなり広大な概念
    • Symbol.iteratorで任意のオブジェクトをiterableにできる
    • Generator、Iterator、Iterable

草案

プログラミングにおいて、同じ処理を繰り返すために同じコードを書くことはありません。
ループや再帰呼び出し、イテレータなどを使い繰り返し処理は抽象化されます。
ここでは、もっとも基本的な繰り返し処理となるループについてを学んでいきます。

リポジトリにミーティングノートを追加しました

• https://github.com/asciidwango/ES6book/tree/mtg-note/meeting

@kahei 間違って mtg-note ブランチを先にpushしてしまって、mtg-noteがデフォルトブランチになってしまいました。(ブランチがない状態だと最初のブランチがデフォルトとなってしまうようです)
コラボレーター権限だとデフォルトブランチの変更ができないので、以下の手順でデフォルトブランチをmasterに変更をお願いできますか?

• Setting the default branch - User Documentation

今はJavaScriptをサポートしていないブラウザはないため、過去に書かれたHTMLコメントをエラーとしないために追加されました。

くどい表現になってる。

言いたいこととしては

• JavaScriptをサポートしてないいないブラウザはもうない
• そのためこのハックはいらない
• しかしサポートを切ると過去に書かれたサイトの互換性がなくなってしまう
• そのためブラウザはこの機能を捨てることができない
• 事実上実装されている機能であるなら、ちゃんとしようとして明記しようとなった
• そうしてできた仕様

というわけだけど、長い

基本文法 #17

• 文と式 => #70 へ

• if/else/elseif
• swich
• { } block
• space
• ASI セミコロン自動挿入

ラベルは次のコードが動くという豆知識ぐらいにしか使わない気はする

http:// 

ここは単純に説明するだけだとそうですねって感じがするので、できるだけ実際の細かいユースケースに寄せたい。
とくにswitchとかはなんとなく使うパターンがあるとは思う(アンチパターンになりやすい)

草案

• ブロックステートメントについての解説。ブロックの機能については #24 で扱う
• if文、else-if、elseについて一通り解説
• 全てを使ったサンプル - 閏年? C言語入門：うるう年判定プログラム:Geekなぺーじ
• switchでは列挙するようなものが書ける
• break忘れによるミスの紹介
• もっと正しく使うには関数と組み合わせる必要がある

Iterator関連は #68 に分離

基本文法 #17

式(Expression)と文(Statement)についての解説をする。

• 式(Expression)
• 文(Statement)
• ブロック(Block)

について解説する。

式(Expression) は演算子 #32 の説明に必要 https://asciidwango.github.io/js-primer/basic/operator/
文(Statement)とブロックはループ #31 の説明に必要 https://asciidwango.github.io/js-primer/basic/condition/

式はそれ単独では基本的に完結せず、文または式の一部として使用される言語要素です。また、式の最大の特徴として、値を返すという点が挙げられます（文は値を返しません）。
-- 式(Expression)と文(Statement) - よねＫＥＮのプログラミング研究

文は実行されて副作用

手続き型言語の単位は「文」
文は一文一文ごとに「実行」される。実行の結果は「副作用」によってのみ表現できる

• プログラミングにおける式と文とは - 愚鈍人
• Rubyist Magazine - 式と文、評価と実行、そして副作用 ―― プログラムはいかにして動くのか【前編】

こういう関係なのかな

+-------------------------------------+
|                                     |
| Declaration                         |
|                                     |
|                                     |
|          +----------------------+   |
|          |                      |   |
|          |   Statement          |   |
|          |                      |   |
|          |    +--------------+  |   |
|          |    |              |  |   |
|          |    |  Expression  |  |   |
|          |    |              |  |   |
|          |    +--------------+  |   |
|          |                      |   |
|          +----------------------+   |
|                                     |
+-------------------------------------+

http://astexplorer.net/

アウトライン

概要: JavaScriptは式と文で構成されている。

• 文はセミコロンで区切る
  • 序盤で話している
• JavaScriptは文と式の集まりで構成される
• 文は文と式を含む
  • Statement
  • ブロック文
• 式は式を含む
  • FunctionExpressionはbodyが文なので式は文を含むことがある
  • Expression
  • 式が単独で式文となる
  • REPLとかに書いても問題無いよ的な感じ
• 文は値を返さない＊
  • 例 if文
  • statement
• 式は値を返す＊
  • 例 三項演算子
  • expression
• if-elseと条件演算子 これ自体は condition のところで書いた方が良さそう

コンソールへの表示方法を扱っているが、開き方については書かれてない
ここで開き方について簡単に触れる。
(変数宣言より前に持って行ったほうが楽かも)

やること

• index.htmlと<script>を使っての実行(ブラウザ(推奨はFirefox)を使ったコンソールの開き方と実行)
  - index.htmlにscriptタグを書いて、コンソール実行。リロード方式
  - script のtypeなしで書く
• 実際に実行したときの表示の読み方
• VSCodeコラム
• 構文エラーがでた例 と エラーのふりがな
• 実行時エラーがでた例と エラーのふりがな
• その他のリンク
  - CodeSandboxとか設定方法へのリンクをまとめたもの

関連

• #83: feat(ajaxapp): エントリポイントについての節を追加

コラム的な扱い

2016-05-27のES2016以降を含めるかどうか?でも議論したけど、策定プロセスやどこで誰が決めているのかという事について触れる。

目的

JavaScriptでは先行実装的を取り入れたという形のツールやライブラリが多い。
ECMAScriptのProposalsは、必ず仕様に入るわけではないので、あくまでそれは提案中の仕様にすぎないという話は現実的に知っておいたほうが良い。(変に振り回されても困るため)
そのため、その判断基準を身につけるという意味での話が必要となる。

仕様以外のはなしとしてもopinionが強いものが結構多い(これは単に人数が多いというのもある)ので、そういう情報の読み方探し方という話になってしまうのかもしれない。

ES6 または ES2015という表記をメインに使うかどうか
最初に ES6 === ES2015 という話は書くが、メインの用語としてはどちらを使うかどうかを決める必要はありそう。

Dr. Axel の本はES6で、続きの今書かれてる本はES2016...という感じにしている。

• Exploring ES6: Upgrade to the next version of JavaScript
• Exploring ES2016… by Axel Rauschmayer [Leanpub PDF/iPad/Kindle]

(微妙に関連して、この機能はES6から使える みたいな表記をアノテーションとして入れておいた方が、後々役立つ気がするが、これは別Issueっぽい。関係あるのは基本文法が殆どだけど)

2016年5月27日のミーティングで事前に書いておきたいアジェンダを書いておく場所です。

書籍で扱う実行環境の数は少ないほど記述のブレが減るため、いずれは決めておく必要があると思います。
その実行環境を何にするのかを話し合うIssueです。

ES6と実行環境

現在のブラウザでES6対応が進んでいるものとしては、以下のようなものがあると思います。

• MSEdge
• Firefox
• Chrome
• WebKit/Safari

この中でクロスプラットフォームなものとしては

• Firefox
• Chrome

となります。

また、ES6の対応状況としてECMAScript 6 compatibility tableを参照した場合、

• Chrome 50 - 91%
• Firefox 45 - 85%

となっています(この数値にはES6 Modulesは含まれていません)。
Chromeの残りは末尾呼び出し最適化で、こちらの方は実装が進んでいるので数ヶ月以内に100%実装になると思います。

Moduleも実装は進められています。(こっちは仕様も一緒に進めつつなのでいつ終わるかはよくわからない)

• Chrome: Chrome Platform Status
• Firefox: 1240072 – Implement milestone 0 <script type="module">
• MSEdge : Looking ahead: Microsoft Edge for developers in 2016 | Microsoft Edge Dev Blog

実行環境について

本題ですが、実行環境としてはFirefox(Spidermonkey)かChrome(V8)のどちらかになるとは思います。

Chromeを選択した場合、ブラウザ以外にもV8を使った実行環境としてはいくつか選択肢があると思います。

• Mancy - An Electron based NodeJS REPL ApplicationのようなElectronを使ったREPL
• Node.js

ブラウザじゃないメリットとしては、バージョンが固定しやすいとか専用のものを作りやすいというぐらいですね。
逆にブラウザじゃないと別途インストールしないといけないものが増えたり、初めて見るものが増えるとかですかね。

決めるべきこと

• 実行環境(Firefox or Chrome)

ここで決めておくどっちのブラウザか(どっちもか)、またChromeならブラウザかそうでないものがいいのかぐらいな気がします。

#17 基本文法

• Booleanによるキャスト
• trueとなる値、falseとなる値
• new BooleanとBoolean(コラム)

これは完全にMDNと同じになる気がしている。

• Boolean - JavaScript | MDN

trueとなる値、falseとなる値

についてを重点的にわかりやすく解説するのを目的とする。

関連

#31 で 次のように書いてるので、ここでその問題を解決する

どのような式がtrueとして評価されるかは、[Booleanオブジェクト][]で紹介します。