エンドポイントからイベントのストリームを予期します。ここで、いくつかのコード行を追加して、サーバーから送信されるイベントをキャプチャしましょう。コンポーネントに追加していきます。このメソッドはサーバーからメッセージを受け取るたびに呼び出され、メッセージデータでコンポーネントの状態を更新します。コンポーネントにどのような変更をする必要があるかを示します。プロパティにイベントハンドラーを追加しました。プロパティはイベントがサーバーから来るときに呼ばれるイベントサーバーをポイントします。メソッドを呼び出します。プロパティでデータを運びます。文字列になり、これについては次のセクションで見ていきます。アプリケーションはサーバーから送信されるイベントを処理する準備ができました。エンドポイントに送信されるリクエストに応答します。呼ばれる新しいディレクトリを作りましょう。呼ばれる新しいファイルを作り、以下のコードをこのディレクトリに入れます。サーバーを実行します。サーバーの動作は引数としてパスされるコールバック関数で説明されます。ヘッダーを送ってレスポンスを開始します。サーバーが送信したヘッダーはクライアントとのライブ通信チャネルを確立するために、非常に重要です。値は、これが常時接続であることをクライアントに伝えます。これで、このクライアントは受信した最初のデータで終わりにならない接続であることを知ります。値はクライアントが受け取るデータを解釈すべき方法を決めます。プロトコルを使用するということをクライアントに伝えます。ヘッダーはそのローカルキャッシュにデータを格納しないようにクライアントに求めるので、クライアントによって読み込まれたデータは本当はサーバーから送信されたもので、過去に受け取った古いデータではありません。コンストラクターを使って新しく使用可能なデータを待ちます。残りの関数本体はフライト状態の変更をシミュレートするために、いくつかの関数実行をスケジュールします。各関数実行がスケジュールされると、以下のフォームの文字列がクライアントに送信されます。クライアントに送信されるデータを表します。行の空白行で閉じなければなりません。イベントメッセージには次のスキーマがある可能性があります。サーバーを実行するために、次のコマンドを端末にタイプしましょう。サーバーの両方を構築したら、お互いに通信できるようにしますが、実行するドメインが違います。リクエストを発行することができなくなります。[ファイルに追加して問題を解決することもできますが、これは既知の問題のため、この回避策は現在は適用できません。このアプローチで、サーバーはそのリソースを要求するために、異なるドメインで発行されたクライアントを承認します。ヘッダーのように新しいヘッダーを追加しします。呼び出しは次のようになります。アクセスが許可されたクライアント(任意のドメインから)を示します。これは運用環境では期待どおりのソリューションではないかもしれません。有効にして選択性を高めたり(特定のドメインだけを承認するなど)など、異なるアプローチを取るべきです。定義する行を次と交換しましょう。EventSource("http://localhost:5000/events");ぴったし!もう一度、バックエンドサーバーを実行してクライアントアプリケーションを始めると、数秒で、ブラウザーにリアルタイムのアプリケーションが表示されます。以下は、プロジェクトをどのように実行するかという要約です。セッションから両方のアプリケーションを実行するのが簡単かもしれません。発行してバックグラウンドのバックエンドサーバーを実行しなければならないかもしれません。プロパティに送信された特定のフライトを更新して、いつも同じ方法でサーバーイベントに応答します。これは素晴らしいけど、さまざまな状況をどのように管理したらいいのでしょうか?例えば、このフライトが到着した特定時間後のフライトを説明する行を削除したいとします。プロトコルはイベントを特定できるので、さまざまなタイプのイベントを簡単に処理できます。サーバーのコードがどのように変わるか、見てみましょう。プロパティを加えました。プロパティはクライアントに送信するイベントのタイプを特定するのに役立ちます。値で新しいイベントを追加します。)を更新したり、フライトを削除したりしなければならないと、クライアントに伝えます。バックエンドサーバーをリファクタリングした後、これらさまざまなイベントのタイプを処理するためにクライアントアプリケーションを更新する必要があります。開き、次のように更新します。プロパティに対するイベントハンドラーの割り当てがありません。メソッドを使用します。要素で生成されたように、サーバーで生成された各イベントに特定のイベントハンドラーを簡単に割り当てられるようになります。メソッドを割り当てました。定義されたように)ローマへのフライトは削除されます。接続はストリーミング接続です。接続はクライアントまたはサーバーの実行を止めない限り、永久的にアクティブに保存されます。サーバーが送信するイベントがなかったり、クライアントがもはやサーバーのイベントに関心がなくなったりしたら、現在アクティブな接続をどのようにして明示的に停止できますか?クライアントがイベントストリームを停止したい場合を考えてみましょう。これについて学ぶには、ユーザーが新しいイベントを受けるのを停止するボタンを作りましょう。メソッドを変更しましょう。メソッドにバインドします。このメソッドは次のようになります。メソッドを呼び出します。クライアント上のイベントストリームを閉じても自動的にサーバー側の接続を閉じません。サーバーはクライアントにイベントを送信し続けるということです。これを避けるには、サーバー側上の接続終了要求を処理する必要があります。イベントのイベントハンドラーを追加して行います。リクエストをキャッチし、コールバック関数を実行します。メソッドを呼び出します。クライアントが複数の終了要求を送信したときに起きる状態のときに接続がすでに閉じているかをチェックします。使ってスケジュールされているので、イベントをクライアントに送信する試行が接続が終了した後に起きる可能性があり、例外を生成します。以下の例で表示されているように、この接続がまだアクティブであるかをチェックして、これを避けます。他のタイムアウトイベントにも同じ戦略を実装しなければなりません。メソッドを呼び出す必要があります。クライアントにはその終了について通知し、そのサイド上のリソースが空きになるようにします。それを達成するために従う簡単な戦略は、接続を終了しなければならないことをクライアントに通知する特定のイベントタイプを生成することです。イベントを生成することもできます。更新することもできます。イベントに割り当てるのと同じくらい簡単です。ベースにしたリアルタイムアプリケーションを構築しました。サーバーによってプッシュされたさまざまなタイプのイベントを入手し、イベントストリームの終わりをコントロールできました。ネットワーク障害のため、クライアントがイベントの一部を失ったら、どうなりますか?もちろん、それは特定のアプリケーションによります。場合によっては、失ったイベントの一部を無視できるものもありますが、できないものもあります。これまで実装したイベントストリームについて考えてみましょう。イベントを失っても、大きな問題ではありません。ユーザーは時間表上で着陸段階を失うだけですが、接続が復元されると、その時間表がその後の状態の正しい情報を提供します。イベント後に復元されると、そのフライトは永遠に着陸状態が維持され、この苦しい状態を処理する必要があるという問題が起きます。プロトコルはイベントを特定して、切断された接続を復元するメカニズムを提供します。これについて学びましょう。キーワードをクライアントに送信する応答に添付して識別子を割り当てる能力があります。イベントを送信することができます。ネットワーク問題が発生し、イベントストリームへの接続が切断されると、ブラウザーは自動的にその接続を復元しようとします。ヘッダーで最後に受け取ったイベントの識別子を自動的に送信します。サーバーはイベントストリームを適切に復元するこの要求を処理するように変更されるべきです。逃したすべてのイベントに送信するか、あるいは新しく生成されたイベントで続けるかは、サーバーが決めることです。サーバーが逃したすべてのイベントに送信する必要があれば、すでにクライアントに送信したすべてのイベントを格納する必要もあります。この戦略をサーバーで実装しましょう。次は、少しのリファクタリングをした後のサーバー側コードの最終バージョンです。呼ばれる配列を紹介します。関数で生成されたイベントのコードをカプセル化します。格納されたことも見ることができます。これは最初のイベントを処理するコードです。配列に送信したイベントをフィルターし、クライアントに再度、送信します。}このような変更で、バックエンドをさらに堅牢にし、さらに回復性の高いものにします。更新することはとても簡単です。除くあらゆる主要なブラウザーに対応しています。ようなポリファイルの使用が余儀なくさせられています。これらポリファイルの使用は非常に簡単です。ポリファイルの使い方を見ていきます。他のものを使用するプロセスはそれほど異なりません。通してそれをインストール必要があります。コンポーネントのモジュールにそのモジュールをインポートします。コンストラクターを定義し、コードは前と同じように、サポートしないブラウザー上で機能し続けます。プロトコルを使うことはサーバーからのデータを待つことにを含む一般的な問題を解決するのに役立ちます。主な難点がクライアントやサーバー側の両方のリソースを消費するという長いポーリングを実装する代わりに、簡単なパフォーマンスソリューションを取得します。間から選択するときに覚えておくべき点です。サーバーからクライアントへの通信のみをサポートします。インフラストラクチャには追加の設定を必要としません。テキストベースのデータ転送のみをサポートします。エンコードする必要があります。