SPA のお話

React Angular

こんにちは、たーせるです。 先日、休暇を利用して大分の温泉へ行ってきました。

そこで今日は、スパ繋がりということで、だらだら SPA の話でもしようかと思います。

SPA ってなんだ

まず基本的なところから。

SPA は、シングル・ページ・アプリケーションの略です。 その名の通り、たった1つの HTML ページで構成された Web アプリケーションのことです。

HTML は1つだけですが、必ずしも極小規模のアプリケーションというわけではありません。 HTML 内部のコンテンツを JavaScript で動的に書き換えることにより、規模の大小を問わず多種多様なアプリケーションが作れます。

SPA を構築するためのライブラリとしては React や Vue 等が有名であり、また、フレームワークでは Angular がポピュラーです。

これらを用いると、従来は実装困難とされていた UX 要件を実現することもできます。

ページ切り替えの影響を受けないコンポーネント

従来の非 SPA 型アプリケーションでは、ページを切り替えた時点で、内包している全ての UI コンポーネントが強制的に破棄されてしまいます。

一方、SPA では「ページを跨いで動作を続けるコンポーネント」をアプリケーション内に配置できます。 これによってページ切り替えの際の切れ目をユーザに意識させない設計が可能になり、UX に連続性が生まれます。

サンプル動画の右下にご注目。

実際には JavaScript でブラウザの表示内容を書き換えることで、（擬似的に）ページ遷移をエミュレートしています。

このとき、一部のコンポーネントを書き換えずに残しておくことで、そのコンポーネントはページを跨いで動き続けているように見えるのです。

リアルタイムなデータのバインディング

メジャーな SPA ライブラリやフレームワークには、UI コンポーネントと JavaScript の変数を同期させる仕組みが採用されています。

これはリアルタイム Web やプッシュ通知と非常に相性が良く、わざわざページを F5 リロードしなくてもページの内容が常に最新化されます。 レガシー Web アプリを使い続けてきたユーザにとっては魔法に見えるかも知れません。

以下は、WebSocket と データバインディングを利用して、ページの表示内容をリアルタイムに更新するサンプル動画。


SPA の弱点

実は、SPA 黎明期[いつ？]の頃から、以下の問題点が指摘されていました。

  1. トップページ以外はブックマークできない
  2. ブラウザの戻る・進む・更新ボタンが使えない
  3. JavaScript によってページを動的に構築する性質上、検索エンジンに引っかからない
  4. 最初に全ページ分のデータを読み込むため、起動時のオーバヘッドが大きい

現在では、上記の問題点はかなり解消（あるいは解決策が確立）されています。

Google は SPA をクロールしてくれるようになりましたし、JavaScript が生成する（仮想的な）ページはきちんと固有の URL が紐付けられ*1、個別のページをブックマークすることも可能です。

また、初回起動時には必要最低限のモジュールのみを読み込み、残りは必要に応じて遅延ロードすることでオーバヘッドを分散できます。

React、Angular などはいずれも非常によくできており、日に日に便利になってきていますので、できる限りキャッチアップしていきたいと思いました。

おまけ - その SPA、本当に必要ですか？

最後にちょっとだけ思うこと。 たまに SPA ありきでアーキテクチャを選んだものの、結局「その仕様ならば SPA である必要はないのでは……」というケースに遭遇することがあります。

たとえば、上流工程の設計担当者が SPA の特長をよく理解しないままフロントの動きを決めてしまうと、「レガシーアプリとどこが違うの？」という全く面白味のないものを、わざわざ無駄な手間をかけて開発する羽目になるわけです。

こうやって作られたなんちゃってシステムが顧客満足度を下げて、「結局 SPA って残念だったね」と言われて終わってしまったりしないかなーと、個人的に少し心配です。

最後、余計なことを言ったせいで着地点がどっかに行ってしまいました。 めでたし、めでたし。

*1:URL とコンポーネントの紐付けは、プログラマが Router を利用して明示的に実装する必要がある。

Copyright (c) 2012 @tercel_s, @iTercel, @pi_cro_s.