HMRでファイルを変更してからブラウザで変更が反映されるまで

HMR(Hot Module Replacement)ってみなさん使ってますか？

HMRは、webpackの提供する仕組みで、ページの再読み込み無しで、モジュールの交換・追加・削除をアプリケーションの動作中にブラウザに適用してくれる開発ツールです。

ブラウザをリロードしなくても変更したモジュールだけが更新されるし、開発の時間が節約できて便利ですよね！

最近HMRってどうして変更したモジュールだけが更新されるのかなあって考えたことがあったのでまとめてみました。

HMRの仕組み

HMRでファイルを変更してからブラウザで変更が反映されるまでの流れは以下のような仕組みになっています。

Webpackのコア、プラグインライブラリ Webpack-dev-server関連のライブラリ HMRライブラリ(react-hot-loader、style-loader等) 変更したファイル(js, css等) アプリ(ブラウザ上で確認できるもの)

1~2. ファイルの変更

webpackはファイルの変更を監視しています。 ファイルを変更すると、Webpackは変更を取得し、HotModuleReplacementPluginに通知します。

3. manifestとchunkの作成

WebpackはHotModuleReplacementPluginを使用して manifestファイル（変更されたモジュールのリストを含むJSON）と updated chunkファイル（実際の変更情報を含むjs）を生成します。

4. Webpack-dev-serverに変更を通知

WebpackはWebpack-dev-serverに変更を通知します。

5. Webpack-dev-server/clientに変更を通知

Webpack-dev-serverは、WebSocketを介して「無効な」通知を送信することで、Webpack-dev-server/clientに変更を通知します。

Webpack-dev-server/clientは、アプリが最初にhot/dev-serverライブラリに読み込まれたときに取得した初期ハッシュ（例：c6202ec89ecd4e669b46）をWebpack-dev-serverに送信します。

Webpack-dev-server/clientとは？

WebSocketを介してブラウザーで実行されているJSファイル。
Webpack-dev-server関連のライブラリ。

6~8. manifestファイルのダウンロード

Webpack-dev-server/clientはhot/dev-serverに変更を通知し、hot/dev-serverはWebpackによって挿入されたJSONP runtimeを呼び出して、3で生成したmanifestファイルをダウンロードします。

manifestファイルには、chunkに関する詳細が含まれています。例えば、ファイル名はc6202ec89ecd4e669b46.hot-update.jsonで、中身は以下のようになります。

{h: "0355e4eec902c32b2d0b", c: {0: true}}

9. updateファイルのダウンロード

JSONP runtimeはmanifestファイル内に含まれる情報を使用して、すべてのupdateファイル(js)をダウンロードします。

変更に関する情報が含まれていて、DOMに追加されて実行されます。

updateファイル(js)の中身は以下のような感じ。

webpackHotUpdate(0,{

/***/ 116:
/***/ (function(module, __webpack_exports__, __webpack_require__) {

"use strict";
Object.defineProperty(__webpack_exports__, "__esModule", { value: true });
/* harmony import */ var __WEBPACK_IMPORTED_MODULE_0_react__ = __webpack_require__(85);
/* harmony import */ var __WEBPACK_IMPORTED_MODULE_0_react___default = __webpack_require__.n(__WEBPACK_IMPORTED_MODULE_0_react__);

//# sourceMappingURL=0.c6202ec89ecd4e669b46.hot-update.js.map

10. HMR runtimeの呼び出し

updateファイルは、モジュールID（上記の例ではmodule id 116）と変更内容を使用してHMR runtimeを呼び出します。

11. loaderにを変更を委任

HMR runtime自体は、変更を適用する方法を知らないので、Reactであればreact-hot-loader、cssであればstyle-loaderなどの対応するloaderにを変更を適用してもらうようにお願いします。

12. モジュールの更新

変更の適用に問題(構文エラー等)がない場合は、モジュールが更新されます。 ここでやっとモジュールファイルを変更してブラウザ上で変更の確認することができるのです。

もし問題があれば、hot/dev-serverにエラーが通知されます。

HMRの変更を実際に見てみる

次は、実際にHMRを使うとブラウザではどのような動きになっているのか見ていきます。

さくっと動きを確認したいのでReact Hot Loaderのboilerplateを使って実際にHMRで変更したときの流れを見てみることにします。

1. Webpack-dev-serverを起動

まずは、以下からReact Hot Loaderのboilerplateを落としてきてWebpack-dev-serverを立ち上げます。

github.com

Webpack-dev-serverを起動するとコンソール上に以下のようなログが表示されます。

[HMR]はWebpack/hot/dev-serverのログ

[WDS]はWebpack-dev-serverのログ

になります。

2. ファイルを変更

src/containers/Root.jsを変更してみます。

とりあえずHello React Hot Loader!→Hello World！に変更してみました。

import React from "react";

const Root = () => <div>Hello World！</div>;

export default Root;

3. サーバーとクライアントでのやり取り

ファイルの変更後、dev toolのNetworkタブのWebSocket欄を確認するとハッシュを送信したりしてることが分かります。 webpack-dev-serverは、WebSocketを介してファイルの変更についてクライアントと常に通信しているみたいです。

4. 変更をアップロード

次にdev toolのNetworkタブ欄を確認すると、webSocketを介して得た現在のハッシュ(001efdfaf0c0e6150d7f)を使用して、manifestファイル（001efdfaf0c0e6150d7f.hot-update.json）をダウンロードしていることが分かります。 また、manifestファイル内に含まれる情報を使用して、updadeファイル(0.001efdfaf0c0e6150d7f.hot-update.js)をダウンロードしていることも分かります。

manifestファイル（001efdfaf0c0e6150d7f.hot-update.json）の内容は以下。

5. 変更内容を更新

updadeファイル(0.001efdfaf0c0e6150d7f.hot-update.js)を確認するとファイル内にwebpackHotUpdate関数があり、 このwebpackHotUpdate関数を呼び出すことでHMR runtimeに変更内容が渡されます。

HMR runtimeは、この変更内容をReact Hot Loaderに渡し、変更内容が更新され変更内容がブラウザで確認することができます。

updadeファイル(0.001efdfaf0c0e6150d7f.hot-update.js)

まとめ

普段何気なく使ってるHMRですが、改めてHMRって何だろうって考えたときにリロードしなくても変更したモジュールだけ変更できるのってすごくない…!! って思ったのがきっかけで仕組みを調べてみました。

仕組みを少し理解できたのでWebpackの設定周りが理解しやすくなった気がしています。

参考

Hot Module Replacement | webpack

Webpack & The Hot Module Replacement - rajaraodv - Medium

2019-09 → 2020-03

仕事について

去年の9月にSmartHRのフロントエンドエンジニアとして転職をしました。 3月で入社して6ヶ月になるので、少し振り返ってみようかなあっと思って書いています。

入社してからの3ヶ月

はじめてのお仕事は、比較的小さいアプリのフロントエンドリニューアルのお仕事。

既存のrailsアプリにReact, TypeScriptを入れて、作り直しました。

私にとっては、はじめてのReact, TypeScriptでとても刺激のある3ヶ月でした。

やったことは、

既存railsアプリにWebpackを入れてフロントエンドを切り分けた

既存のRailsアプリにReact, TypeScirptを入れてフロントエンドリニューアルをする際に、最初に悩んだのが、 Reactを入れる、動く環境を作るためにはどうしよう？

でした。 　

1. webpackerをいれる
2. 自分でwebpackを用意する
3. 上記以外の何か別の何かの方法...?

上記3つの方法を検討していたのですが、

• フロント部分の細かな設定がしたい
• webpackerだと
  • 細かい設定が大変
  • webpackerの学習コストやwebpackのバージョンアップについていけないことが辛い
• 他のプロダクトと設定を統一したい

という理由から、自分でwebpackを用意し、フロントエンドを切り分けることにしました。

React, TypeScriptで作り直す

はじめてのReact, TypeScriptだったので、慣れるまではとても時間がかかりました。。。(しんどかった…)

苦労したところは、はじめてやることなので時間がかかるでした。

なので、

• React tutorial
• りあクト！ TypeScriptで始めるつらくないReact開発 第2版
• 実践TypeScript

↑の本を読んだり、先輩に教えて貰ったり、ちょっと早めに出社して勉強したりしながらやっていました。

UIのコンポーネント化

もともとスタイルははscssで書かれていたのですが、フロントエンドリニューアルにあたって、Styled Componentsを使用することにしました。

Reactはコンポーネント・ベースでUI開発することに特化したJavaScriptライブラリなので、個人的にはコンポーネント単位でcssを管理したく、コンポーネント単位でスコープが生成されるStyled Componentsで書き直すことにしました。

他のプロダクトもStyled Componentsなので、統一したかったっていうのも理由のひとつです。

UIのコンポーネント設計部分はAtomic Designを採用しました。 フロントエンドリニューアルするプロダクトは開発人数が少ないため、UI設計の共通認識が持ちやすそう、またメンテナンスしやすいUI開発がしたいと思い採用しました。

こちらもはじめてのStyled Components、Atomic Designだったので、

• styled-components docs
• Atomic Design

↑のdocsを読んだり、Atomic Designの本を読んだりしてました。

Ruby on Rails

フロントエンドのリニューアルなので、あんまりバックエンド部分は触ることはなかったのですが、 どうしても修正しないといけない箇所があったりで、コードを読んだり、修正したりしてました。

railsはあんまり得意ではなく… 事前にその話をしていたので、先輩がすぐに助けてくれたり、丁寧に教えてくれたりしたおかげで少しだけrailsのこと理解できた気がします。（たぶん）

入社してからの4ヶ月目~今

今年に入ってから、新しいチームに配属になりました。

以前やっていたプロダクトよりも大きいプロダクトで技術スタックはRails, React, TypeScript、 そして半年ほど専任のフロントエンドエンジニアがいなかったチームです。

フロントエンドエンジニアの人数が少ないので、チームのフロントエンドエンジニアは私一人だけです。

私一人で大丈夫かな、私で大丈夫なのかなって不安がたくさんあったのですが、 チームのみんなは、困ってるとすぐに助けてくれたり、いっしょに悩んでくれたり、とても心強く、楽しく開発できています。

今のチームに入ってからやったこと＆やっていることは、

tslintをやめた

TSLintは現在非推奨になっています。

なので、TSLintはやめて、eslintに変更しました。

既存のUIをSmartHR UIに変更

SmartHRには共通のコンポーネントライブラリSmartHR UIがあります。 また、SmartHRにはたくさんのプロダクトがあり、プロダクトによっては少しUIが違っていたり、カラーが違っていたりしています。 プロダクト間でのUIの統一をし、多くの人に使いやすいと思ってもらいたいので、既存のUIをSmartHR UIに変更しています。

（まだ途中で、置き換え作業中です。）

フロントエンドの問題点の洗い出し

しばらく専任のフロントエンドがいないプロダクトだったので、 フロントエンド部分のコードを良くしていきたい、底上げをしたいと思っています。

フロントエンドのコードに関して

• どんな問題点、課題があるのか、
• 将来的にどうしたいのか

を洗い出しました。

↑を踏まえてフロントエンドの技術顧問の方に相談したり、先輩に相談したり、 チームのみんなにも共有して協力してもらったりしています。

jsのts化

もともとjsで書かれていたのですが、以前チームにいたフロントエンドの先輩が半分以上TypeScriptにしてくれていました。

ですが、まだjs部分が残っています。。。

堅牢性をあげたいので、早くts化を終わらせたいなあと思っているので、ちょっとずつTypeScriptにしようと頑張っています。

ビルド周りの改善

以下は、私がやったことではなく技術顧問の方がやってくださりました。

以前はTypeScriptのコンパイル部分をawesome-typescript-loaderを使用していたのですが、ts-loaderに変更しました。 変更することで、コンパイルの速度が速くなりました。

また、ESModulesのままwebpackに渡すようにしてTreeShakingを有効にしました。

これで本番ビルドのファイルサイズが削減されました。

// tsconfig.json
{ 
  "compilerOptions": {
    "target": "es5",
    "module": "esnext",
    "sourceMap": true,
    ...
    ...
    ...

TypeScriptコードのimport文とexport文がコンパイラによってCommonJSとして変換されるため、Tree Shakingの効果を得るためには明示的にES Modulesをコンパイルオプションで指定するみたいです。

上記2つは、技術顧問の方にPRを出していただいたのですが、私自身ビルド周りが詳しくなく…勉強になりました！

振り返り

半年を振り返ると、はじめてなことばかりで大変だったけど、出来ることが増えて嬉しい気持ちとやりがいがあります。

今やってるプロダクトのフロントエンドが良くなっていくのを感じる度に、私のフロントエンド力も一緒に成長している気持ちになっています。

入社して半年がたち、このままこのプロダクトと一緒に成長していけたらなあ、前職、現職含めお世話になった人にお仕事で恩返しができたらなあ、と日々思いながらお仕事をしています。

2019年振り返り

2019年を

• WORK
• STYDY
• PRODUCT
• BLOG
• BOOK
• MUSIC

で振り返ります。

WORK

お仕事は上手くまとめられなかったので月ごとに簡単にまとめます。

1月

悩み事が多かった気がする。

2月

辛いことがありました。
辛いこともあったけど、嬉しい言葉をかけて貰えたのも2月でした。

3月

UI/UXチームは2人で開発してたけど、webチームとwebメッセージ開発を始める。
先輩と朝勉強をはじめた。
先輩との勉強で一番印象に残ってるのは、
”webはHippy”

4月

きちんとテストすることの大切さを学んだ4月。
web-sdkのリリースを先輩といっしょにやった。
朝活も続いてる。

5月

チーム解体。スクラムの導入。Lessの勉強。
環境の変化に対応するのに大変だったけど、チームのメンバーは最高だった。

6月

sprint planningでのTaskの分割が上手くできない。分からない。
サーバーサイドもインフラもフロントエンドも何も分からない…

7月

頑張れなかった。
会社を辞めた。
何もかも自信がなくなった。
憧れてるエンジニアの人と面談をした。誕生日の日だった。
ブログを読んでくれたり、頑張ってるのを見てくれてた人がいるんだと嬉しい気持ちになった。
もう少しだけ頑張ろうと思った。

8月

ゆっくりすることにした。
音楽を聴いたり、花を飾ったり、本を読んだり、ご飯をちゃんと作るようにした。
夕方よく散歩をした。時々見かける子供とお母さんの会話をぼんやり聞いたりした。

9月

転職した。
はじめて設計含めてフロントエンド開発することになった。
ReactもTypeScriptもはじめてやる。
既存railsアプリにreactを導入した。
webpackerいれるか考えたりした。（いれなかった）

10月

サーバー側のデータをフロントでどうやって取得しようか悩んだりした。
form送信できない…CSRFトークンとは？ってなった。
Smart HR UIにselect boxコンポーネントのPRを出した。嬉しい。

11月

入社後、なんとなくReactとTypeScriptを先輩のコードを参考に書いてたけど、
これじゃだめだ！と思って、朝活を始める。
TypeScriptの勉強を毎日することにした。
少しずつ会社の人に慣れてきた。

12月

先輩が設計に関してPRを出してくれた。とても勉強になった。
リリースまで12月までにできなかったけど作りきった。
自信になった。
少しずつ会社の人に心を開いてきた。

STUDY

• ブラウザの仕組み
• web
• React
• TypeScript
• Atomic Design
• スクラム, Less
• (テスト)
• (Ruby)
• (Ruby on Rails)

今年は、ブラウザについて勉強しました。
もともと仕組みが分からないともやもやして先に進めない性格なので、
ブラウザについて勉強したのは、とても良い経験になったように思います。

ブラウザの仕組みで一番好きなのはParse（構文解析）の部分ですって話を先輩にすると the-super-tiny-compilerを教えてくれたので、コードリーディングしたり写経したりしました。

あとは、テスト技法を少しだけ学んでみたり、React、TypeScriptに挑戦してみたり、Atomic Designについても勉強してみたり。です。

来年は、興味のある分野についてもっと勉強していき、自分の強みを見つけることができたら、なんて思ってます。

PRODUCT

• the-super-tiny-compiler.js
• cidermitaina.github.io
• TEA PAGE

the-super-tiny-compiler.jsを写経したものをブラウザ上で使えるように作ってみたり、
ReactとTypeScriptに慣れたいので、練習のためにReactとTypeScriptでTEA PAGEを作ったり、ポートフォリオを作り直したりしました。

Reduxを使ったアプリを作りたいなあと思ってるのですが、サーバー構築に対して苦手意識があるので、来年はその辺りも含めて何か作ってみたいです。

BLOG

12本書きました。（その内1本は音楽について）

以下の3つは書いてて楽しかったブログ。

• はじめてのコンパイラ
• webpagetest.orgでGoogle MAPを計測
• Webを見ているときに起きていること

今年は、Web、ブラウザについての記事を多く書きました。 去年は15本書いているのですが、内容的には濃い内容を今年は書いている気がするので、来年もこの調子でアウトプットしていきたいです。

BOOK

技術書

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webフロントエンド ハイパフォーマンス チューニング

ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ポートとソケットがわかればインターネットがわかる――TCP/IP・ネットワーク技術を学びたいあなたのために (Software Design plus)

Atomic Design ~堅牢で使いやすいUIを効率良く設計する

実践TypeScript ~ BFFとNext.js&Nuxt.jsの型定義~

booth.pm

小説

トニオ・クレエゲル (岩波文庫)

メルヒェン (新潮文庫)

星の王子さま (新潮文庫)

第七官界彷徨 (河出文庫)

道をひらく

買ったけど読んでない＆読みたい

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術

「実践ドメイン駆動設計」から学ぶDDDの実装入門 (CodeZine Digital First)

夜と霧 新版

ささやかだけれど、役にたつこと

かげろうの日記遺文 (講談社文芸文庫)

今年はけっこう本を読んだ気がします。
就活してたときに、説明会でもらった道をひらくって本、改めて読むととても滲みました。

ヘッセのアヤメという短編が今年の一番です。

MUSIC

open.spotify.com

open.spotify.com

open.spotify.com

open.spotify.com

www.youtube.com

www.youtube.com

今年はThe World Will Tear Us Apartという京都のバンドのアルバムが冬にリリースされました。
大学生の頃からずっと待っていたのでなんだか感慨深いです。

個人的にDIIVの新しいアルバムが衝撃でした。（良い意味で）

TO 2020

今年は本当に辛かったです。
辛かった分、得たことも多かった一年のように思います。

辛かったこと、得たこともしっかり受け止めて来年もまた少しずつ頑張れたらいいなあ、と思っています。

来年は自分の得意領域を見つけ、深堀りして行ったり、成長を実感できるような年にしていきたいです。

では、2020年も宜しくお願いします。

実践 TypeScriptの読書MEMO1

最近、実践 TypeScriptを読んでいるので読書メモです。

実践TypeScript ~ BFFとNext.js&Nuxt.jsの型定義~

私の知らなかったことをたくさん書いてます。

どんな本

• TypeScript特有の知識を体系的に学ぶための１冊
  • 集中してTypeScriptの型定義を深く学べる
• 1部は基礎知識、2部は理解を深める
  • 2部は実践的にJavascriptフレームワークやライブラリ（React、Vue.js等）におけるTypeScript の導入
• TypeScriptを導入するメリット
  • 分割されたモジュール同士の依存関係を担保する
  • 型システムが、バックエンドからフロントエンドの末端のviewまで一環して不整合ないデータの橋渡しを実現する

目的

• TypeScriptの型定義きちんと理解したい
  • 型定義ははじめてなので…
• 最終的にTypeScriptを実践的に使えるようになりたい
• 先輩のTypeScriptのコードをちゃんと理解できるようになりたい
• 4章5章をちゃんと読んでTypeScriptのコンパイルエラーの解決慣れしたい
  • コンパイルエラーの解決に時間がかかってしまう…

1. 開発環境と設定

1-1. tsconfig.json

TypeScriptコンパイラーの設定ファイル。 tsc --initで作成

tsconfig.json

{
  // teconfig.jsonの初期値
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true
}

target

トランスパイル後のECMAScriptのターゲットバージョン。

• es5
• es2015
• esnext

module

コード生成モジュールを指定

• commonjs
• amd
  • define()に配列でモジュール名を指定する

strict

型の厳密さを一括して指定

一括で有効になるのは以下の指定

• noImplicitAny
• noImplicitThis
• alwaysStrict
• strictBindCallApply
• strictNullChecks
• strictFunctionTypes
• strictPropertyInitialization

1-2. 型宣言ファイルの出力

関数定義などの型を通達するために、型宣言ファイル(.d.ts)が利用できる

.d.tsいつ使うんだろう🤔

• 型情報が消えしまう
• .d.tsは型定義が分かる
• JavaScriptで書かれたライブラリには型情報がない…
• ライブラリ等で使うときは型定義ファイルがあれば、みんなが幸せになれる

1-3. ライブラリの型定義を利用する

npmで配信されているライブラリには、TypeScriptの型定義が存在するものとしないものがある。

DefinitelyTyped

TypeScript型定義ファイル（dts）を用意していないJSライブラリのための型定義ファイル集 @typesで始まるパッケージ

2. TypeScriptの基礎

TypeScriptのもっとも基本的な用語の呼称・利用方法についての章。

2-1. JavaScriptの課題

１. 引数に数値として扱うことのできない値を渡してしまいNaNが表示されてしまう

• 引数を型注釈で制約する

function expo2(amout: number){
  return amout ** 2
}

２. 計算の途中、数値が文字列に変換されてしまいNaNが返ってくる

• 関数戻り値に型注釈（アノテーション）を付与。明示的に戻り値を制約。型注釈と定義内容に型不整合がある場合はコンパイルエラーを得ることができる。

function fee(amount): number {
    return amount * 1.4
}

2-2. 基本の型

(私の知らなかった型をまとめてます。)

• tuple型
  • 固定数の要素がわかっている配列を表現できる
  • 配列の要素ごとに型が違うデータ型が定義できる。
    • let x: [string, number]
• any型
  • 型の不明な変数を扱うことがある場合に使用することで型チェックを無効にし、コンパイルを通過させる
  • TypeScriptの恩恵を受けることはできないので、できる限りany型が現れないコードを書き、型安全なプロジェクトを目指す。
• unknown型
  • any型に似ているが、型安全なanyを表したいときに利用する
• void型
  • any型の反対のようなもの。型が全くないことを表す。
  • 一般に、値を返さない関数の戻り値として利用
• never型
  • 発生し得ない値の型を表す
  • 返り値が無いことを表すvoid型とは異なり、そもそも関数が正常に終了して値が返ってくるということがあり得ない場合

function func(): never {
   throw new Error('Hi');
 }
 const result: never = func();

• object型
  • 非プリミティブ型
  • {}を使った型表現ではエラーを得ることができない

2-3. 高度な型

• Intersection Types
  • 複数の型を一つに結合する
• Union Types
  • Union Types（共用体）は複数の型のうち一つの型が成立することを示している。
    • let value: boolean | number | string
      • array型を含む要素をUnion Typesにする場合
    • let numberOrString: (number | string)[]
      • Nullable型を表現できる
    • let nullableString: string | null
• Literal Type
  • String Literal Types
  • 文字列に必要な正確な値を指定できる
  • let users: 'Taro' | 'Jiro'| 'Hanako' (Union Typesと併用)
  • Numeric Literal Types(数値リテラル)
  • Boolean Literal Types(真偽値リテラル)

2-5. アサーション

任意の型に変換することができる。

型アサーションは2種類の書き方がある。

• <変換したい型>値
• 値 as 変換したい型

let text: any = "this is a string";
let textLength: number = (<string>text).length;

let text: any = "this is a string";
let textLength: number = (text as string).length;

↑ 文字列の文字数を取得するために string に変換して length を呼び出している

<>ではJSXタグとの区別が曖昧になるため、非推奨

2-6. 列挙型

enumを使用すると、列挙型を定義できる。 列挙している属性以外が入ってくると怒ってくれる

3. TypeScriptの型安全

バグを減らすことはTypeScriptを導入する大きな理由の一つであり、

TypeScriptを使いこなすようになるほど、絞り込むという作業がバグを減らす上でいかに重要な作業かということに気づくらしい。

3-1. 制約による型安全

• アノテーションを用いると、引数や変数定義において、誤った値の代入を防げる。
• null, undefined
  • 早期return(ガード節、Type Guard)
• Weak Type
  • すべてのプロパティがオプショナルな型

3-2. 抽象度による型安全

• 抽象的な型は広く値を受け付けることができる
• 詳細な型は担保された制約の下で処理を安全に展開できる
• 抽象的な型・詳細な型がどのようなものであるかを理解し、抽象度をコントロールすることが必要
• キャスト
  • 変数の型を別の型へ変換すること
• ダウンキャスト
  • 抽象的な型から詳細な型を付与すること（互換性があるときのみ可能、互換性がない場合は成立しない）
• アップキャスト
  • 抽象度をあげる
• インデックスシグネチャ
  • 任意のプロパティを動的に追加することが可能
• 危険な型の付与
  • Non-null assertion
  • double assertion

4. TypeScriptの型システム

バグを減らすことはTypeScriptを導入する大きな理由の一つ。

TypeScriptを使いこなすようになるほど、絞り込むという作業がバグを減らす上でいかに重要な作業かということに気づくらしい。

4-1. 型の互換性

any型の互換性

• どんな型にも宣言・代入できる。
• any型は、どのように扱おうとも危険な型

unknown型の互換性

• unknown型は、どんな型の値も受け入れることができるTopTypeであり、型の中でもっとも抽象的な型。
  • any型とは異なり安全に扱うことができる型
• unknown型の値はどんな値なのか分からないため、できることが制限されている。 　- (任意の値を代入できる点はany型と同じ、型アサーション等が無いと利用できない。)

{}型の互換性

• 型に互換性がありため、いずれもコンパイルエラーにはならない。
• {}という型はオブジェクト以外も受け付けてしまう。(ただし、undefinedとnullはだめ)
• プリミティブ型は{}型のサブタイプ

5. TypeScriptの高度な型

Generics

• Genericsを用いると、型の決定を遅延できる。
• Genericsが割り当てられた型定義に対し、< >の内側に型指定をすることで、導かれる型推論を可変にできる。

基本的な付与

• Genericsを利用する型を宣言する場合、型名称に続いて<T>のようにT型をエイリアスとして指定する。
• 慣習的にT, U, Kなどの型エイリアス名称が利用されることが多い。

Genericsを利用する型の宣言

interface Box<T> {
    value: T
}

const box0: Box = { value: 'test' } // Error! Genericsを指定していない
const box1: Box<string> = { value: 'test' }
const box2: Box<number> = { value: 'test' }// Error! Number型ではない

実践TypeScriptの読書MEMO2に続きます。

2019 上半期 聴いたもの

2019年の上半期によく聴いた、印象的だった音楽について。

まず最初に、この半年に聴いた新譜の中でもこれはヤバすぎるな… と思ったのがいくつかあるので以下に。

youtu.be

open.spotify.com

ノルウェー出身19歳の宅録女子らしい。 dead girl in the poolという曲のタイトルで狂気的な印象を受けたけど、

「なんとも言えない不安な気持ちとか、自分は誰であるかというアイデンティティの揺らぎとか、そういった気持ちに根ざした恐怖感を表現したかった」

ということらしい。

open.spotify.com

知り合いに教えてもらった。 甘ったるい感じに歌う声が好きです。

open.spotify.com www.youtube.com

ここ最近で一番衝撃的な新譜でした。

言葉とサウンド（メロディ？音？）が究極に美しいです。 Everythingは特に綺麗。

open.spotify.com

高揚感に溢れます。

open.spotify.com

高熱でぼんやりしてるときって夢でよく京都での大学時代の夢を見るなあと思いながら聴いています。

最近聴いて印象的だったもの。

open.spotify.com

open.spotify.com

open.spotify.com

open.spotify.com

open.spotify.com

open.spotify.com

音楽は相変わらず毎日聴いているし、何か聴いていないときの方が少ないのではないかってくらい聴いています。

自分から何か探すことは減ってきていて、Spotifyが勧めてくれるおすすめの音楽を聴くことが多くなったかもしれないです。 あとは、今まで好きだったバンドの新譜とか、そういうものばかりを聴くことが多かったです。

2019年ではないけど、ここ最近で読んだ本、漫画についても。

草の花 (新潮文庫)

トニオ・クレエゲル (岩波文庫)

メルヒェン (新潮文庫)

星の王子さま (新潮文庫)

風立ちぬ・美しい村 (新潮文庫)

ノルウェイの森 (講談社文庫)

バースデイ・ストーリーズ (村上春樹翻訳ライブラリー)

SLAM DUNK 新装再編版 1 (愛蔵版コミックス)

あんまり、楽しい小説は読んでいなくて、言葉の綺麗な小説を探して読んでいました。

ヘッセはなぜか苦手意識があったけど、アヤメは本当に美しくて綺麗な話で... 好きな話のひとつになりました。

あとはスラムダンクを読みました。

ここ最近はこんな感じです。

なんだか疲れているような感じで、いろいろと立ち止まってみるのもいいのかもしれない。と思ったりする日々です。 ゆっくり音楽を聴いたり、ご飯を丁寧に作ってみたり、花を生けたり、好きなお茶を選んで淹れてみたり...

夏休みのつもりでのんびりしています。

夏休みが終わったら、また頑張れるだろうか。

アドレスバーにURLを打ち込んでページが表示されるまで

ブラウザを立ち上げてアドレスバーにURLを打ち込んでEnter押してからページが表示されるまでに (裏側で) 何が起こっているかわかる限り説明してみてください。

という問題に15分何も見ずに考えてみるというのを以前(2月くらい？)やってみたので、そのMEMOです。

予想

何もブラウザに関して勉強せず、15分考えてみた予想(結果)は以下です。 (すごくざっくりしてるので恥ずかしい...)

• アドレスバーに打ち込んだURLがサーバーに送られる
• サーバーがURLを受け取る
• サーバーがデータベース？データサーバー？にURLの情報を探しにいく
• 見つかったらサーバーがクライアント側にその情報を返す(その情報ってなんだろ？html、css、jsとか？)
• クライアント側、ブラウザが受け取り、htmlやcssなどをレンダリングする
• 表示

勉強後

あまりにも書けなかったことがショックだったので、

Webフロントエンド ハイパフォーマンス チューニング

を読んでブラウザのレンダリングの仕組みについて学んでみました。

勉強後、同じように15分何も見ずに考えてみた結果が以下です。

• アドレスバーにURLを打ち込む
• ホスト名をIPアドレスに変換した上でネットワークプロトコルを介して必要なリソースを取得
  • リソース→HTML、css、js、画像など
• まずはHTMLから読み込み、DOMツリーの構築をする
• DOMツリーの構築　(DOMツリーとはレンダリングエンジンが解釈できるようしたもの)
  • htmlファイルをもとに字句解析をしトークン列に
  • トークン列をもとに構文木に
• DOMツリーの構築中にcssやjs、画像の参照があれば読み込む
• cssをもとにCSSOMツリーの構築
• jsファイルをもとに字句解析
• トークン化
• 抽象構文木に
• コンパイル
  • javascriptエンジンが解釈できるように変換
  • よく使われているのがJIT
• javascriptの実行
  • CPU上で実行
• DOMツリーをもとにレイアウトツリー構築構築をする
• スタイルの計算
  • どのDOMにどのcssプロパティが当たるか計算
  • cssの詳細度の計算
• レイアウト
• レイアウト情報の計算をしレイアウトの作成（設計図みたいなもの）
  • レイアウト情報→margin,paddingなどの位置
• ペインティング
  • 2dグラフィックエンジン向けにRender Treeをもとに命令を作成
• ラスタライズ
  • レイヤーごとに描画
  • レイヤーはposition ,opacity,z-indexごとに
• レイヤーの合成
  • できたレイヤーを合成
• ブラウザに表示される

感想

最初は、

ブラウザを立ち上げてアドレスバーにURLを打ち込んでEnter押してからページが表示されるまでに (裏側で) 何が起こっているかわかる限り説明してみてください。

の問いに対してあまり書けなかったのですが、ブラウザのレンダリングの仕組みの勉強後、3倍くらいの量で書くことができました！ ブラウザに関する知識が身についた感触があります。

ブラウザに対して興味を持ったので、今後はネットワークやコンパイル、レイアウト、ラスタライズ等の自分の興味を持った分野に対して深掘りしていき、この問いに対しては定期的に考えてみたいなあと思っています。 (来年も同じ問いに対して考えて、書ける量を増やしていけたらなあ...)

毎日の小さなアウトプット

毎日こつこつアウトプットする習慣を作りたいと思っていたのですが、

小さなアウトプットを100日続けてみた感想

という記事を見かけて、私もTIL(Today I Learned) をやってみようと思ったので TILについて＆どのようにやっていくかを考えてみました。

WHY

• 何かを毎日アウトプットする習慣をつけたい。
• 毎日の気になったこと、覚えたこと、新しく気付いたこと、学んだことをどんな形でもいいからアウトプットしたかった。

TILとは

Today I Learnedの略。 Github上にTILというリポジトリを作成してそこに今日覚えたことを書いていく。 （githubで検索するとtilというリポジトリがけっこう見つかる）

塵も積もれば山となるみたいな感じ。

ref. https://qiita.com/sitmk/items/239335b4ed0c3c797add ref. https://syossan.hateblo.jp/entry/2016/02/16/144305

実際のリポジトリ

https://github.com/jbranchaud/til

カテゴリごとにディレクトリを作成し、勉強した内容などをmdファイルでまとめている。

HOW

https://aloerina01.github.io/blog/2019-03-22-1

↑を参考に

• 何か読んだり考えたりしたらそのログをIssueに残す
• ブログに書くほどじゃないネタを雑にIssueにまとめる
• ちょっとした実装を日付毎のディレクトリにCommitする

という感じでやっていく。

毎日アウトプットする習慣を作ることが目的なのでブログに書いてある通りかなりハードルを低くして、やっていく。

github.com

5月中旬からはじめて、毎日続いているわけではないのですが...

毎日コツコツ小さなアウトプットをしたいと思っているのでこのブログで意思表明です。。。