Drupal में विशाल मेनू को कैसे बनाए रखें

Menu Select Ajax: विकल्प तभी लोड करें जब एडिटर को उसकी ज़रूरत हो

autocomplete के साथ Menu Select पहले से ही बड़ा सुधार है। लेकिन बहुत बड़ी साइटों पर, बेहतर widget भी भारी हो सकता है यदि फॉर्म एडिटर के कुछ भी करने से पहले बहुत अधिक मेनू डेटा तैयार करने की कोशिश करता है। यही वह जगह है जहाँ AJAX-आधारित menu select pattern समझ में आता है।

विचार सरल है: फॉर्म को शुरुआती लोड पर विशाल मेनू के लिए पूरा parent selector नहीं बनाना चाहिए। उसे इंतज़ार करना चाहिए। जब एडिटर कोई मेनू चुनता है, search term टाइप करता है, या कोई branch खोलता है, तो Drupal एक छोटा AJAX request कर सकता है और मेनू का केवल matching हिस्सा वापस कर सकता है। Drupal की Form API AJAX-enabled form elements के माध्यम से इस pattern को support करती है, जहाँ user action server-side rebuild trigger करता है और form का केवल चुना हुआ हिस्सा बदला जाता है। https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms

व्यवहार में, AJAX menu select में आमतौर पर दो layers होती हैं। पहली layer visible selector होती है: search field, parent picker, या छोटी expandable branch। दूसरी layer stored value होती है: वास्तविक menu link plugin ID या parent reference, जिसकी Drupal को form save करते समय ज़रूरत होती है।

यह अंतर महत्वपूर्ण है। एडिटरों को labels, trails और परिचित page titles के साथ काम करना चाहिए। Drupal को stable machine values store करनी चाहिए। जब ये दो concerns आपस में मिल जाते हैं, तो बड़े menu widgets fragile हो जाते हैं। duplicate labels, unclear parent choices और slow form rebuilds दिखाई देने लगते हैं।

अच्छा AJAX menu select flow लगभग boring लगता है। एडिटर किसी title का हिस्सा टाइप करना शुरू करता है। Drupal संभावित parent links की छोटी सूची लौटाता है, बेहतर होगा कि पर्याप्त context के साथ ताकि समान titles को अलग किया जा सके। एडिटर एक चुनता है। फॉर्म selected menu link को पर्दे के पीछे store कर लेता है। कोई विशाल select list नहीं। पूरा tree render नहीं। browser meltdown नहीं।

यही pattern expandable branches के लिए भी काम करता है। पहले top level दिखाएँ। जब एडिटर कोई parent खोलता है, तो उस parent के children fetch करें। यदि वह कोई और child खोलता है, तो अगला level fetch करें। जब data set बड़ा हो, तो UI को इसी तरह व्यवहार करना चाहिए: छोटा request, छोटा response, स्पष्ट next action।

10,000 menu items पर, forward loading बंद करें

जब कोई मेनू लगभग 10,000 items तक पहुँच जाता है, तो मैं उसे सामान्य Drupal menu के रूप में सोचना बंद कर देता हूँ। तकनीकी रूप से, वह अभी भी मेनू है। संचालन के स्तर पर, वह tree shape वाले content index के अधिक करीब है।

आम गलती यह है कि root से शुरू किया जाए, पूरा tree load किया जाए, active trail expand किया जाए, और फिर result का अधिकांश हिस्सा फेंक दिया जाए। यह छोटे menus पर काम करता है। बहुत बड़े menu पर, यह उल्टा है।

बेहतर approach जो मैंने इस्तेमाल की, वह backward loading थी। वर्तमान page के active menu link से शुरू करें। वहाँ से केवल उसके parents load करें। इससे आपको active trail मिल जाता है, बिना Drupal से हर unrelated branch बनवाए। Drupal की menu APIs इस दिशा को support करती हैं: menu link manager route के आधार पर links खोज सकता है, और वह menu link plugin के लिए parent IDs भी expose करता है। 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

यह cost profile को पूरी तरह बदल देता है। एक विशाल menu में 10,000 items हो सकते हैं, लेकिन किसी page का active trail आमतौर पर छोटा होता है। शायद पाँच levels। शायद सात। गहरा catalog भी किसी एक item के लिए शायद ही दर्जनों ancestors रखता हो। इसलिए एक path खोजने के लिए 10,000 links load करने के बजाय, आप active item load करते हैं और ऊपर की ओर चलते हैं।

उसके बाद, आप तय कर सकते हैं कि page को वास्तव में कितनी surrounding navigation चाहिए। कभी-कभी parent trail पर्याप्त होता है। कभी-कभी active item के children भी चाहिए होते हैं। कभी-कभी section menu के लिए एक level पर siblings चाहिए होते हैं। ठीक है। उन slices को जानबूझकर load करें। “हमें navigation चाहिए” को चुपचाप “हर request पर पूरा tree load करो” में बदलने न दें।

Drupal का menu tree system पहले से ही tree parameters, active trails और transformations के संदर्भ में सोचता है। सामान्य tree-loading approach current active trail के साथ links expand कर सकती है, जो सामान्य menus पर उपयोगी है। https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21MenuLinkTreeInterface.php/interface/MenuLinkTreeInterface/8.2.x हालांकि, बहुत बड़े menu पर, मैं अधिक strict होना पसंद करता हूँ। पहले active link खोजें। फिर उसके parents load करें। फिर केवल वह branch load करें जिसकी current page को ज़रूरत है।

असली maintenance rule: एडिटरों से कभी भी पूरे menu की कीमत न चुकवाएँ

विशाल Drupal menus केवल rendering problem नहीं हैं। वे editorial problem हैं, form-building problem हैं, cache problem हैं, और कभी-कभी information architecture problem हैं जिसे किसी ने तीन साल तक टाल दिया था।

BigMenu एडिटरों को बड़े trees के साथ काम करने में मदद करता है, बिना सब कुछ एक साथ खोले। https://www.drupal.org/project/bigmenu Menu Select parent selection को सहन योग्य बनाता है, खासकर autocomplete के साथ। https://www.drupal.org/project/menu_select AJAX selection फॉर्मों को एडिटर के पहले meaningful click से पहले हज़ारों choices तैयार करने से रोकता है। https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms

front-end navigation के लिए, backward loading वह हिस्सा है जिसकी मैं सबसे सख्ती से रक्षा करूँगा। active menu link से शुरू करें। केवल parents load करें। children या siblings केवल तब जोड़ें जब design को वास्तव में उनकी ज़रूरत हो। यह एक आदत 10,000-item menu को हर request को सज़ा में बदलने से रोकती है।

browser को कभी भी पूरा menu ढोना नहीं चाहिए, सिर्फ इसलिए कि किसी एक page को यह जानना है कि वह कहाँ स्थित है।