ng-sake #9

1. HttpClientModule
移行から新機能まで

2. 自己紹介
● 武田 憲太郎 @KentarouTakeda
● ヒトメボ - ヒトメボレした時、押すスイッチ
○ PostgreSQL,PostGIS, 国土数値情報
● 金持ち父さんのキャッシュフローゲーム
○ AngularJS , PHP, Node
● ソシャゲ・コンシューマーゲーのインフラ
○ ………
○ 管理画面で Angular 大活躍
あくまで本業はサーバサイド

3. HttpClientModuleへの移行
以下の条件を満たせば
● 正常時のサーバからのレスポンスの形式がjsonであること。
● subscribe()の開始時点でObjectに変換していること。
基本的に移行は簡単！

4. 移行の概要
● Angular 4.3への移行
● HttpClientModuleインポート
● HttpClientの利用
● HttpModuleの削除

5. Angular 4.3への移行
定期的に npm update していれば既に4.3になっているはず
$ npm list --depth 0 | grep @angular/
├── @angular/animations@4.3.3
├── @angular/cli@1.2.7
├── @angular/common@4.3.3
├── @angular/compiler@4.3.3
├── @angular/compiler-cli@4.3.3
├── @angular/core@4.3.3
...

6. HttpClientModuleのimport
src/app/app.module.ts
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { HttpModule } from '@angular/http';
+import { HttpClientModule } from '@angular/common/http';
import { AppComponent } from './app.component';

7. HttpClientModuleのimports
src/app/app.module.ts
],
imports: [
HttpModule,
+ HttpClientModule,
BrowserModule
],
providers: [],

8. HttpClientの利用
src/app/app.component.ts
import { Component, OnInit } from '@angular/core';
import { Http } from '@angular/http';
+import { HttpClient } from '@angular/common/http';

9. HttpClientの利用
src/app/app.component.ts
constructor(
- private http :Http,
+ private http :HttpClient,
) { }
● 上の例ではいきなり差し替えている。
● 段階的に移行する場合はプロパティ名を変えて共存。

10. HttpClientの利用
src/app/app.component.ts
this.http.get(url)
- .map(res => res.json())
.subscribe( res => {
.....
});
リクエストの返却がResponseからObjectに！

11. Httpの削除
src/app/app.component.ts
import { Component, OnInit } from '@angular/core';
-import { Http } from '@angular/http';
import { HttpClient } from '@angular/common/http';
import 'rxjs/add/operator/map';
import 'rxjs/add/operator/catch';

12. HttpModuleの削除
src/app/app.module.ts
imports: [
- HttpModule,
HttpClientModule,
BrowserModule
],

13. HttpModuleの削除
src/app/app.module.ts
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
-import { HttpModule } from '@angular/http';
import { HttpClientModule } from '@angular/common/http';
import { AppComponent } from './app.component';

14. packageも削除可能
package.json
"dependencies": {
"@angular/core": "^4.0.0",
"@angular/common": "^4.0.0",
- "@angular/http": "^4.0.0",
...
}

15. default as JSON

16. 型の指定
subscribe()に渡されるレスポンスの型はObject
this.http.get(url).subscribe( res => {
console.log(res['foo']); // OK
// console.log(res.bar); // Property 'bar' does not exist on type 'Object'
});
プロパティを持たないので foo.bar 形式でアクセス出来ない

17. 返却型の指定
HttpClient#get にジェネリクスで型を指定 （取り急ぎanyで対応…）
- this.http.get(url)
+ this.http.get<any>(url).subscribe( res => {
console.log(res['foo']); // OK
- // console.log(res.bar); // Property 'bar' does not exist on type 'Object'
+ console.log(res.bar); // OK!
});

18. 基本的には単純作業

19. 型をどう管理するか？

20. APIの返却形式と型定義とが一対一で紐づく
● 全APIのレスポンスに対応した型定義を書く？
● サーバ側でも（おそらく）レスポンスのスキーマは管理している。
○ 二重管理するのか？
○ サーバも開発中でAPI仕様も不定期に変わるとしたら？

21. まずは書く
interface SomeApiResponse {
requiredString : string, // このプロパティは必ず存在する
optionalNumber ?: number, // このプロパティは特定の場合のみ存在する
}
以降strictNullChecksを前提に解説します。

22. 使ってみる
this.http.get<SomeApiResponse>(url).subscribe( res => {
// console.log(res.optionalNumber.toFixed()); // Object is possibly 'undefined'
if(res.optionalNumber) {
// optionalなのでnullチェック必須
console.log(res.optionalNumber.toFixed())
}
// requiredなのでnullチェック不用
console.log(res.requiredString.length);
});

23. TypeScript最強！

24. …では済まない

25. 現実1
this.http.get<SomeApiResponse>(url) .subscribe( res => {
console.log(res.requiredString.length);
// Uncaught ReferenceError: requiredString is not defined
});

26. （サーバの人）あ、ごめん、バグってた…
● 特定条件で代入が漏れる系（自戒）

27. 現実2
this.http.get<SomeApiResponse>(url).subscribe( res => {
if(res.optionalNumber) {
console.log(res.optionalNumber.toFixed());
// Uncaught TypeError: res.optionalNumber.toFixed is not a function
}
});

28. （サーバの人）す、すみません、すぐ直します！
● PHPerやらかしがち系（自戒）
{"optionalNumber":"3"}

29. 型チェックが必要

30. 人力strictNullChecks
this.http.get<SomeApiResponse>(url).subscribe( res => {
if(res.optionalNumber && res.optionalNumber.toFixed) {
console.log(res.optionalNumber.toFixed());
}
if(res.requiredString) {
console.log(res.requiredString.length);
}
});
チェックが漏れていてもコンパイラは教えてくれない。

31. 粘着strictNullChecks
interface SomeApiResponse {
requiredString : string,
optionalNumber ?: number,
}
type SomeApiResponseCheck = {
[P in keyof SomeApiResponse] ?: SomeApiResponse[P];
}

32. 粘着strictNullChecks
this.http.get<SomeApiResponseCheck>(url).subscribe( res => {
if(typeof res.optionalNumber === 'number') {
console.log(res.optionalNumber.toFixed());
}
// console.log(res.requiredString.length);
// Object is possibly 'undefined'.
});
必須と解っていてもチェックしないとコンパイル通してくれない。

33. 何のためにTypeScript
を使っているか解らない
レベル

34. 問題を整理
● 入力は信頼しない方針。
● TypeScriptの恩恵は受けたい。
● スキーマの二重管理は避けたい。

35. 提案
● JSON Schema
● JSON Schema Validation
● JSON Schema to TypeScript

36. 管理を一本化
SomeApiResponse.yaml
type: "object"
properties:
requiredString:
type: "string"
optionalNumber:
type: "number"
required:
- "requiredString"
additionalProperties: false

37. JSON Schemaの自動生成
SomeApiResponse.ts
export const SomeApiResponse = {
"type": "object",
"properties": {
"requiredString": { "type": "string" },
"optionalNumber": { "type": "number" }
},
"required": [ "requiredString" ],
"additionalProperties": false
}

38. 型定義の自動生成
SomeApiResponse.ts
export interface SomeApiResponse {
requiredString: string;
optionalNumber?: number;
}
https://github.com/bcherny/json-schema-to-typescript

39. 自動化されたバリデーションの通過までがAPI
import { SomeApiResponse } from './SomeApiResponse';
...
this.http.get<SomeApiResponse>(url)
// 仕様を満たさない返却は棄てる例
.filter( res => jsonschema.validate(res, SomeApiResponse).valid )
.subscribe( res => {
/* ... */
})
;

40. 再掲＆提案
● 全APIのレスポンスに対応した型定義を書く？
○ d.tsでなくて良ければ既に誰かが書いてる。利用する。
○ 誰も書いてなかった場合自分が書く。皆と共有する。。
● サーバ側でも（おそらく）レスポンスのスキーマは管理している。
○ *二重管理するのか？ *
■ 集中管理
○ *サーバも開発中でAPI仕様も不定期に変わるとしたら？ *
■ バリデーションまで含め自動で追従

41. more validation

42. サーバ側を巻き込む

43. サーバ側を巻き込む
http.createServer((req, res)=>{
let body : string;
const errors = jsonschema.validate(body, SomeApiResponse).errors;
if(errors.length) {
res.writeHead(500);
res.write('ごめんバグ！Slackにログ飛ばしたので光の速さで直すよ！')
} else {
....
}
}).listen(8000);

44. 交換条件を提示する

45. 交換条件を提示する
class HttpClientValidation extends HttpClient {
public post<ResponseSchema,RequestSchema>(url: string, body:
RequestSchema, RequestSchema: any) {
const errors = jsonschema.validate(body, RequestSchema).errors
if(errors.length) {
console.warn(errors);
throw new Error('壊れたリクエスト、それは信頼関係をも壊す……');
}
return super.post<RequestSchema>(url, body);
}
}

46. ベストプラクティス
● サーバとクライアントが同じスキーマを参照
○ 中間形式（今回はyaml）を活用
● スキーマ変更はサーバ・クライアント双方が 自動で 追従する
○ git submodule
● バリデーションは人力では書かない
○ 仕組み化（今回はJSON Schema）が重要
些細なミス撲滅
テスト大幅削減
API統廃合の際の対応漏れ撲滅

47. more more validation

48. 外部との入出力を行う箇所には全て仕込む
● localStorage / sessionStorage
● KVS / NoSQL
○ 本番はNoSQLを利用するがローカル開発時は localStorage で代用するケース
○ レスポンスを丸ごとKVSにキャッシュするケース
● RDB
○ Table Schema <--> JSON Schema <--> TypeScript
○ WebAPIの型も出自はRDBのカラムの型
■ 書いておけば意外と再利用できる

49. 型安全性の範囲
● 閉じた系の中ではTypeScriptは型安全
● 系を跨いだ安全性は自分達で用意
○ 担当者とか部署とか社内社外とか気にしない
● レイヤーを超えた型安全により TypeScriptがより便利になる
○ JSONがデフォルトとなった HttpClientModuleではより顕著

50. 新機能デモ

51. HttpProgressEvent New!!
● Sent
New!! リクエストの送信を開始した
● UploadProgress
New!! リクエストを送信中
● ResponseHeader
New!! レスポンスヘッダを受信した
● DownloadProgress
New!! レスポンス受信中
● Response
レスポンス受信完了
● User
New!! カスタムイベント

52. 使えそうなもの
● UploadProgress
● DownloadProgress
○ 進捗に応じて何度も発火される。
○ 途中経過（サイズ・内容）を取得できる .

53. 使いみち
ダウンロード（アップロード）の進捗表示

54. だけ…？

55. Long-Polling with XHR

56. サーバ側
http.createServer((req, res)=>{
// 5秒毎に「hello」と出力
let timer = setInterval( () => { res.write('hello'); }, 5000);
/* res.end(); */ // サーバ側からの切断は行わない。
// クライアントの切断まで動き続ける。
req.on('close', () => { clearTimeout(timer); });
}).listen(8000);
仮ソースです。実際にはヘッダ制御なども必要になります。

57. クライアント側
const request = new HttpRequest('GET', url, {
reportProgress: true, // HttpProgressEvent を使う。
responseType: 'text' // json（デフォルト）は最後まで受信しないとparse開始出来な
い。
});
this.http.request(request).subscribe(ev => {
if(ev.type === HttpEventType.DownloadProgress) {
console.log(ev.loaded); // これまでに取得したサイズ
console.log(ev.partialText); // これまでに取得した内容
}
});

58. 使いどころ
素直に socket.io を使うのが無難
const socket = io({
transports: ['polling']
});
今回のサンプルソースをきちんと実装した例
https://github.com/socketio/engine.io/blob/master/lib/transports/polling.js

59. とは言え

60. High-Level
● HttpModule
○ Responseをsubscribe()
■ httpの存在を意識
● HttpClientModule
○ Objectをsubscribe()
■ httpを隠蔽

61. Low-Level
● HttpModule
○ 「送信開始」「受信完了」しか制御できない。
● HttpClientModule
○ 途中経過も制御できる

62. HttpClientModule
● High-Level
○ httpの存在を意識せず利用
● Low-Level
○ XMLHttpRequestで出来ることは全てできる
用途の幅は大幅に広がった

63. Thank you
Welcome to http