code-computer

SPAで別タブ、別窓は避けるべき

JavaScript

そもそもSPAとは

Single Page Applicationの略で、サーバにはAjaxで通信を行う。受け取ったJSONをもとにDOMを更新する。Singleと言うだけあって、「画面遷移」という概念が無いです。
→「画面更新」という形で、画面(アドレス)はそのままでDOMが書き換えられる。

SPAで別タブ、別窓は可能?

ずばり、「可能です」。その代わり、「MPA(Multi Page Application)」になります。もう少し言えば、「なんちゃってSPA」とでも言うべきでしょうか。(SPAプロジェクトで、URLディスパッチで疑似的に別タブ、別ウィンドウを生み出す。)

これは「技術的に」という話であり、セキュリティ制約などを考慮すると結果「不可能」となる可能性があります。

画面のイメージとしては、

SPA→Webアプリログイン→メニュークリック→【別タブ・別窓(情報引継)】
※別タブ、別窓で開く想定のWebアプリは「同一のSPAプロジェクト」です。

実現方法

「ローカルストレージ」が選択肢としては、一番でしょうね。

そもそも、「流行っているから」のようなフワフワした理由じゃない限り、
性能面(描画速度しかり、サーバ負荷しかり)を懸念してのことだと思います。特にサーバサイドレンダリングでは初回「以外」の描画速度を上げたいってのが大きいでしょうか。

別タブ・別窓ということは「同時に複数データを保持する」ことになる(可能性があります。)
そもそも論で言えば、そこまでのデータ(負荷)をフロントにかけるな!という話もあるでしょう。

最後に

SPAを選択する時点で、「JSファイルの肥大化」が懸念されます。
(初回アクセスの時間はMPAに比べて多くなる可能性が高いです。)
初回アクセス時には、「アプリのログイン処理」以外にも「セキュリティ認証」などでコストを食うため、予想以上に長くなるうえ、対策が難しいです。

SPAはメリットばかりではなく、デメリットも多く抱えている方式であることを理解し、
アプリの方式を考えましょう。

SPAのSは、Singleは「画面とともに、業務が一直線に流れる」場合にはかなり有効です。
[操作]→表示画面 のイメージとすると以下の感じ。(一覧-明細の直線更新フロー)

[ログイン]→初期画面
[検索]→一覧画面
[一覧選択]→明細画面
[変更]→更新画面
[内容修正]→更新確認画面
[更新]→更新完了画面 ←この辺はモーダルにして一覧即飛びも有
[戻る]→一覧画面

ただし、例えば「基幹系システム」を「SPA」とするのは私なら避けます。
(基幹系というより、各サブシステムを別タブ・別窓で開いて「複数のサブシステム」を同時利用したい。なんて仕様が上がった場合は、避けたいな。と思います。Singleじゃないので。)

[ログイン]→初期画面
→(別タブ)給与管理サブ
→(別タブ)勤怠管理サブ
 ……
→(別タブ)マスタ管理サブ

ログイン画面は普通にサーバサイドレンダリングにして、各サブ単位でSPA化するのはありかな?とも思いますが、SSO可否などの制約もあるでしょうから一概には言えませんね。

 

スポンサーリンク