Drupal で巨大なメニューを保守する方法

Menu Select Ajax:編集者が必要とするときに選択肢を読み込む

オートコンプリート付きの Menu Select は、すでに大きな前進です。しかし非常に大きなサイトでは、編集者が何かをする前にフォームがメニューデータを準備しすぎようとすると、より優れたウィジェットでも依然として重すぎることがあります。ここで AJAX ベースのメニュー選択パターンが意味を持ちます。

考え方は単純です。フォームは、初期読み込み時に巨大なメニューの完全な親セレクターを構築すべきではありません。待つべきです。編集者がメニューを選ぶ、検索語を入力する、あるいはブランチを開くと、Drupal は小さな AJAX リクエストを行い、メニューの一致する部分だけを返せます。Drupal の Form API は、AJAX 対応のフォーム要素を通じてこのパターンをサポートしており、ユーザーのアクションがサーバー側の再構築を引き起こし、フォームの選ばれた部分だけが置き換えられます。https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms

実際には、AJAX メニュー選択にはたいてい2つの層があります。1つ目の層は目に見えるセレクターです。検索フィールド、親のピッカー、あるいは小さな展開可能なブランチです。2つ目の層は保存される値です。フォームが保存されるときに Drupal が必要とする、実際のメニューリンクプラグイン ID または親への参照です。

この区別は重要です。編集者はラベル、パンくず、そして馴染みのあるページタイトルを扱うべきです。Drupal は安定したマシン値を保存すべきです。この2つの関心事が混ざり合うと、大きなメニューのウィジェットは脆くなります。重複したラベル、不明瞭な親の選択肢、そして遅いフォームの再構築が現れます。

良い AJAX メニュー選択の流れは、ほとんど退屈に感じられます。編集者がタイトルの一部を入力し始めます。Drupal は、できれば同一のタイトルを見分けられるだけの十分な文脈とともに、候補となる親リンクの短いリストを返します。編集者が1つを選びます。フォームは、選ばれたメニューリンクを裏側で保存します。巨大なセレクトリストはありません。ツリー全体のレンダリングもありません。ブラウザのメルトダウンもありません。

同じパターンが展開可能なブランチにも当てはまります。まずトップレベルを表示します。編集者が親を開いたら、その親の子を取得します。さらに別の子を開いたら、次の階層を取得します。データセットが大きいとき、UI はこう振る舞うべきです。小さなリクエスト、小さなレスポンス、明確な次のアクション。

1万件のメニュー項目では、先読み読み込みをやめる

メニューが1万件ほどに達すると、私はそれを通常の Drupal メニューとして考えるのをやめます。技術的には、それは依然としてメニューです。運用上は、ツリー状のコンテンツインデックスに近いものです。

よくある間違いは、ルートから始めてツリー全体を読み込み、アクティブなパスを展開し、それから結果のほとんどを捨てることです。それは小さなメニューでは機能します。巨大なメニューでは、逆向きです。

私が使ったより良い方法は、逆向きの読み込みです。現在のページのアクティブなメニューリンクから始めます。そこから、その親だけを読み込みます。それにより、無関係なすべてのブランチを構築するよう Drupal に求めることなく、アクティブなパスが得られます。Drupal のメニュー API はこの進行方向をサポートしています。メニューリンクマネージャーはルートによってリンクを見つけられ、また、メニューリンクプラグインの親 ID も公開します。https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21MenuActiveTrail.php/11.x https://api.drupal.org/api/drupal/core%21lib%21drupal%21core%21menu%21menulinkmanagerinterface.php/function/menulinkmanagerinterface%3A%3Agetparentids/9

これはコストのプロファイルを完全に変えます。巨大なメニューは1万件の項目を持つかもしれませんが、あるページのアクティブなパスはたいてい短いものです。5階層かもしれません。7階層かもしれません。深いカタログでさえ、1つの項目に対して数十もの先祖を持つことはめったにありません。ですから、1つのパスを見つけるために1万件のリンクを読み込むのではなく、アクティブな項目を読み込んで上へ辿ります。

その後、ページが実際にどれだけ周辺のナビゲーションを必要とするかを決められます。親のパスで十分なこともあります。アクティブな項目の子も必要なこともあります。セクションメニューのために、同じ階層の兄弟が必要なこともあります。結構です。それらのスライスを意図的に読み込んでください。「ナビゲーションが必要だ」が、いつの間にか「リクエストのたびにツリー全体を読み込む」に変わることを許さないでください。

Drupal のメニューツリーシステムは、すでにツリーパラメーター、アクティブなパス、変換という観点で考えます。通常のツリー読み込みの手法は、現在のアクティブなパスに沿ってリンクを展開でき、それは通常のメニューでは有用です。https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21MenuLinkTreeInterface.php/interface/MenuLinkTreeInterface/8.2.x しかし、非常に大きなメニューでは、私はもっと厳格でありたいと思います。まずアクティブなリンクを見つける。次にその親を読み込む。次に、現在のページに必要なブランチだけを読み込む。

本当の保守ルール:編集者にメニュー全体の代償を決して払わせない

巨大な Drupal メニューは、レンダリングの問題だけではありません。編集の問題、フォーム構築の問題、キャッシュの問題、そして時には誰かが3年間先延ばしにしてきた情報アーキテクチャの問題です。

BigMenu は、編集者がすべてを一度に開くことなく大きなツリーを扱うのを助けます。https://www.drupal.org/project/bigmenu Menu Select は、特にオートコンプリートを使えば、親の選択を我慢できるものにします。https://www.drupal.org/project/menu_select AJAX による選択は、編集者が最初の意味のあるクリックをする前に、フォームが数千の選択肢を準備するのを防ぎます。https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms

フロントエンドのナビゲーションについては、逆向きの読み込みこそ、私が最も積極的に守りたい部分です。アクティブなメニューリンクから始める。親だけを読み込む。デザインが本当に必要とするときにのみ、子や兄弟を加える。その一つの習慣が、1万件のメニューが各リクエストを罰に変えることを防ぎます。

1つのページが自分の居場所を知る必要があるというだけで、ブラウザがメニュー全体を背負わされるべきではありません。