Event Handling

ratatui ライブラリでイベントを処理する方法はたくさんあります。主に、 ratatui がキャッチするイベントを直接公開しないためです。プログラマーは、選択したバックエンドのライブラリに依存します。

ただし、イベント処理について考える方法はいくつかあります。これは網羅的なリストではありませんが、より一般的な実装のいくつかをカバーしています。しかし、正しい方法は、あなたとあなたの現在のアプリケーションのために機能するものであることを忘れないでください。

集中イベント処理

これは、イベントが表示されたときにすべてのイベントを処理するため、イベントを処理する最も簡単な方法です。多くの場合、さまざまなサポートされているキーの event::read()? (in crossterm) の結果の単なる一致です。

長所: これには、メッセージの合格を必要としないという利点があり、プログラマーが可能なすべてのキーボードイベントを1か所で編集できるようにします。

短所: ただし、イベントを処理するこの特定の方法は、単に十分にスケーリングされません。 all イベントは1か所で処理されるため、キーバインドのさまざまなグループを別々の場所に分割することはできません。

集中キャッチ、メッセージの合格

イベントを処理するこの方法では、イベントのポーリングを1か所で投票し、キャッチされたイベントでメッセージ/呼び出しサブ関数を送信します。

長所: これは、シンプルさにおいて最初の方法に同様の魅力を持っています。このパラダイムを使用すると、個別のファイルに移動できる広範なパターンマッチングをサブ関数に簡単に分割できます。この方法は、メッセージチャネルがマルチスレッドセーフメッセージに合格するために使用されるため、基本的なマルチスレッドアプリケーションでよく使用されるアイデアでもあります。

短所: この方法では、集中型の場所でのイベントのために一貫して投票するために、メインループを実行する必要があります。

分散イベントループ/セグメント化されたアプリケーション

このスタイルでは、 Terminal の制御とサブモジュールへのメインループ。この場合、レンダリングとイベント処理の責任全体をサブモジュールに安全に渡すことができます。理論的には、このように構築されたアプリケーションには、集中イベントリスナーは必要ありません。

長所: 新しいサブモジュールが作成されるたびに更新する必要がある集中イベントループはありません。

短所: ただし、アプリケーションのいくつかのサブモジュールに同様のイベント処理ループがある場合、この方法では多くの重複コードにつながる可能性があります。