Ինչպես պահպանել հսկայական մենյուները 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 մենյուի ընտրությունը սովորաբար ունի երկու շերտ։ Առաջին շերտը տեսանելի ընտրիչն է՝ որոնման դաշտ, ծնողի ընտրիչ կամ փոքր ընդարձակվող ճյուղ։ Երկրորդ շերտը պահպանվող արժեքն է՝ իրական մենյուի հղման plugin ID-ն կամ ծնողի հղումը, որը Drupal-ին պետք է ձևը պահպանելիս։

Այս տարբերությունը կարևոր է։ Խմբագիրները պետք է աշխատեն պիտակների, ուղիների և ծանոթ էջերի վերնագրերի հետ։ Drupal-ը պետք է պահպանի կայուն մեքենայական արժեքներ։ Երբ այս երկու մտահոգությունները խառնվում են, մեծ մենյուների վիջեթները դառնում են փխրուն։ Հայտնվում են կրկնվող պիտակներ, ծնողի անհասկանալի ընտրություններ և ձևի դանդաղ վերակառուցումներ։

Լավ AJAX մենյուի ընտրության հոսքը գրեթե ձանձրալի է թվում։ Խմբագիրը սկսում է մուտքագրել վերնագրի մի մասը։ Drupal-ը վերադարձնում է հնարավոր ծնող հղումների կարճ ցուցակ՝ ցանկալի է բավարար համատեքստով, որպեսզի նույնական վերնագրերը հնարավոր լինի տարբերել։ Խմբագիրը ընտրում է մեկը։ Ձևը հետին պլանում պահպանում է ընտրված մենյուի հղումը։ Ոչ հսկայական ընտրացանկ։ Ոչ ամբողջ ծառի render։ Ոչ բրաուզերի փլուզում։

Նույն մոտեցումը գործում է նաև ընդարձակվող ճյուղերի համար։ Նախ ցուցադրեք վերին մակարդակը։ Երբ խմբագիրը բացում է ծնող տարրը, բեռնեք այդ ծնողի երեխաները։ Եթե նա բացում է ևս մեկ երեխա, բեռնեք հաջորդ մակարդակը։ Ահա այսպես պետք է վարվի ինտերֆեյսը, երբ տվյալների հավաքածուն մեծ է՝ փոքր հարցում, փոքր պատասխան, հստակ հաջորդ գործողություն։

10,000 մենյուի տարրերի դեպքում դադարեք բեռնել առաջ

Երբ մենյուն հասնում է մոտ 10,000 տարրի, ես դադարում եմ դրա մասին մտածել որպես սովորական Drupal մենյուի։ Տեխնիկապես այն դեռ մենյու է։ Գործնականում այն ավելի մոտ է ծառաձև բովանդակության ինդեքսի։

Տարածված սխալն է սկսել արմատից, բեռնել ամբողջ ծառը, բացել ակտիվ ուղին, ապա դեն նետել արդյունքի մեծ մասը։ Դա աշխատում է փոքր մենյուների դեպքում։ Հսկայական մենյուի դեպքում դա հակառակ ուղղությամբ մտածել է։

Ավելի լավ մոտեցումը, որը ես օգտագործել եմ, հետադարձ բեռնումն էր։ Սկսեք ընթացիկ էջի ակտիվ մենյուի հղումից։ Այնտեղից բեռնեք միայն դրա ծնողներին։ Դա տալիս է ակտիվ ուղին՝ առանց Drupal-ին ստիպելու կառուցել բոլոր անկապ ճյուղերը։ Drupal-ի մենյուի API-ները աջակցում են այս ուղղությամբ շարժմանը. մենյուի հղումների կառավարիչը կարող է գտնել հղումներ ըստ route-ի, և այն նաև տրամադրում է ծնող ID-ներ մենյուի հղման plugin-ի համար։ 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

Սա ամբողջությամբ փոխում է ծախսի պրոֆիլը։ Հսկայական մենյուն կարող է ունենալ 10,000 տարր, բայց էջի ակտիվ ուղին սովորաբար կարճ է։ Գուցե հինգ մակարդակ։ Գուցե յոթ։ Նույնիսկ խորը կատալոգը հազվադեպ է ունենում տասնյակ նախնիներ մեկ տարրի համար։ Այսպիսով՝ մեկ ուղի գտնելու համար 10,000 հղում բեռնելու փոխարեն բեռնում եք ակտիվ տարրը և շարժվում դեպի վեր։

Դրանից հետո կարող եք որոշել, թե որքան շրջակա նավիգացիա է էջին իրականում պետք։ Երբեմն ծնողական ուղին բավական է։ Երբեմն պետք են նաև ակտիվ տարրի երեխաները։ Երբեմն բաժնի մենյուի համար պետք են նույն մակարդակի հարևան տարրերը։ Լավ։ Բեռնեք այդ հատվածները գիտակցաբար։ Թույլ մի տվեք, որ «մեզ նավիգացիա է պետք» արտահայտությունը լուռ վերածվի «բեռնել ամբողջ ծառը յուրաքանչյուր հարցման ժամանակ»-ի։

Drupal-ի մենյուի ծառի համակարգն արդեն մտածում է ծառի պարամետրերի, ակտիվ ուղիների և փոխակերպումների տեսանկյունից։ Ծառի բեռնման սովորական մոտեցումը կարող է բացել հղումները ընթացիկ ակտիվ ուղու երկայնքով, ինչը օգտակար է սովորական մենյուների դեպքում։ https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21MenuLinkTreeInterface.php/interface/MenuLinkTreeInterface/8.2.x Բայց շատ մեծ մենյուի դեպքում ես նախընտրում եմ ավելի խիստ լինել։ Նախ գտեք ակտիվ հղումը։ Հետո բեռնեք դրա ծնողները։ Հետո բեռնեք միայն այն ճյուղը, որը պետք է ընթացիկ էջին։

Իրական պահպանման կանոնը. երբեք մի ստիպեք խմբագիրներին վճարել ամբողջ մենյուի համար

Հսկայական Drupal մենյուները միայն render-ի խնդիր չեն։ Դրանք խմբագրական խնդիր են, ձևի կառուցման խնդիր, քեշի խնդիր և երբեմն տեղեկատվական ճարտարապետության խնդիր, որը ինչ-որ մեկը հետաձգել է երեք տարի։

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

Front-end նավիգացիայի համար հետադարձ բեռնումն այն մասն է, որը ես ամենախիստը կպաշտպանեի։ Սկսեք ակտիվ մենյուի հղումից։ Բեռնեք միայն ծնողներին։ Ավելացրեք երեխաներ կամ հարևաններ միայն այն դեպքում, երբ դիզայնին դրանք իսկապես պետք են։ Միայն այդ սովորությունը թույլ չի տալիս, որ 10,000 տարրանոց մենյուն յուրաքանչյուր հարցում վերածի պատժի։

Բրաուզերը երբեք չպետք է ստիպված լինի կրել ամբողջ մենյուն միայն այն պատճառով, որ մեկ էջը պետք է իմանա, թե որտեղ է գտնվում։