Hoe je enorme menu’s in Drupal onderhoudt

Menu Select Ajax: laad de keuze wanneer de redacteur die nodig heeft

Menu Select met autocomplete is al een grote stap vooruit. Maar op zeer grote sites kan zelfs een betere widget nog steeds te zwaar zijn als het formulier te veel menudata probeert voor te bereiden voordat de redacteur iets doet. Hier is een op AJAX gebaseerd menu-selectiepatroon logisch.

Het idee is eenvoudig: het formulier zou bij de eerste load geen volledige parent-selector voor een enorm menu moeten bouwen. Het moet wachten. Wanneer de redacteur een menu kiest, een zoekterm typt of een tak opent, kan Drupal een kleine AJAX-request doen en alleen het overeenkomende deel van het menu teruggeven. Drupal’s Form API ondersteunt dit patroon via AJAX-enabled formulierelementen, waarbij een gebruikersactie een server-side rebuild triggert en alleen het gekozen deel van het formulier wordt vervangen. https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-formshttps://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms

In de praktijk heeft een AJAX-menu-selectie meestal twee lagen. De eerste laag is de zichtbare selector: een zoekveld, een parent-kiezer of een kleine uitklapbare tak. De tweede laag is de opgeslagen waarde: de daadwerkelijke plugin-ID van de menulink of parent-referentie die Drupal nodig heeft wanneer het formulier wordt opgeslagen.

Dit onderscheid is belangrijk. Redacteuren moeten werken met labels, paden en herkenbare paginatitels. Drupal moet stabiele machinewaarden opslaan. Wanneer die twee zorgen door elkaar lopen, worden widgets voor grote menu’s kwetsbaar. Je ziet dubbele labels, onduidelijke parent-keuzes en trage formulier-rebuilds.

Een goede AJAX-menu-selectiestroom voelt bijna saai aan. De redacteur begint een deel van een titel te typen. Drupal geeft een korte lijst met mogelijke parent-links terug, bij voorkeur met genoeg context om identieke titels van elkaar te onderscheiden. De redacteur kiest er één. Het formulier slaat de geselecteerde menulink achter de schermen op. Geen gigantische selectielijst. Geen volledige boom-render. Geen browser-meltdown.

Hetzelfde patroon werkt voor uitklapbare takken. Toon eerst het hoogste niveau. Wanneer de redacteur een parent opent, haal je de children van die parent op. Als hij nog een child opent, haal je het volgende niveau op. Zo hoort de UI zich te gedragen wanneer de dataset groot is: kleine request, kleine response, duidelijke volgende actie.

Bij 10.000 menu-items: stop met vooruit laden

Zodra een menu iets van 10.000 items bereikt, denk ik er niet meer over als een normaal Drupal-menu. Technisch gezien is het nog steeds een menu. Operationeel lijkt het meer op een contentindex met een boomvorm.

De veelgemaakte fout is beginnen bij de root, de hele boom laden, het actieve pad uitklappen en daarna het grootste deel van het resultaat weggooien. Dat werkt bij kleine menu’s. Bij een enorm menu is het achterstevoren.

De betere aanpak die ik gebruikte, was achterwaarts laden. Begin met de actieve menulink voor de huidige pagina. Laad van daaruit alleen de parents. Dat geeft je het actieve pad zonder Drupal te vragen elke niet-gerelateerde tak te bouwen. Drupal’s menu-API’s ondersteunen deze bewegingsrichting: de menu link manager kan links op basis van route vinden en geeft ook parent-ID’s vrij voor een menu link plugin. https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21MenuActiveTrail.php/11.xhttps://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/9https://api.drupal.org/api/drupal/core%21lib%21drupal%21core%21menu%21menulinkmanagerinterface.php/function/menulinkmanagerinterface%3A%3Agetparentids/9

Dit verandert het kostenprofiel volledig. Een enorm menu kan 10.000 items hebben, maar het actieve pad voor een pagina is meestal kort. Misschien vijf niveaus. Misschien zeven. Zelfs een diepe catalogus heeft zelden tientallen ancestors voor één item. Dus in plaats van 10.000 links te laden om één pad te vinden, laad je het actieve item en loop je omhoog.

Daarna kun je bepalen hoeveel omliggende navigatie de pagina echt nodig heeft. Soms is het parent-pad genoeg. Soms heb je ook de children van het actieve item nodig. Soms heb je siblings op één niveau nodig voor een sectiemenu. Prima. Laad die slices bewust. Laat “we hebben navigatie nodig” niet stilletjes veranderen in “laad de hele boom bij elke request”.

Drupal’s menuboomsysteem denkt al in termen van tree parameters, active trails en transformaties. De gebruikelijke aanpak voor het laden van bomen kan links langs het huidige actieve pad uitklappen, wat nuttig is bij normale menu’s. https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21MenuLinkTreeInterface.php/interface/MenuLinkTreeInterface/8.2.xhttps://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21MenuLinkTreeInterface.php/interface/MenuLinkTreeInterface/8.2.x Bij een zeer groot menu ben ik echter liever strenger. Vind eerst de actieve link. Laad daarna de parents. Laad vervolgens alleen de tak die nodig is voor de huidige pagina.

De echte onderhoudsregel: laat redacteuren nooit betalen voor het hele menu

Enorme Drupal-menu’s zijn niet alleen een renderingprobleem. Ze zijn een redactioneel probleem, een probleem bij het bouwen van formulieren, een cacheprobleem en soms een informatiearchitectuurprobleem dat iemand drie jaar heeft uitgesteld.

BigMenu helpt redacteuren met grote bomen te werken zonder alles tegelijk te openen. https://www.drupal.org/project/bigmenuhttps://www.drupal.org/project/bigmenu Menu Select maakt parent-selectie draaglijk, vooral met autocomplete. https://www.drupal.org/project/menu_selecthttps://www.drupal.org/project/menu_select AJAX-selectie voorkomt dat formulieren duizenden keuzes voorbereiden voordat de redacteur de eerste betekenisvolle klik heeft gedaan. https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-formshttps://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms

Voor front-end navigatie is achterwaarts laden het deel dat ik het meest agressief zou beschermen. Begin bij de actieve menulink. Laad alleen parents. Voeg children of siblings alleen toe wanneer het ontwerp ze echt nodig heeft. Die ene gewoonte voorkomt dat een menu met 10.000 items elke request in een straf verandert.

De browser zou nooit het hele menu hoeven te dragen alleen omdat één pagina moet weten waar die zich bevindt.