WEBVTT

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

2
00:00:00.911 --> 00:00:08.198
今回は、サーバーコンポーネントからクライアントコンポーネントへ、プロップスを安全に渡す方法です。

3
00:00:08.198 --> 00:00:12.905
プロップスは、親から子へ値を渡すリアクトの基本的な仕組みです。

4
00:00:12.905 --> 00:00:19.889
ところがネクストジェイエスでは、サーバーで動く部分とブラウザーで動く部分の境界が加わります。

5
00:00:19.889 --> 00:00:23.988
そのため、どんな値でも自由に渡せるわけではありません。

6
00:00:23.988 --> 00:00:30.820
渡せる値の形と、渡した値が誰に見えるのか、この二つを意識して設計することが今回の中心です。

7
00:00:30.820 --> 00:00:31.802
まず前提です。

8
00:00:31.802 --> 00:00:38.394
この記事の例は、ネクストジェイエス十五以降の非同期リクエストエーピーアイに合わせた書き方です。

9
00:00:38.394 --> 00:00:44.426
ネクストジェイエス十六では、キャッシュコンポーネンツを有効にしない構成を前提とします。

10
00:00:44.426 --> 00:00:51.158
タイプスクリプトは五・二以降で、利用するネクストジェイエスが対応するノードジェイエスを使います。

11
00:00:51.158 --> 00:00:57.751
配置先は、アプリ直下にレイアウト・ティーエスエックスを備えたアップルーターのプロジェクトです。

12
00:00:57.751 --> 00:01:05.325
ページズルーターとは配置先も実行場所も異なるため、プロジェクトのルーターとバージョンを先に確認してください。

13
00:01:05.325 --> 00:01:11.216
この前提がずれていると、同じコードでも動く場所や結果が変わってしまうことがあります。

14
00:01:11.216 --> 00:01:13.226
境界の仕組みを整理します。

15
00:01:13.226 --> 00:01:16.783
通常のプロップスは、コンポーネントの引数です。

16
00:01:16.783 --> 00:01:21.267
親が値を用意し、子がそれを受け取って表示や処理に使います。

17
00:01:21.267 --> 00:01:28.999
しかしサーバーからクライアントへ渡す場合は、値を一度、ブラウザーへ送れる形へ変換する必要があります。

18
00:01:28.999 --> 00:01:31.628
この変換をシリアライズと呼びます。

19
00:01:31.628 --> 00:01:36.730
文字列や数値、真偽値、配列やプレーンなオブジェクトは変換できます。

20
00:01:36.730 --> 00:01:43.689
一方、一般の関数やデータベース接続のようなものは、そのままでは変換できないため渡せません。

21
00:01:43.689 --> 00:01:48.328
サーバー側で必要な形に整えてから渡す、という順序が大切です。

22
00:01:48.328 --> 00:01:54.204
境界を意識せずに設計すると、実行して初めてエラーに気づくことになりがちです。

23
00:01:54.204 --> 00:01:56.204
記事のコードの一つ目です。

24
00:01:56.204 --> 00:02:02.974
ファイルは、アプリ、プロップスデモというフォルダーのカウンター・ティーエスエックスです。

25
00:02:02.974 --> 00:02:09.897
先頭のユーズクライアントという宣言で、このファイルがクライアントコンポーネントになります。

26
00:02:09.897 --> 00:02:15.589
プロップスの型は、ラベルという文字列と、イニシャルカウントという数値です。

27
00:02:15.589 --> 00:02:22.205
ユーズステートに初期値を渡してカウントを管理し、ボタンを押すたびに値を一つ増やします。

28
00:02:22.205 --> 00:02:25.744
画面の中で増やす処理はブラウザーが担当します。

29
00:02:25.744 --> 00:02:31.898
スライドでは表示崩れを避けるため、波括弧の埋め込みを文字列の連結で示しています。

30
00:02:31.898 --> 00:02:37.744
ラベルは見出しに、カウントは段落に表示され、増やすボタンがその下に並びます。

31
00:02:37.744 --> 00:02:39.440
二つ目は親ページです。

32
00:02:39.440 --> 00:02:44.372
ファイルは同じフォルダーのページ・ティーエスエックスで、ユーズクライアントの宣言がないため、

33
00:02:44.372 --> 00:02:49.305
こちらはサーバーコンポーネントです。

34
00:02:49.305 --> 00:02:57.937
ここではカウンターを読み込み、ラベルに読んだ記事という文字列を、イニシャルカウントに二という数値を渡しています。

35
00:02:57.937 --> 00:03:03.332
親は文字列と数値を渡せばよく、クリック用の関数を渡す必要はありません。

36
00:03:03.332 --> 00:03:08.881
処理をどちら側で担当するかを分けると、境界を越える値は最小限で済みます。

37
00:03:08.881 --> 00:03:15.972
サーバーが初期値を用意し、ブラウザーがボタン操作を担当する、という役割分担がこの例の形です。

38
00:03:15.972 --> 00:03:22.292
二つのファイルを並べて読むと、宣言のあるなしで役割が分かれることがよく分かります。

39
00:03:22.292 --> 00:03:23.406
実行結果です。

40
00:03:23.406 --> 00:03:31.364
スラッシュ・プロップスデモを開くと、読んだ記事という見出しと、二から始まるカウンターが表示されます。

41
00:03:31.364 --> 00:03:39.322
最初にサーバーコンポーネントがラベルと初期値を用意し、それがシリアライズされてブラウザーへ届きます。

42
00:03:39.322 --> 00:03:46.325
次にクライアントコンポーネントがその値を受け取り、ユーズステートの初期値として使います。

43
00:03:46.325 --> 00:03:52.055
その後のボタン操作による状態の変化は、ブラウザーの中だけで管理されます。

44
00:03:52.055 --> 00:03:55.715
サーバーへ毎回問い合わせるわけではありません。

45
00:03:55.715 --> 00:04:02.400
誰が最初の値を用意し、誰が操作を引き継ぐのか、その順序で読むと理解しやすくなります。

46
00:04:02.400 --> 00:04:06.653
渡せるかどうかを、純粋な判定に切り出して確認します。

47
00:04:06.653 --> 00:04:12.214
まずタイプオブで関数かどうかを確かめ、関数なら渡せないと判断します。

48
00:04:12.214 --> 00:04:18.102
文字列、数値、真偽値、配列、そしてプレーンなオブジェクトは渡せる側です。

49
00:04:18.102 --> 00:04:23.173
記事の例のラベルと初期値は、文字列と数値なので問題ありません。

50
00:04:23.173 --> 00:04:29.879
逆に、クリック処理そのもののような普通の関数や、データベース接続は渡せない側です。

51
00:04:29.879 --> 00:04:36.258
迷ったときは、値をデータとして送れる形かどうか、という観点で確かめてください。

52
00:04:36.258 --> 00:04:42.147
判定の考え方はシンプルですが、境界のエラーを事前に避ける助けになります。

53
00:04:42.147 --> 00:04:49.180
クラスや特別なオブジェクトも、そのままでは安全に送れない場合があるため注意が必要です。

54
00:04:49.180 --> 00:04:50.839
関数について補足します。

55
00:04:50.839 --> 00:04:57.336
親が用意した普通のコールバック関数を、サーバーからクライアントへそのまま渡すことはできません。

56
00:04:57.336 --> 00:05:04.247
クリックで何かを実行したい場合は、記事の例のようにクライアント側の中で処理を完結させるのが基本です。

57
00:05:04.247 --> 00:05:07.634
一方、サーバー側の処理を呼び出すためのサーバーファンクションへの参照には、

58
00:05:07.634 --> 00:05:11.020
専用の仕組みがあります。

59
00:05:11.020 --> 00:05:16.550
ただしそれを使う場合は、呼び出し時の認証と認可、そして入力の検証が欠かせません。

60
00:05:16.550 --> 00:05:22.217
誰でも呼び出せる入口になるため、便利さと引き換えに守るべき点を忘れないでください。

61
00:05:22.217 --> 00:05:27.608
処理の置き場所を先に決めることが、境界で迷わないための実践的なコツになります。

62
00:05:27.608 --> 00:05:29.850
安全面で最も大切な点です。

63
00:05:29.850 --> 00:05:35.713
クライアントへ渡すプロップスは、ページの閲覧者が確認できる情報です。

64
00:05:35.713 --> 00:05:41.920
つまり、ブラウザーへ送った時点で公開されたものとして扱う必要があります。

65
00:05:41.920 --> 00:05:47.266
エーピーアイキーや、表示に不要な個人情報を混ぜてはいけません。

66
00:05:47.266 --> 00:05:54.336
サーバー側でデータを取得した場合でも、子へ渡すのは表示に必要な項目だけに絞ります。

67
00:05:54.336 --> 00:05:59.854
たとえばユーザー情報なら、名前だけが必要なら名前だけを渡します。

68
00:05:59.854 --> 00:06:05.200
必要最小限を選んで渡す習慣が、意図しない情報の公開を防ぎます。

69
00:06:05.200 --> 00:06:09.511
型が合っていることと、安全であることは別問題です。

70
00:06:09.511 --> 00:06:16.236
サーバー側だけで使う値は、サーバー側に残しておくことが原則だと覚えてください。

71
00:06:16.236 --> 00:06:17.679
実務への応用です。

72
00:06:17.679 --> 00:06:22.650
この例はビルド時に値を確定できるため、静的出力に組み込めます。

73
00:06:22.650 --> 00:06:28.743
ただしシーエムエスの更新などで値を変えた場合は、再ビルドと再配置が必要です。

74
00:06:28.743 --> 00:06:31.629
もう一つ、確認課題にもある注意です。

75
00:06:31.629 --> 00:06:37.401
初期値を五へ変えて再読み込みすると、五から始まることを確かめてください。

76
00:06:37.401 --> 00:06:43.013
ただしユーズステートの初期値は、最初の描画のときに一度だけ使われます。

77
00:06:43.013 --> 00:06:47.503
後から親のプロップスが変わっても、自動では追従しません。

78
00:06:47.503 --> 00:06:54.237
常に親の値へ従わせるのか、独立した操作状態にするのかを、先に決めて設計してください。

79
00:06:54.237 --> 00:06:57.284
確認は本番ビルドと公開先でも行います。

80
00:06:57.284 --> 00:06:59.368
分けて試すことも大切です。

81
00:06:59.368 --> 00:07:00.308
まとめです。

82
00:07:00.308 --> 00:07:07.831
サーバーコンポーネントからクライアントコンポーネントへ渡せるのは、シリアライズできる値だけです。

83
00:07:07.831 --> 00:07:14.257
文字列や数値のようなデータは渡せますが、普通の関数やデータベース接続は渡せません。

84
00:07:14.257 --> 00:07:21.152
処理は担当する側で完結させ、サーバーファンクションを使う場合は認証と入力検証を行います。

85
00:07:21.152 --> 00:07:28.518
そして、渡した値は閲覧者に見えるため、秘密情報は混ぜず、表示に必要な項目だけを選んで渡します。

86
00:07:28.518 --> 00:07:35.728
初期値を変えて確かめ、初期化と親の変化が別であることを説明できれば、この回の目標は達成です。

87
00:07:35.728 --> 00:07:40.116
これでサーバーとクライアントの間のプロップスは完了です。

88
00:07:40.116 --> 00:07:41.526
お疲れさまでした。

89
00:07:41.526 --> 00:07:43.721
次回はヘッダーズを学びます。

90
00:07:43.721 --> 00:07:49.676
境界、変換、公開範囲という三つの言葉で説明できれば、実務でも応用が利きます。