UIコンポーネント単位のエンド・ツー・エンドの開発パイプライン

『アーキテクトがリードするUIプロトタイピング（OOSass と JavaScript MVC と DDD）』の続き。ウェブ・アプリケーション・フレームワークの話です。

UIコンポーネント指向

「UIコンポーネント」という単位で、UIからビジネス・ロジックまでエンド・ツー・エンドに実装する。「UIコンポーネント」の単位で、ひたすら並列開発できる（パイプライン化）。こんな開発手法を模索しています。

それにより、 OOSass を使った HTML & CSS ベースのプロトタイピングを、ビジネス・ロジックの実装にまで拡張できるはずです。それが「UIコンポーネント単位のエンド・ツー・エンドの開発パイプライン」という意味です。作業仮説ですが。

Seaside

ここで参考になるのが、SeasideというSmalltalkのウェブ・アプリケーション・フレームワークです。非常にユニークというか、個人的にはかなり違和感もある独特なフレームワークですが、学ぶべきところも多々あります。 About ページで挙げられている特徴のなかに「コンポーネント指向」の考え方があります：

Embedded components. Stop thinking a whole page at a time; Seaside lets you build your UI as a tree of individual, stateful component objects, each encapsulating a small part of a page.

「ウェブページをまるごと一度に考えるのを止めよう」と言っています。「ステートフルなコンポーネントを作り、その組み合わせによってウェブ・ページを構成しよう」という考え方です。コンポーネントは色々な画面で再利用できるので DRY (Don't Repeat Yourself) です。

しかも「継続」 (continuation) まで使えます。「ステートレスな HTTP というプロトコル」という常識に正面から挑んでいます。かなり独特なので（とくに URL が…）、だまされたと思って、いちど触ってみて頂きたいです。「だまされた！」と思うかもしれませんが…

ともあれ「コンポーネント指向」を分かりやすくイメージするならば、こういう喩えがよいでしょう。「ヘッダ」「フッタ」を共通化してインクルードして使い回すことがあると思います。そういう「埋め込み部品」 (embedded components) の組み合わせによってウェブ・ページを構成する手法を、ヘッダやフッタのみならずウェブ・ページを構成するあらゆる情報要素にも適用するということですね。静的なヘッダやフッタとは異なり、機能を持った部品 (functional components) もあるのがポイントです。

コンポーネント指向とオブジェクト指向の密接な関係

具体的に、どういうものが「UIコンポーネント」になるのでしょうか。設計次第ですが、現時点の私は、次のような粒度をイメージしています：

問い合わせフォーム (an inquiry form)
検索結果リストのなかの商品 (a product information embedded into a search result list)
商品詳細の「カートに入れる」ボタン (an add-to-cart button embedded into a product detail)
検索結果リストのなかの商品の「カートに入れる」ボタン (an add-to-cart button embedded into a product information, which is embedded into a search result list)

ここで、「カートに入れる」ボタンは、まったく同じ部品でよいとしましょう。ならば再利用できます。この再利用は、単なるコンポーネントの再利用とは少し意味が違います。コンポーネントの「入れ子」で再利用することになります。小さなコンポーネントを使って、大きなコンポーネントを作ることができるのです。

ここで「コンポーネント」を「オブジェクト」と呼び直せば、まさに「オブジェクト指向」 (OO: object-orientation) の考え方だと分かります。小さなオブジェクトの組み合わせで大きな部品を作り、大きな部品の組み合わせでウェブ・ページを作り、ウェブ・ページの組み合わせでウェブ・サイトを作る、というミクロからマクロへの構造が現れてくるわけです。

ちなみに、アラン・ケイがオブジェクト指向を構想する際に「細胞」の概念を援用したという話があります。まさにそういう話になっています。

Seaside のコンポーネント指向に関する詳しい説明が『SeasideへGO!!(第2回)』にあります：

Web はマルチユーザの環境なので、「アプリケーション」のインスタンスは複数立ち上がらなければなりません。つまり正確にはアプリケーションそのものではなく、ルートとなる「コンポーネント (WAComponent)」が、セッションごとに立ち上がります。 GUI にあてはめると、アプリケーションを選択した後に、ウィンドウが一つ開いたと考えると良いでしょう。

ルートコンポーネントはメモリ上で待機し、それぞれがループを行います。イベントを受けつけ、必要に応じて自身の表示更新を行い、インタラクティブにユーザとやり取りをします。リクエストごとに都度立ち上がるコントローラ、コントローラの指示を待つ受け身のビューというものは存在しません。

コンポーネントは内部にコンポーネントを入れ子として含むことが可能です。ルートのコンポーネントがウィンドウ、入れ子になったコンポーネントが、ボタンやリストなどのウィジェットと考えることができます。

各コンポーネントは、状態をそれぞれ別個で保持します。典型的な Web アプリフレームワークでありがちな、ページ間にまたがるデータを一つのセッション辞書に詰め込むようなアプローチとは一線を画しています。