いろいろ

Author: shibukawa

baseenv.rst

@@ -5,6 +5,7 @@
 環境構築の共通部分を紹介しておきます。
 
 プロジェクトでのコーディングであれば、誰が書いても同じスタイルになるなど、コード品質の統一が大切になりますので、単なる個人用の設定ではなく、それをシェアできるというのも目的として説明していきます。
+
 ここでは、基本的にすべてのプロジェクトでJest、ESLint、Prettierなどを選択しています。まあ、どれも相性問題が出にくい、数年前から安定して存在している、公式で推奨といった保守的な理由ですね。きちんと選べば、「JSはいつも変わっている」とは距離を置くことができます。
 
 * Jest
@@ -214,18 +215,29 @@ Prettierの設定ファイルも作成します。シングルクオートの有
 Visual Studio Codeの設定
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-VSCodeから利用する場合は、拡張機能と、その設定をファイルに記述しておきます。まずは拡張機能です。
+Visual Studio Codeから利用する場合は、拡張機能と、その設定をファイルに記述しておきます。まずは拡張機能です。
+
+Visual Studio Codeでフォルダを開いたときに、必要な拡張機能がインストールされるようにします。\ ``.vscode``\ フォルダにファイルを作ることで、プロジェクトのソースコードと一緒に、プロジェクトの共有設定を共有できます。同じ拡張機能を入れてもらって、コードチェックなどのクオリティを統一し、コードインテグレーション時に無駄な調整をしなくて済むようにできます。ここではついでにコードのスペルチェックの拡張機能も入れておきます。
+
+この設定はこのJSONを書いても良いですし、拡張機能のページで該当する拡張機能を開いてから、コードパレットで\ ``Extensions: Add to Recommended Extensions (Workspace Folder)``\ を選択すると追加されます。
+
+.. figure:: images/add-to-recommendation.png
+
+   拡張機能をプロジェクト推奨に設定
 
 .. code-block:: json
    :caption: .vscode/extensions.json
 
    {
      "recommendations": [
        "esbenp.prettier-vscode",
-	   ],
+       "streetsidesoftware.code-spell-checker"
+     ],
      "unwantedRecommendations": []
    }
 
+インストールができたら、次はその拡張機能の設定をします。こちらもプロジェクトのリポジトリにファイルを入れておくことでプロジェクトメンバー間で共通の設定をシェアできます。
+
 Prettierを標準のフォーマッターに指定し、VSCode自身の実行メカニズムを利用してファイル保存時にフォーマットがかかるようにします。  
 
 .. code-block:: json
@@ -255,7 +267,15 @@ ESLintのインストールと設定はウィザードで作ります。
 
 モジュール形式はCommon.jsかES6 modulesか、使う場合はReactかVueか、Node.jsなのかブラウザなのか、TypeScriptを使うのかあたりを聞かれます。設定ファイルをどの形式で出力するか、最後に必要なパッケージをnpmでインストールするかも聞かれます。モジュール形式はES6 modulesを、TypeScriptの利用はYを、設定ファイルの形式はJavaScriptを、ツールのインストールはYを選択します。ウェブのフロントエンド、ブラウザ向けかNode.jsか向けかは環境に応じて選択してください。これインストールと設定は8割がた完了です。
 
-ESLintの設定は、機能を追加するプラグインと、設定をまとめて変更するextends、プロジェクト内部で個別に機能を切り替えるのはrulesに書きます。次のサンプルはブラウザ＆React、TypeScriptで生成したものに、Prettier関連の\ ``extends``\ を2つ追加したのと（必ず末尾におくこと）、個別ルールで、開発時のみ\ ``console.log()``\ を許可するように、返り値の型推論を許可しています。ESLintとPrettierでオーバーラップしている領域があり、ここで追加したextendsはそれらの設定が喧嘩しないようにするためのもので、ESLint側の重複機能をオフにします。React拡張を作成する場合は、Reactバージョンの設定をしないと警告を毎回見ることになるでしょう。 
+ESLintの設定は、機能を追加するプラグインと、設定をまとめて変更するextends、プロジェクト内部で個別に機能を切り替えるのはrulesに書きます。次のサンプルはブラウザ＆React、TypeScriptで生成したものに、Prettier関連の\ ``extends``\ を2つ追加したのと（必ず末尾におくこと）、個別ルールで、開発時のみ\ ``console.log()``\ を許可するように、返り値の型推論を許可しています。また、コールバック関数の利用でよくあるのですが、未使用引数で出る警告はライブラリ側の都合で避けようがなかったりするため、アンダースコアで始まる名前の変数に関しては未使用でも警告が出ないようにしています。
+
+ESLintとPrettierでオーバーラップしている領域があり、ここで追加したextendsはそれらの設定が喧嘩しないようにするためのもので、ESLint側の重複機能をオフにします。React拡張を作成する場合は、Reactバージョンの設定をしないと警告を毎回見ることになるでしょう。 
+
+先ほどの初期化でほとんどのツールはインストール済みですが、Prettierとの連携用設定のパッケージは入っていないので追加します。
+
+.. code-block:: bash
+
+   $ npm install --save-dev eslint-config-prettier
 
 .. code-block:: js
    :caption: .eslintrc.js
@@ -284,6 +304,7 @@ ESLintの設定は、機能を追加するプラグインと、設定をまと
        rules: {
            'no-console': process.env.NODE_ENV === 'production' ? 2 : 0,
            '@typescript-eslint/explicit-module-boundary-types': 0,
+           'no-unused-vars': ['error', { argsIgnorePattern: '^_' } ]
        },
        settings: {
            react: {
@@ -364,6 +385,31 @@ Visual Studio Codeの設定
 
     以前は次に紹介するPrettierをESLintの一部として組み込んで利用することがデファクトスタンダードでした。Lintのエラーもしかし、その場合、チェックのたびにコードをフォーマットしなおし、それからパースして文法のチェックが実行されます。ESLintはコーディングの中でなるべくリアルタイムに結果をプログラマーに提示する方が開発の流れが途切れずに品質の高いコードが量産できます。現在はフォーマッターとこのESLintは同期させないで個別に実行させるのが推奨となっています。
 
+ESLintの警告と特定の行だけ無効化する
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ESLintの警告はなるべく適用したいが、特別なコードだけ除外したいことがあります。逆をやることは基本的になく、なるべく厳しくして、特別な箇所だけ緩めてあげるのが一番やりやすい方法でしょう。例えば、コードジェネレータで生成したコードの警告を無効化したり、変数名の規則はcamelCaseだが、サーバーのレスポンスのみsnake_caseを許容したい場合などがあります。
+
+.. code-block:: ts
+   :caption: 特定の行のみ無効化
+
+   const { status_code } = await res.json(); // eslint-disable-line camelcase
+
+   // eslint-disable-next-line camelcase
+   const { status_code } = await res.json();
+
+
+.. code-block:: ts
+   :caption: 特定のブロック内のみ無効化
+
+   /* eslint-disable camelcase */
+
+   const { status_code } = await res.json();
+
+   /* eslint-enable camelcase */
+
+これ以外に、.eslintignoreでファイルごと無効化する方法など、さまざまな方法があります。
+
 テスト
 -----------
 
@@ -400,7 +446,7 @@ scripts/testと、jestの設定を追加します。古い資料だと、transfo
      ]
    };
 
-最後にESLintの設定です。これでJest固有のキーワードがエラーならなくなります。
+JestでもMochaでも、人気のフレームワークはテスト専用の関数などが定義されているものとしてテストコードを記述していきますが、これらの関数があるかどうかは、ESLintからは見えません。ESLintにさまざまな設定を追加することで、Jest固有のキーワードでもエラーがでなくなります。
 
 .. code-block:: json
    :caption: .eslintrc.js
@@ -422,40 +468,6 @@ scripts/testと、jestの設定を追加します。古い資料だと、transfo
    }
 
 
-Visual Studio Codeの設定
---------------------------------
-
-Visual Studio Codeでフォルダを開いたときに、eslintの拡張と、editorconfigの拡張がインストールされるようにします。\ ``.vscode``\ フォルダにファイルを作ることで、プロジェクトのソースコードと一緒に、プロジェクトの共有設定を共有できます。同じ拡張機能を入れてもらって、コードチェックなどのクオリティを統一し、コードインテグレーション時に無駄な調整をしなくて済むようにできます。ここではついでにコードのスペルチェックの拡張機能も入れておきます。
-
-.. code-block:: json
-   :caption: .vscode/extensions.json
-
-   {
-     "recommendations": [
-       "dbaeumer.vscode-eslint",
-     ]
-   }
-
-この設定はこのJSONを書いても良いですし、拡張機能のページで該当する拡張機能を開いてから、コードパレットで\ ``Extensions: Add to Recommended Extensions (Workspace Folder)``\ を選択すると追加されます。
-
-.. figure:: images/add-to-recommendation.png
-
-   拡張機能をプロジェクト推奨に設定
-
-ファイル保存時にeslint --fixが自動実行されるように設定しておきましょう。これでVisual Studio Codeを使う限り、誰がプロジェクトを開いてもコードスタイルが保たれます。Visual Studio Codeのeditor.codeActionsOnSaveは、files.autoSaveがafterDelayのときは効かないので、offに設定しておきます。
-
-.. code-block:: json
-   :caption: .vscode/settings.json
-
-   {
-     "editor.codeActionsOnSave": {
-       "source.fixAll.eslint": true
-     },
-     "files.autoSave": "off"
-   }
-
-ファイルを保存してみて修正されるか試してみましょう。もしされない場合は一度コマンドラインから実行してみてください。拡張で設定されているパッケージが足りない場合などはエラーが発生します。
-
 .. todo:: tsdocとかドキュメントツールを紹介
 
 .. todo:: eslintやテストの書き方の紹介

browserenv.rst

@@ -0,0 +1,34 @@
+ブラウザ環境
+==========================
+
+今も昔も、ウェブフロントエンドが今のJavaScript/TypeScriptの主戦場です。本章ではそのウェブフロントエンドの環境について紹介します。
+
+現在、メジャーなウェブフロントエンドのフレームワークというと、React、Vue.js、Angularです。本書で取り上げるのはReactとVue.jsです。React以外にReactをベースにした統合フロントエンドフレームワークとなっているNext.jsも取り上げます。Angularは2以降からTypeScriptに書き直されて、TypeScript以外では書けなくなり、最初からTypeScriptが有効な状態でプロジェクトが作成されるため、説明は割愛します。
+
+本章では、それぞれの環境の共通部分について紹介します。
+
+ウェブアプリケーションにおけるビルドツールのゴール
+-----------------------------------------------------
+
+JavaScriptでビルドといっても、いろいろなステップがあります。
+
+1. TypeScriptやBabelを使って、ターゲットとなるバージョンのJavaScriptに変換
+2. SCSSとかPostCSSを使ってブラウザにない機能を使って書かれたCSSを素のCSSに変換
+3. webpackなどを使って、1つのJavaScriptファイル、もしくは遅延ロードをするJSファイル群を生成
+
+実際には綺麗にステップが分かれることはなくて、バンドラーがimport文を追跡しつつファイルを探し、.tsを見つけてはTypeScriptで処理して（コンパイル）、コード中にSCSSを見つけてはSCSSの処理系に投げて、一つのファイルにまとめる（バンドル）・・みたいな工程を行ったりきたりしながらビルドします。以前は、これにJake、Gulp、Gruntなどのタスクランナーも組み合わせてやってましたが、今はwebpack単体にts-loaderなどを組み合わせる感じで一通りできます。webpackがシェア80%で一強です。
+
+しかし、ファイルを集めてきてコンパイルしつつ1ファイルにバンドルし、必要に応じてminify化してサイズを小さくするといったタスクは、比較的重い処理です。そのため、ウェブのフロントエンドのビルド環境は、開発者のストレスを軽減するために、さまざまな機能を備えてきました。
+
+* バンドルツールは毎回ファイルを読み込むのではなく、メモリに常駐し、変更されたファイルだけすばやく読み込んでバンドルを完成させる
+* ブラウザに対して、変更検知を伝えるコードを差し込んでおくことで、すばやくブラウザをリロードして最新のファイルを読み込む仕組み
+
+これらを実現するのが開発サーバです。開発サーバーはHTTPサーバーとして起動し、JavaScriptやHTML、CSSを配信するサーバーとしてブラウザからは見えます。その裏では、ファイルシステムのソースコードを監視し、変更があったら即座にビルドをして動作確認までのリードタイムを短くします。それだけではなく、その開発中のウェブサイトを見ているブラウザに対して強制リセットをしかけたり（ホットリロード）、起動中にJavaScriptのコードを差し替えたり（ホットモジュールリプレースメント）といったことを実現します。また、TypeScriptだけではなく、CSSでも、事前コンパイルでコーディングの効率をあげる方法が一般化しているため、この設定も必要でしょう。
+
+この分野では数多くのツールがあります。スキルのある人は自分の好みや要件に合わせてツールを選択すると良いでしょう。TypeScriptの対応についても、最初から対応していたり、後からプラグインで拡張など、いろいろなものがあります。
+
+webpackは細かくカスタマイズできますし、豊富な開発リソースで頻繁にリリースされています。ツリーシェイキングといった不要なコードを除外してサイズを小さくする機能にいち早く取り組んだり、業界をリードしています。困った時に検索すると情報も多く出てきます。一方で、TypeScript対応で開発サーバーやCSS対応など、機能を足していこうとすると設定やプラグインが増えていきます。特に、ReactのJSX構文を利用する場合は、バンドラーの処理の前段でTypeScriptをJavaScriptに変換したあとにBabelを使い、最後にバンドラーで1ファイルや複数ファイルにまとめるなど、ビルドのパイプラインが多段になりがちです。ReactやVueの環境構築ツールやNext.js、Nuxt.jsなどはwebpackを内包して、少ない設定の量で一定の機能を備えたビルド環境を整えてくれます。本書でも、webpackそのものを紹介することはしませんが、これらのツールの紹介をします。
+
+他にも数多くのバンドラーがあります。webpack以降に出てきたものの多くは設定が少ない、あるいは設定ファイルが不要（ゼロコンフィギュレーション）を売りにしたものが数多くあります。Rollupは人気のあるバンドラーで、TypeScriptを使うにはプラグインが必要ですが、そうでないのであれば設定がほとんど必要ありません。RollupをベースにTypeScriptサポートを最初から組み込んだmicrobundleもあります。HTMLやCSSのビルドもできて開発サーバーも全てついてくるオールインワンでビルド速度を重視したParcelや、Go製でビルド速度に特化したesbuildもあります。一方で、カスタマイズが必要なので最初からカスタマイズ前提でCLIを提供しないFuseboxなどもあります。
+
+

complex.rst

@@ -264,6 +264,8 @@ C言語由来のループは昔からあるものですがループ変数が必
 速度の面で言えば、旧来の ``for`` ループが最速です。 ``for ... of`` や ``forEach()`` は、ループ1周ごとに関数呼び出しが挟まるため、実行コストが多少上乗せされます。
 といっても、ゲームの座標計算で1フレームごとに数万要素のループを回さなければならない、といったケース以外ではほぼ気にする必要はないでしょう。
 
+``forEach()``\ 、\ ``map()``\ などのメソッドは関数型プログラミングの章でも紹介します。
+
 iterableとイテレータ
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -376,6 +378,17 @@ TypeScriptを使っていると、ES5への出力の場合型情報を見て、
 
 TypeScriptを使うと、型情報がついて実装が簡単になるだけではなく、速度のメリットもあります。
 
+配列のようで配列でない、ちょっと配列なオブジェクト
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TypeScriptがメインターゲットとしてるブラウザ環境では、配列に似たオブジェクトがあります。HTMLのDOMを操作したときに得られる、\ ``HTMLCollection``\ と、\ ``NodeList``\ です。前者は\ ``document.forms``\ などでフォームを取得してきたときにも得られます。どちらも\ ``.length``\ で長さが取得でき、インデックスアクセスができるため、一見配列のようですが、配列よりもメソッドがかなり少なくなっています。\ ``NodeList``\ は\ ``forEach()``\ はありますが、\ HTMLCollection``\ にはありません。\ ``map()``\ や\ ``some()``\ はどちらにもありません。
+
+どちらもイテレータは利用できますので、次のようなコードは利用できます。
+
+* ``for .. of``\ ループ
+* スプレッド構文
+* ``Array.from()``\ で配列に変換してから各種配列のメソッドを利用
+
 オブジェクト
 ---------------------