フロントエンドの目標

このセクションでは、GitLabフロントエンドが今後数年間でどのような_状態になることが望ましいかを_定義しました。

クラスターSPA

現在のところ、GitLabのほとんどはRailsアーキテクチャとRailsルーティングに従っています。つまり、ルートを変更するたびにページをリロードしなければなりません。その結果、読み込み時間が長くなってしまいます：

  • HAMLページのレンダリング；
  • Vueアプリケーションのマウント
  • これらのアプリケーションのデータの取得

理想的には、ユーザーがこの長いプロセスを経る回数を減らすべきです。これはGitLabをシングルページのアプリケーションに変換することで可能になりますが、大幅なリファクタリングが必要になり、短期的・中期的な目標としては達成できません。

現実的なゴールは、ユーザーフローを形成するページの_クラスターを_定義し、このクラ_スターを_Railsルーティングからクライアントサイドルーティングを持つシングルページアプリケーションに移行することです。こうすることで、HAMLから関連するすべてのコンテキストを一度だけロードし、ルートに応じてAPIからすべての追加データを取得することができます。クラスターの例は次のようなPagesです：

  • イシューリスト
  • イシューボード
  • イシュー詳細ページ
  • イシュー
  • イシュー編集

これらすべてが同じコンテキスト(プロジェクト・パス、現在のユーザーなど)を持っているため、イシュー固有のパラメータ(イシューiid)を使用して簡単に多くのデータを取得し、その結果をクライアントに保存することができます(同じイシューを開くために多くのAPIコールを必要としないように)。これは、イシューをナビゲートするためのスムーズなユーザー・エクスペリエンスにつながります。

クラスター間のナビゲーションについては、まだRailsルーティングに頼ることができます。このようなケースはクラスター内のナビゲーションよりも比較的少ないはずです。