（ASP.NET に限らず）ページングされた一覧ページと詳細・編集ページの行き来

背景

Webアプリにて、ページングされているグリッド表示系の一覧ページから、行クリックで詳細表示ページへ飛ぶ、といった UI はよく見かけるところだ。

ところがこのような Web アプリの実装において、この詳細表示ページから一覧ページへ戻るリンクをクリックしたときに、もとのページング状態を復元して一覧を表示するのは結構大変だ。

詳細ページに一覧ページへ戻るリンクを設けるだけなら、window.history.back() を実行する JavaScript コードを仕込むのも手だろう。

しかし詳細ページからさらに編集ページへ遷移し、編集ページから OK や Save で詳細ページに戻ってくる UI だと、history.back() の技法は使えない（一覧ページに戻らず、先ほど編集中だった編集ページに戻ってしまう）。

かといって普通に一覧ページへのハイパーリンクを設けるだけでは、詳細ページから一覧ページに戻った時には、"何インデックス目を表示していたか?" というページングの "状態" は失われ、常に1ページ目が表示される。

「これでは困る。どういうページ遷移であっても、一覧ページに戻ってきたら、当初の表示インデックスを表示してほしい」ということが要件だと、この動作は許容できない。

"Web には状態がない" という基本を踏まえると、ページング状態はプログラマがどこかに保存・復元する実装を書いてやる必要がある。

Cookie? セッション変数?

ページング状態を Cookie に保存するというのはどうだろうか?

これは全く機能しないわけではないが、ユーザーがページ遷移の途中で別のウィンドウまたタブを開いて操作したときに最善の動作はしなくなる。

どういうことかというと、タブ A と B のふたつのタブを開いてこの同じ Web アプリを操作したとすると、タブ A でページング切替したことが、タブ B に反映されてしまうのだ。

なぜならウィンドウやタブの数の如何によらず、Cookie は共通・単一の保存場所であるからだ。
いうなれば、この件に関してはグローバル変数のようなものである。

これで良しとする仕様もありだろう。
しかし、各タブごとにページング状態を記憶することを要件とした場合には この技法では太刀打ちできない。

ちなみに、サーバー側セッション変数にページング状態を保存する方法も、同じ理由から各タブごとにページング状態を記憶することはできない。
サーバー側では、どのウィンドウまたはタブからの要求かは、普通には区別がつかない。

クエリ文字列はどう?

クエリ文字列にページング状態を保存するというのは悪くないアイディアだ。
要するにページング状態を URL に埋め込んでしまうわけだ。
実際、自分もこの技法を使うことも少なくないし、よそでも普通に見かける実装である。

これならウィンドウまたはタブごとにページング状態を保存・復元したいという要件が満たせる。

しかしながら実装が大変だ。

少なくとも、ASP.NET ではそうだと思う（ほかの言語やプラットフォームに詳しくないので...）。

想像がつくと思うが、一覧ページに通じるありとあらゆるページ遷移のパス上で、このページング状態を保存したクエリ文字列を読み取り、ハイパーリンクなどの URL 生成時にこのクエリ文字列を埋め込む実装を書きまくる羽目になる。

ASP.NET MVC における緩和策

ちなみに、ASP.NET MVC による Web アプリ実装においては、この実装の大変さを緩和する実装技法を知っている。

@miso_soup3 さんのブログにある記事がそれだ。
http://d.hatena.ne.jp/miso_soup3/20130418/1366294932

こちらも URL に状態を埋め込むという点ではクエリ文字列による方法と同じだ。
しかし単純にクエリ文字列で状態を持ち運ぶのではなく、ASP.NET MVC のルーティングの仕組みを利用しているのがミソである。

ルーティング規則をうまく設定しておくことで、ASP.NET MVC による URL 生成で自動で URL 中に埋め込まれた "状態" をあらゆるページ遷移間で持ち運べるという寸法だ。

なかなかのアイディアだと思うので詳しくは上記ブログ記事を参照されたい。

別の解 - SessionStorage を使ってみる

ここではもうひとつの解を提案してみたい。

ブラウザのクライアント側スクリプトにおける SessionStorage を使う、というものだ。

実装は次のような感じである。

1. Webアプリから送信される、一覧ページの HTML 中には一覧のコンテンツはない。
   代わりに、このあと XHR(いわゆる"AJAX")によって取得される HTML の断片を挿入するためのプレースホルダである div 要素があるのみ。
2. この一覧ページ HTML に付随している JavaScript がページロード時に動き出し、SessionStorage からページインデックスを取り出す。既定値は1ページ目を指す"1"。
3. こうして入手したページインデックスをパラメータにしてWebサーバーへ XHR を実行し、一覧の HTML 断片を取得する。
4. 取得した HTML 断片を、一覧ページ HTML 中のプレースホルダ div 要素内に設置する。
5. ページインデックスを切り替えるリンクがクリックされたら、同様に JavaScript が起動し、クリックされたページインデックスを引数に Webサーバーへ XHR 実行 & 返された HTML 断片でプレースホルダ div 要素内を置換、を実施する。
6. このときに、切り替えるページインデックスを SessionStorage に保存しておく。

こうすることで、一覧ページを表示するときは、SessionStorage に保存しておいたページインデックスから XHR 実行で一覧を描き出すので、どのようなページ遷移をたどっても当初表示していたインデックスの一覧が表示されるわけだ。

文章で書いてもわかりにくいので、サンプルコードを GitHub に掲載しておいた。

https://github.com/sample-by-jsakamoto/SampleOfKeepPagingState
(※このサンプル、サーバ側実装は C# による ASP.NET MVC だが、要点はどんな言語・プラットフォームでも、たぶんそんなに変わらないだろうと想像している)

AppHarbor 上に実際にデプロイしてあるので、動作も確認できる。

https://appharbor.com/applications/sampleofkeeppagingstate

SessionStorage を使った実装のメリット

SessionStorage のうれしいところは、ウィンドウないしはタブ単位で固有である点だ。
そこが Cookie とは違うところである。

同じページから Ctrl + クリックなどで複数のタブを開いて操作したとしても、各タブごとにちゃんと一覧ページのインデックスが保存・復元されて動作する。

実装の負担も軽いと思う。

たしかに、一覧ページのサーバ側実装をページ全体を返す部分と一覧コンテンツの HTML 断片を返す部分に分割したり、多少とはいえ JavaScript コードを書かねばならない面はある。
とはいえ、ひどく煩雑という程でもなかろう。

むしろ、"一覧ページ" という局所に実装が凝集・完結しているので、詳細表示ページや編集ページなどの実装に影響しないところが好印象だ。

弱点

一瞬、白いページが見えるかもしれない

この技法の弱点は、一覧ページの HTML がロードされてから、一覧のコンテンツが読み込まれて描画されるまでにタイムラグが発生する点だ。
一覧の HTML 断片を返す処理に 500msec とかかかると、一瞬、真っ白な一覧ページがユーザーの目に触れるわけである。

読み込み中であることを表す Spinner 画像を一覧ページのプレースホルダ要素内に表示しておくなどの工夫が必要かもしれない。

検索エンジンに検出されない

また、検索エンジンのクローラに、一覧のコンテンツが検出されないという側面もある。
クローラにしてみたら、一覧ページの要求結果を手に入れても、そこにはプレースホルダの div 要素しか見えないわけだ。

もっとも個人的には、この種の Web アプリで検索エンジンのクローラに検出されることが要件となる事例がどれほどあるかあまり心配はしていない。

だがもしも、どうしてもクローラに検出してもらう必要があるのであれば、HTTP 要求中の User Agent 変数を見て、適宜サーバー側ですべてをレンダリングするように切り替えてもよいだろう。

JavaScript 必須

当たり前だが、JavaScript が使えることが必須となっている。
縮退動作を実装するのは難しいと思う。

あと、SessionStorage を搭載しない古いブラウザ（IE7以前とか）だと
JavaScript エラーを引き起こすことになる。
幸いこの件は、ダミーの SessionStoage 実装を window オブジェクトにくくりつけることで縮退動作を実現可能だ。
クラッシュせずにページングは機能する代わりに、しょせんダミーなので、ページ遷移して一覧ページに戻ると、必ず1インデックス目になってしまうが。

そもそもそこまで手間をかけてまでして古いブラウザに対応させるべきかどうかは検討の余地があるだろう。

状態が URL に埋め込まれていない

あと、REST の考え方に基づけば、状態は URL に埋まっているほうが望ましいのかもしれない。
ないしは、REST が云々は別としても、URL にページングのインデックスが埋まっていれば、ほかの人に URL を知らせるだけで、同じページングインデックスのページを見ることができるという利点がある。

しかしこの技法は要するに "AJAX" なので、ページインデックスをいくら切り替えても、URL はまったく変わらない。

この点に納得いかない場合は、ブラウザ側スクリプトにおける History API などを駆使して、SessionStorage と組み合わせて実装するとよいのかもしれない（但し自分はそのような実装を試したことはない）。

まとめ

以上、弱点というか考慮すべき点も多いが、それでもなお大いに有力な選択肢候補となるのが SessionStorage を用いた実装技法ではないだろうか。

上記で挙げた "弱点" が要件的に問題とならなければ、大きな実装負担を強いることなく、些細なことながらユーザー体験をより自然な "状態" のあるものにしてくれる良い技法だと自分では感じている。

さらに今回はページングのインデックスを状態保存・復元することだけに言及したが、絞込検索やソートなどの状態も同じ要領で状態保存・復元が可能だ。

これを突き詰めていくと、ステートフルな HTML5 + JavaScript アプリケーション、Web サーバ側は単なる永続化層、Single Page Applicion といったものになるのだろうか。

以上、参考になれば幸いである。