WEBVTT

1
00:00:00.000 --> 00:00:00.974
こんにちは。

2
00:00:00.974 --> 00:00:06.979
今回のテーマは、タイプスクリプトのプロミスと、エイシンク、アウェイトです。

3
00:00:06.979 --> 00:00:14.446
通信やファイル読み込みなど、時間のかかる処理の結果を型で表し、安全に受け取る方法を学びます。

4
00:00:14.446 --> 00:00:20.613
プロミス・ティーは、後で成功したときにティー型の値を受け取る処理を表します。

5
00:00:20.613 --> 00:00:28.242
エイシンク関数はプロミスを返し、アウェイトは成功した値を受け取るか、失敗を例外として伝えます。

6
00:00:28.242 --> 00:00:34.897
大切なのは、ティーは成功する値の型であり、失敗する理由の型ではない、という点です。

7
00:00:34.897 --> 00:00:42.363
アウェイトはアプリ全体を止めるわけではなく、待っている非同期関数の続きを中断する仕組みです。

8
00:00:42.363 --> 00:00:49.180
順次処理、並行処理、失敗の扱いを、実行できる小さな例で一つずつ確認していきましょう。

9
00:00:49.180 --> 00:00:53.124
まず、記事を取得する学習用の関数を用意します。

10
00:00:53.124 --> 00:00:59.641
アーティクル型は、数字のアイディーと文字列のタイトルを持つ記事そのものです。

11
00:00:59.641 --> 00:01:04.957
一方、プロミス・アーティクルは、記事で成功する処理を表します。

12
00:01:04.957 --> 00:01:09.672
エイシンク関数ロードアーティクルは、アイディーが1以上の整数でなければエラーを投げ、

13
00:01:09.672 --> 00:01:14.388
正しければ記事を返します。

14
00:01:14.388 --> 00:01:20.219
エイシンク関数の中で投げた例外は、返されるプロミスの失敗になります。

15
00:01:20.219 --> 00:01:27.935
呼び出し側では、戻り値から直接タイトルを読まず、アウェイトで記事を受け取ってから読みます。

16
00:01:27.935 --> 00:01:35.652
実際に、アウェイトせずにタイトルを読もうとすると、型エラーになることを実機で確認しました。

17
00:01:35.652 --> 00:01:39.425
この関数は学習用で、実際の通信は行いません。

18
00:01:39.425 --> 00:01:43.712
通信に置き換える場合の注意は、最後の章で扱います。

19
00:01:43.712 --> 00:01:45.812
次に、失敗の受け取り方です。

20
00:01:45.812 --> 00:01:51.960
失敗する理由は、文字列などでも構わないため、必ずエラーオブジェクトとは限りません。

21
00:01:51.960 --> 00:02:00.959
そこで、エラーメッセージ関数は、理由をアンノウンで受け取り、インスタンスオブ・エラーで判定してからメッセージを読みます。

22
00:02:00.959 --> 00:02:07.857
ストリクトでは、明示的に設定を上書きしない限り、キャッチの変数もアンノウンとして扱われます。

23
00:02:07.857 --> 00:02:12.206
判定なしにメッセージを読もうとすると、型エラーになります。

24
00:02:12.206 --> 00:02:17.755
受け取った失敗を、まず種類を確認してから使う、という流れを覚えてください。

25
00:02:17.755 --> 00:02:23.604
文字列など、エラー以外の理由が来た場合は、不明なエラーとしてまとめて扱えます。

26
00:02:23.604 --> 00:02:26.385
では、メイン処理で成功と失敗を扱います。

27
00:02:26.385 --> 00:02:30.974
メイン関数は値を返さないため、戻り値はプロミス・ボイドと表します。

28
00:02:30.974 --> 00:02:36.536
トライの中で、まずアイディー1の記事をアウェイトで取得し、タイトルを表示します。

29
00:02:36.536 --> 00:02:42.238
続けてアイディーゼロで取得しようとすると例外が投げられ、処理はキャッチへ移ります。

30
00:02:42.238 --> 00:02:46.688
キャッチでは、アンノウンで受け取った理由をエラーメッセージ関数に渡し、記事アイディーは1以上の整数にしてください、

31
00:02:46.688 --> 00:02:51.137
と表示します。

32
00:02:51.137 --> 00:02:57.256
この一連の出力は、実機でコンパイルして実行し、記事の期待どおりであることを確認済みです。

33
00:02:57.256 --> 00:03:01.125
ここからは、複数の記事を扱う方法を比べます。

34
00:03:01.125 --> 00:03:02.884
最初は順次処理です。

35
00:03:02.884 --> 00:03:10.270
フォー・オブの中でアウェイトすると、一つの取得が完了してから、次の取得を開始します。

36
00:03:10.270 --> 00:03:15.722
画面の例では、記事1、記事2の順に、順次という表示が並びます。

37
00:03:15.722 --> 00:03:23.108
前の結果を次の処理が必要とする場合や、順番が重要な場合は、この書き方が向いています。

38
00:03:23.108 --> 00:03:30.142
逆に、互いに依存しない処理まで順番に待つと、その分だけ全体の時間は長くなります。

39
00:03:30.142 --> 00:03:36.298
依存関係があるかどうかを先に考えることが、書き方を選ぶ基準になります。

40
00:03:36.298 --> 00:03:43.508
例えば、前の記事の内容を使って次を決める処理では、この順序の保証が必要になります。

41
00:03:43.508 --> 00:03:46.447
依存しない処理は、並行処理にできます。

42
00:03:46.447 --> 00:03:51.242
プロミス・オールでは、渡す配列を作るときに、それぞれのロードアーティクルが呼ばれて処理が開始し、

43
00:03:51.242 --> 00:03:56.036
その完了をまとめて待ちます。

44
00:03:56.036 --> 00:04:04.079
関数名だけを配列に並べても、プロミス・オールが代わりに呼び出してくれるわけではない点に注意してください。

45
00:04:04.079 --> 00:04:08.255
結果の配列の順序は、完了した順ではなく、入力の順です。

46
00:04:08.255 --> 00:04:14.133
画面の例では、記事1と記事2が入力の順に受け取れ、並行という表示になります。

47
00:04:14.133 --> 00:04:19.237
開始した処理の失敗をどこで扱うかも、あらかじめ決めておきましょう。

48
00:04:19.237 --> 00:04:24.960
二件とも独立しているため、片方を待つ間にも、もう片方の処理を進められます。

49
00:04:24.960 --> 00:04:29.274
失敗が混ざる場合は、プロミス・オールセトルドを使います。

50
00:04:29.274 --> 00:04:33.741
これは、成功と失敗を含む全件の結果が確定するまで待ちます。

51
00:04:33.741 --> 00:04:42.677
各結果はステータスで区別でき、フルフィルドならバリューに成功した値が、そうでなければリーズンに失敗の理由が入ります。

52
00:04:42.677 --> 00:04:49.147
画面の例では、アイディー1は成功、アイディーゼロは失敗として、それぞれ表示されます。

53
00:04:49.147 --> 00:04:55.772
一件の失敗で全体を止めたくない場合や、成功分だけでも処理を進めたい場合に向いています。

54
00:04:55.772 --> 00:05:01.780
結果の使い分けを型に沿って書けるため、分岐の書き漏れにも気づきやすくなります。

55
00:05:01.780 --> 00:05:06.717
プロミス・オールの失敗について、誤解しやすい点を押さえます。

56
00:05:06.717 --> 00:05:10.996
一つが失敗すると、まとめたプロミス自体は失敗します。

57
00:05:10.996 --> 00:05:17.744
しかし、すでに開始した他の通信や処理が、自動でキャンセルされるわけではありません。

58
00:05:17.744 --> 00:05:24.820
中断したい場合は、対象のエーピーアイに対応する中断方法を、別に組み込む必要があります。

59
00:05:24.820 --> 00:05:33.707
また、大量のアイディーをマップして全ての通信を一度に開始すると、接続数や相手側の制限を超える場合があります。

60
00:05:33.707 --> 00:05:42.594
プロミス・オール自体に開始数を制限する機能はないため、必要なら同時に動く数を制限する仕組みを加えてください。

61
00:05:42.594 --> 00:05:48.848
失敗を早く知りたい場合と、全件の結果が必要な場合とで、使う道具が変わります。

62
00:05:48.848 --> 00:05:51.273
よくある間違いが、フォーイーチです。

63
00:05:51.273 --> 00:05:57.334
フォーイーチにエイシンクのコールバックを渡しても、外側は各コールバックの完了を待ちません。

64
00:05:57.334 --> 00:06:02.588
フォーイーチはアンディファインドを返すため、アウェイトを付けても解決しません。

65
00:06:02.588 --> 00:06:05.955
実機でも、外側の処理が先に進むことを確認しました。

66
00:06:05.955 --> 00:06:11.006
順次実行ならフォー・オブ、まとめて待つなら、マップでプロミスの配列を作ってプロミス・オールで待つ、

67
00:06:11.006 --> 00:06:16.058
というように、実際に待つプロミスを明示してください。

68
00:06:16.058 --> 00:06:20.368
開始した処理の失敗を扱う場所も、併せて決めておくことが大切です。

69
00:06:20.368 --> 00:06:24.948
失敗した処理に誰も気づかないまま終わる、という事故にもつながります。

70
00:06:24.948 --> 00:06:26.767
実行方法を確認します。

71
00:06:26.767 --> 00:06:31.726
空のフォルダで初期化し、タイプスクリプトとノードの型定義をインストールして、

72
00:06:31.726 --> 00:06:36.686
二つのファイルをエスアールシーに保存します。

73
00:06:36.686 --> 00:06:40.819
設定ファイルには、ターゲット・イーエス2022、モジュール・ノードネクスト、

74
00:06:40.819 --> 00:06:44.952
ストリクトを指定します。

75
00:06:44.952 --> 00:06:50.407
ビルドしてノードで実行すると、これまで見た出力が順に表示されます。

76
00:06:50.407 --> 00:06:56.441
練習として、プロミス・オールの片方のアイディーをゼロに変えると、続く処理へ進まず、

77
00:06:56.441 --> 00:07:02.475
最後のメインのキャッチが失敗を受け取ることも実機で確認しました。

78
00:07:02.475 --> 00:07:10.576
実際の通信に置き換える際は、型注釈やアズでは外部のジェイソンを検証できない点にも注意してください。

79
00:07:10.576 --> 00:07:11.492
まとめです。

80
00:07:11.492 --> 00:07:16.837
プロミス・ティーは成功した値の型を表し、失敗の理由の型ではありません。

81
00:07:16.837 --> 00:07:21.114
失敗はアンノウンで受け取り、種類を確認してから扱います。

82
00:07:21.114 --> 00:07:26.611
待つ順序は、依存する処理だけを順次にし、独立した処理は並行を検討します。

83
00:07:26.611 --> 00:07:32.415
その際、開始する件数や通信先の制限、失敗時に必要な結果を先に決めてください。

84
00:07:32.415 --> 00:07:37.225
画面の状態を扱う場合は、読み込み中、成功、失敗を別の状態として型で表すと、

85
00:07:37.225 --> 00:07:42.036
結果がないのに表示する間違いを見つけやすくなります。

86
00:07:42.036 --> 00:07:47.687
非同期の戻り値の型と、利用側の状態設計を組み合わせて確認していきましょう。

87
00:07:47.687 --> 00:07:54.254
まずは小さな例で、成功、失敗、並行の三つの流れを、自分で動かして確かめてみてください。

88
00:07:54.254 --> 00:07:55.628
お疲れさまでした。