リアクティブ・プログラミング

今回お伝えするのは，Meteorが一般的なWebフレームワークとは一線を画しているコンセプト，「⁠リアクティブ・プログラミング」についてです。

リアクティブ・プログラミングとは，端的に言うと，あるデータに対して行った変更が自動的に伝播し，その他の部分に影響をおよぼすようなプログラミング・パラダイムのことです。

たとえば表計算ソフトの一般的な機能として，セルの値に応じて，そのセルを参照している部分の値も自動的に変更されるというものがありますが，これはリアクティブ・プログラミングの典型的な例です。

また，MVCフレームワークの中には，モデルの値を変更すると自動的にビューが更新されるという機能を持つ（バインディングと呼ばれます）ものもありますが，これもリアクティブ・プログラミングの例と言って良いでしょう。

Meteorの素晴らしい点は，リアクティブ・プログラミングをフレームワーク全体でサポートしていることです。Meteorは御存知の通り，クライアントからサーバまでカバーする「フルスタック・フレームワーク」ですから，その恩恵はWebアプリケーションスタック全体に及びます。

たとえば第8回のサンプル（8-1）を2つのウィンドウで開き，片方のウィンドウ上でデータを変更します。すると，もう片方のウィンドウの値も自動的に変更されます ─そんな，データを同期するようなコードはどこにも書いていないのに！！

この現象は，以下のような流れで起こっています。

1. 片方のクライアントが，キャッシュされたデータを変更する
2. サーバのデータにも自動的に変更が伝わる
3. そのサーバデータを利用している他のクライアントにも，自動的に変更が伝わり，キャッシュが更新される
4. キャッシュが更新されると，自動的にビューが更新される

2～4までの処理がすべて「自動的に」行われていることがおわかりでしょう。このように，サーバとクライアント間のネットワークすらもまたいで，データ変更が自動的に伝播するというのが，Meteorによるリアクティブ・プログラミングのパワーです。

上記のようなMeteorの動作は，具体的には以下のような要素によって成り立っています。

• クライアント上のリアクティビティ
• publish/subscribeによるサーバデータとクライアントキャッシュの同期

それぞれを理解するのは決して難しくありません。今回は，クライアント上のリアクティビティについて説明します。

クライアントサイドでのリアクティビティ

Meteorが提供するクライアントサイドでのリアクティビティにより，たとえば以下のようなことが実現されます。

• データに変更があった場合，ビューが自動的に変更される
• 設定値を保持する変数に変更があった場合，自動的にサーバデータとの同期が再実行される
• ...

ここで挙げた例はどれも，「⁠○○（というデータ）に変更があった場合」「⁠××（という関数）が実行される」という形になっているのがおわかりでしょう。前者（○○というデータ）のことをリアクティブ・データソース，後者（××という関数）のことをリアクティブ・コンテキストと呼びます。

Meteorがデフォルトで用意しているリアクティブ・データソースには以下のようなものがあります。

• Session…メモリ上に展開される，汎用的なキー・バリューストア。Sessionというグローバル変数で表され，任意のデータを自由に格納できる。
• データベースクエリの結果…コレクションのfindを実行した結果。
• Meteor.status()…クライアントとサーバの間の接続状況。
• Meteor.user()…現在ログイン中のユーザ
• Meteor.userId()…現在ログイン中のユーザID
• Meteor.loggingIn()…現在ログイン中かどうか

これらのデータソースに変更があった場合，以下に示すリアクティブ・コンテキストに渡した関数オブジェクトが，自動的に再実行されます。

• HTMLテンプレート…連載4～6回を参照。Meteorのビューを構築する中心的な技術。
• Meteor.render()/Meteor.renderList()…HTMLテンプレート内で使用される。
• Meteor.autosubscribe()…メソッド内で実行されたMeteor.subscribeについては，再実行時に自動的に停止・再開してくれる。
• Meteor.autorun()…任意の関数を受け取り，データソースの変更に際して自動的に再実行できる。