値の評価について

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

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

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

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

条件分岐: if/switch/block

基本文法 #17

文と式 => #70 へ

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

http://

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

草案

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

Iterator関連は #68 に分離

data-type: 配列リテラルとアクセス方法

これ先に配列とオブジェクトのデータへのアクセス方法をちゃんと書いた方が良さそう。
(ユースケースにかなり触れにくい)
オブジェクトはデータ型とリテラルで書いているので、配列も同じ場所に 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行程度)

ブラウザアプリユースケース用の開発サーバ

#78 (comment) より。

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

[meta] 敬体(ですます調)と常体(である調)

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

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

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

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

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

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

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

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

ミーティングノートの追加

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

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

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

Setting the default branch - User Documentation

[meta] JavaScriptの基本文法

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

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

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

その他の書く候補

基礎文法
- #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 - やるか微妙

TODOアプリ

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

TODO

アウトライン

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

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

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

関数宣言、関数式、Arrow Function

#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(){} } と書くこともできるがこれは関数式と同じ
  - なので現在的にはメソッド定義をする方法はメソッド定義の記法でやる

スクリーンショットについて

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

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

懸念点：

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

loop: for/for in/for of/while/do while

#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

草案

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

2016-06-28 ミーティングアジェンダ

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

式(Expression)と文(Statement)

基本文法 #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) - よねＫＥＮのプログラミング研究

文は実行されて副作用

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

こういう関係なのかな

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

http://astexplorer.net/

アウトライン

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

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

コラム: ECMAScript/JavaScript策定プロセス

コラム的な扱い

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

目的

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

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

Node.jsのCLIアプリ

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

/cc @laco0416

リテラル/値/Primitive

#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

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

2016年5月27日MTG アジェンダ

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

ES2015 or ES6 どちらを使う?

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

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

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

data-type: 型変換

基礎文法 #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どちらを呼び出すというのかという違い。

実行環境について

書籍で扱う実行環境の数は少ないほど記述のブレが減るため、いずれは決めておく必要があると思います。
その実行環境を何にするのかを話し合う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ならブラウザかそうでないものがいいのかぐらいな気がします。

Ajax通信を行うブラウザアプリケーション

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

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

コミットメッセージの規約

コミットするときのルールは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

operator/演算子

#17 基本文法

演算子について

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

Docテストの追加

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

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

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

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

サポートする形式

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

or

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

目的

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

目的ではないこと

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

アウトライン

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

参考文献

リリース時に通知を受け取れるフォーム

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

変数 var, let, const

基本文法 #14

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

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

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

Twitterのハッシュタグ

jsprimer

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

prototype/ブロックスコープ/クロージャー

基本文法 #17

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

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

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

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

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

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

文法の基本解説をどうするか

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

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

Front Matterにメタ情報を入れる

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

---

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

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

read-eval-print: コンソールの開き方について

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

やること

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

	Organization	Repository only
Domain	一番柔軟で変更に強い	複数のリポジトリが必要になるとダメ
No Domain	ドメインがない以外は特に問題なし	単一のリポジトリなら問題なし

この本について 📖

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

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

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

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

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

このIssueについて

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

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

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

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

基本文法

基本文法 #17

ユースケース一覧

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

コメント: HTML commentは本編からは外す

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

Bug: npm run eslint:mdの修正

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

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

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

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

連絡ほか

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

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

正規表現/RegExp

基本文法 #17

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

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

基本文法では`var`を使う

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

やること

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

Booleanオブジェクト

#17 基本文法

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

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

Boolean - JavaScript | MDN

trueとなる値、falseとなる値

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

asciidwango / js-primer Goto Github PK

js-primer's Issues

草案

TODO

アウトライン

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

草案

アウトライン

目的

目的

アウトライン

+ -

ES6と実行環境

実行環境について

決めるべきこと

サポートする形式

関連

目的

目的ではないこと

アウトライン

関連

参考文献

jsprimer

やること

関連

この本について 📖

このIssueについて

基本文法

ユースケース一覧

やること

関連

Recommend Projects

Recommend Topics

Recommend Org