Handlebars.js: फीचर सुझाव | सिंक्रोनस/एसिंक्रोनस हेल्पर्स

यह अतीत में सामने आया है लेकिन हमने इस पर कार्रवाई नहीं की क्योंकि उपयोग का मामला स्पष्ट नहीं था। चूंकि हैंडलबार्स को अभी भी तब तक इंतजार करना पड़ता है जब तक कि एसिंक मूल्यांकन प्रदान करने के लिए सभी डेटा उपलब्ध नहीं होते हैं, यह केवल उस चीज के लिए एक विश्वास है जो संदर्भ उत्पन्न करने वाला कोड अधिक कुशल तरीके से कर सकता है।

मूल रूप से इस बिंदु पर एसिंक मूल्यांकन जोड़ना संगतता और रनटाइम प्रदर्शन दोनों के मामले में काफी महंगा होगा कि मुझे अभी उपयोग के मामले में काफी कुछ नहीं दिख रहा है। क्या आपके पास एक ठोस उदाहरण है कि आप क्या करने की कोशिश कर रहे हैं?

मैं प्रदर्शन के मुद्दों से सहमत हूं, लेकिन मुझे लगता है, यह बेहतर होगा, अगर हम वैकल्पिक रूप से इसे aysnc बना सकते हैं, उदाहरण के लिए, RegisterHelper & RegisterHelperAsync, या ऐसा कुछ भी।

दरअसल, जब मैं नोड.जेएस के साथ काम करता हूं, तो मुझे इन एसिंक हैंडलबार्स के बारे में सोचना पड़ा। मैं एक्सप्रेस.जेएस का उपयोग कर कुछ अनुप्रयोगों पर काम कर रहा हूं और मैं जिस टेम्पलेट इंजन का उपयोग करता हूं वह हैंडलबार है। इसलिए, यदि मुझे दृश्य को संकलित करते समय डेटाबेस कॉल से कुछ मूल्य प्राप्त करने की आवश्यकता है, तो इस तुल्यकालिक कार्य के साथ यह संभव नहीं है,

उदाहरण के लिए,

Handlebars.registerHelper('getDbValue', function(id) {
     var Model = require('./myModel.js');
     Model.getValue(id, function(data){
           return data;
     });
});

उपरोक्त उदाहरण काम नहीं करेगा, और कुछ भी नहीं लौटाएगा। निम्नलिखित मेरी अवधारणा है। और, मुझे नहीं पता, यह पूरी तरह से सही है या इसे लागू किया जा सकता है या नहीं। एसिंक विधि के मामले में, वापसी के बजाय बस कॉलबैक फ़ंक्शन का उपयोग करना।

Handlebars.registerHelperAsync('getDbValue', function(id, callback) {
     var Model = require('./myModel.js');
     Model.getValue(id, function(data){
           callback(data);
           //or
           //callback(new Handlebars.SafeString(data)); //in case of safestring.
     });
});

मैं ऊपर की तरह अधिक मुद्दों का सामना कर रहा हूं, और मैं अपने परिदृश्य के अनुसार और उदाहरण दिखा सकता हूं, अगर कोई इस सुविधा में रूचि रखता है।

धन्यवाद

@robincsamuel , दृश्य पीढ़ी में डेटाबेस लुकअप सहित, एमवीसी अलगाव का पूरा विचार खिड़की पर जाता है। मुझे लगता है कि आप तर्क दे रहे हैं कि जब तक दृश्य प्रस्तुत नहीं किया जा रहा है, तब तक आपको यह नहीं पता होगा कि आपको डेटा की आवश्यकता है, लेकिन मेरे लिए जो कार्यक्षमता का सुझाव देता है जिसे आपके विचार को उत्पन्न करने के बजाय नियंत्रक स्तर पर लागू किया जाना चाहिए। प्रदर्शन विचारों के साथ संयुक्त @kpdecker का उल्लेख किया गया है, एसिंक हेल्पर्स सिर्फ गलत लगते हैं। -- मेरी 2सी

मैंने अपनी समस्या बताने के लिए बस उस उदाहरण का इस्तेमाल किया। और मैं बहस करने की कोशिश नहीं कर रहा हूं, लेकिन सिर्फ एक सुझाव दिया है। मुझे उम्मीद है, अगर हम हेल्पर से कॉलबैक के साथ फ़ंक्शन को कॉल करते हैं तो इससे मदद मिलेगी। वैसे भी, आपके समय के लिए धन्यवाद :) @kpdecker @jwilm

इस बिंदु पर परियोजना का रुख यह है कि टेम्प्लेट को कॉल करने से पहले डेटा रिज़ॉल्यूशन किया जाना चाहिए। टेम्पलेट चिंताओं के अंदर या बाहर व्यावसायिक तर्क के बाहर, एसिंक रिज़ॉल्यूशन उपयोगिता व्यवहार से अधिक है कि अन्य पुस्तकालय जैसे कि एसिंक्स हैंडलिंग के लिए बेहतर अनुकूल हैं।

मैं कुछ टिप्पणी करना चाहता हूं। भले ही यह खिड़की को डीबी उदाहरण से बाहर फेंक देगा, यह वास्तव में उत्परिवर्तनीय टेम्पलेट्स के लिए सहायक हो सकता है। उदाहरण के लिए, अंदर "सबव्यू" वाला एक टेम्प्लेट, और जिसे आप कई अन्य टेम्प्लेट में विभाजित नहीं करना चाहते हैं। मैं सिर्फ दृश्य में एक भाग को अद्यतन करना चाहता हूं, और उसके लिए एक सरल तर्क है, या तो मेरे पूरे दृश्य (झिलमिलाहट प्रभाव) को फिर से चित्रित करने के बजाय या मेरे नियंत्रक को इन सभी "मिनी विचारों" के लिए पूरी चीज बनाने के लिए

तुम क्या सोचते हो?

@tomasdev मेरा मतलब है कि :)

यदि आप https://github.com/barc/express-hbs का उपयोग करते हैं तो यह सुविधा एक्सप्रेस के साथ नोड में उपलब्ध कराई जाती है। हालांकि सहायकों का एसिंक संस्करण उप-अभिव्यक्तियों और कुछ अन्य किनारे के मामलों के साथ अच्छी तरह से नहीं खेलता है।

मैं इस सुविधा को हैंडलबार में शामिल करने के लिए पुनर्विचार करना चाहता हूं, या कम से कम इस बात पर विचार करना चाहता हूं कि हैंडलबार कोर इस तरह के विस्तार का बेहतर समर्थन कैसे कर सकता है।

मेरा मानना ​​​​है कि भूत एसिंक हेल्पर्स के लिए एक स्पष्ट और वैध (हालांकि शायद असामान्य) उपयोगकेस प्रदर्शित करता है, क्योंकि हमारी दृश्य परत अनुकूलन योग्य है।

फ़्रंटएंड पर, घोस्ट के सभी टेम्प्लेट थीम द्वारा प्रदान किए जाते हैं। थीम हैंडलबार्स, सीएसएस और क्लाइंट जेएस की एक बहुत पतली परत है, इसकी पहुंच केवल वही है जो हम पहले से प्रदान करते हैं। इसमें नियंत्रक या व्यवहार बदलने वाले तर्क तक पहुंच नहीं है। यह बहुत जानबूझकर किया गया है।

थीम एपीआई का विस्तार करने के लिए, हम उन सहायकों को जोड़ना शुरू करना चाहते हैं जो अतिरिक्त डेटा संग्रह को परिभाषित करते हैं जिसका उपयोग विषय करना चाहता है। उदाहरण के लिए कुछ ऐसा:

{{#fetch tags}}
.. do something with the list of tags..
{{else}}
No tags available
{{/fetch}}

घोस्ट में एक JSON API है जो आंतरिक और बाहरी दोनों तरह से उपलब्ध है। तो यह फ़ेच क्वेरी हमारे ब्राउज़ टैग फ़ंक्शन पर मैप करेगी। इसे सभी एंडपॉइंट पर AJAX/http का उपयोग करने की आवश्यकता नहीं है, इसके बजाय, एक एसिंक हेल्पर आंतरिक रूप से एपीआई से इस डेटा को प्राप्त कर सकता है और हमेशा की तरह आगे बढ़ सकता है।

मैं यह तर्क नहीं देता कि यह एक सामान्य उपयोग का मामला है, और मैं स्वीकार करता हूं कि यह मानक एमवीसी मॉडल को तोड़ता है, लेकिन मेरा मानना ​​​​है कि यह मान्य और उपयोगी है।

@ErisDS अच्छी खबर! और मैं भी यह तर्क नहीं देता कि यह सामान्य मुद्दा है, लेकिन यह मदद करता है।

इस मामले में यह ध्यान देने योग्य है, कि वर्तमान में हम जिन कई कार्यों के लिए async हेल्पर्स का उपयोग कर रहे हैं, वे हुड के नीचे सिंक्रोनस हैं, लेकिन वे वादों के रूप में संरचित हैं।

एक विस्तृत उदाहरण देने के लिए ...

घोस्ट के सभी डेटा को एक आंतरिक एपीआई के माध्यम से एक्सेस किया जाता है। इसमें सेटिंग्स जैसी वैश्विक जानकारी शामिल है। सेटिंग्स एपीआई के लिए अनुरोध डेटाबेस से टकराने से पहले एक पूर्व-आबादी-इन-मेमोरी कैश हिट करता है, इसलिए हम वास्तव में केवल एक चर वापस कर रहे हैं, लेकिन इसे एक वादे के रूप में संरचित करके डेटाबेस में जाना आसान है यदि हमें इसकी आवश्यकता है।

यह यह भी सुनिश्चित करता है कि सब कुछ सुसंगत है - अन्यथा सेटिंग्स एपीआई सिंक्रोनस होगी, और अन्य सभी आंतरिक डेटा अनुरोध एसिंक्स होंगे, जिसका कोई मतलब नहीं होगा।

मुझे पता है कि वादों के साथ सब कुछ संरचित करना पहली बार में काफी भ्रमित करने वाला हो सकता है, लेकिन यह उन चीजों में से एक है जिसे आप समझ नहीं पाते हैं कि आप इसे प्राप्त किए बिना कैसे रहते थे। ES6 में आने वाले जनरेटर के साथ, कार्यों के अतुल्यकालिक संकल्प के लिए समर्थन जावास्क्रिप्ट में बेक किया जाएगा - और इसी तरह की समस्या: https://github.com/wycats/handlebars.js/issues/141 में उल्लेख किया गया है कि हैंडलबार बनाना अच्छा होगा उपज के साथ काम करें।

मुझे यकीन नहीं है कि एचटीएमएलबार की आने वाली रिलीज इस पर कैसे असर डाल सकती है, लेकिन मुझे लगता है कि यह कम से कम आगे की चर्चा की गारंटी देता है।

एसीएल संकल्प के लिए एक सहायक बनाने की कोशिश करते समय एक और उपयोग के मामले में भाग गया। यह मेरे टेम्पलेट्स में अच्छी तरह फिट होगा:

        {{#allowedTo 'edit' '/config'}}
            <li>
                <a href="/config">Config</a>
            </li>
        {{/allowedTo}}

लेकिन वास्तविक isAllowed विधि नोड-एसीएल से अतुल्यकालिक है (उदाहरण के लिए डेटाबेस बैकएंड की अनुमति देता है)।

सभी उपयोगकर्ता अनुमतियों को पहले से लाने के लिए एक समाधान है ( अनुमत अनुमतियां), लेकिन यह थोड़ी खुजली है

@kpdecker इन उपयोग मामलों पर कोई और विचार?

@ErisDS मैं यहां इच्छा को समझता हूं लेकिन मुझे गंभीर संदेह है कि यह कभी भी इसे कॉलबैक या वादे के रूप में भाषा में बना देगा। यह कुछ ऐसा है जो एपीआई के नजरिए से सफाई से करना बहुत कठिन है और प्रभावी रूप से हमें इसका समर्थन करने के लिए टेम्पलेट इंजन के बड़े हिस्से को फिर से लिखने की आवश्यकता है। मेरी सिफारिश है कि यह सब अपस्ट्रीम मॉडल/डेटा स्रोत द्वारा प्रतिपादन चक्र में प्रवेश करने से पहले संभाला जाए।

उपज विचार एक दिलचस्प है, लेकिन अगर कोई यह देखना चाहता है कि वहां क्या आवश्यक होगा, तो यह एक अद्भुत शोध परियोजना होगी, लेकिन इसके लिए ब्राउज़र समर्थन मुझे बहुत दूर लगता है और मैंने ईमानदारी से गड़बड़ नहीं की है मेरी किसी भी परियोजना पर अभी तक उन सुविधाओं में से कोई भी।

बस मेरे "दो" (ठीक है, युगल) सेंट जिन पर आप विचार करना चाहेंगे:

• एमवीसी पवित्र नहीं है। चीजें गलत नहीं हैं क्योंकि वे एमवीसी के विपरीत प्रतीत होते हैं। किसी को यह मूल्यांकन करना होगा कि क्या विकल्प एमवीसी का सख्ती से पालन करने पर शुद्ध सकारात्मक लाभ प्रदान नहीं करते हैं।
• यदि दृश्य डेटा के लिए नियंत्रक से पूछता है, सीधे मॉडल नहीं, यह वैसे भी एमवीसी का उल्लंघन नहीं है, है ना?
• यह शायद तर्क दिया जा सकता है कि नियंत्रक को पहले से ही सब कुछ पता होना चाहिए जो दृश्य की आवश्यकता होगी सूचना का दोहराव है (यानी जानकारी "एक्स, वाई, जेड, डब्ल्यू आवश्यक हैं" विचारों और नियंत्रकों में डुप्लिकेट है।) दूसरे शब्दों में, हमारे वर्तमान अभ्यास डीआरवाई सिद्धांत का उल्लंघन हो सकता है, जो एमवीसी, आईएमओ से कहीं अधिक महत्वपूर्ण है।
• केवल प्रस्तुत किए जा रहे विचारों के लिए आवश्यक मॉडल लोड करने के प्रयोजनों के लिए एसिंक्रोनस हेल्पर्स के प्रदर्शन हिट को डेटाबेस से कम डेटा लोड करके आसानी से मुआवजा दिया जा सकता है।

मैं एक बेहतर उदाहरण पेश करने में सक्षम हो सकता हूं जहां यह उपयोगी होगा।

हम मोबाइल एप्लिकेशन के लिए कॉर्डोवा के साथ बहुत काम करते हैं और कई भाषाओं के लिए स्थानीयकरण की आवश्यकता होती है। कॉर्डोवा तिथियों, संख्याओं, मुद्राओं आदि को प्रारूपित करने में सहायता के लिए कार्य प्रदान करता है।
समस्या यह है कि उन सभी को एसिंक कॉलबैक की आवश्यकता होती है।

उदाहरण:

Handlebars.registerHelper('stringToNumber', function(string, type)
{
    type = type || 'decimal';
    navigator.globalization.stringToNumber(string, function(number)
    {
        return number;
    }, function()
    {
        return NaN;
    }, {
        type: type
    });
});

यह आईएमओ होना बहुत अच्छा होगा।

मुझे npm पर हैंडलबार्स-एसिंक पैकेज मिला है। लेकिन यह थोड़ा पुराना है और मुझे नहीं पता कि यह वर्तमान हैंडलबार-संस्करण के साथ काम करता है या नहीं।

मैंने भी अभी-अभी वादों के लिए कुछ ऐसा ही लिखा है। पैकेज का वादा-हैंडलबार आपको मददगारों के भीतर से वादे वापस करने की अनुमति देता है। मैं इसे अपनी परियोजनाओं में से एक में उपयोग करने की योजना बना रहा हूं, लेकिन अभी तक इसका उत्पादन वातावरण में उपयोग नहीं किया गया है। लेकिन कई किनारे-मामलों के लिए यूनिट परीक्षण हैं (जैसे एसिंक-हेल्पर्स को एसिंक ब्लॉक-हेल्पर्स के भीतर से कॉल करना) और वे सभी हरे हैं ...

@nknapp जो आश्चर्यजनक लगता है! एक्सप्रेस-एचबीएस में एसिंक समर्थन है, और एसिंक ब्लॉक हेल्पर्स के लिए काम करता है, लेकिन एसिंक हेल्पर्स नेस्टिंग काम नहीं करता है - इसलिए मुझे यह काम करने में वास्तव में दिलचस्पी है - इसका मतलब है कि एक्सप्रेस-एचबीएस के लिए अभी तक आशा है: +1:

@ErisDS , क्या आपको लगता है कि मुझे इसे वहां पोस्ट करना चाहिए। मैंने अब ऐसा नहीं किया था कि express-hbs async हेल्पर को नेस्ट नहीं कर सकता था। मेरा प्राथमिक ध्यान express नहीं है, बल्कि एक रीडमे-जनरेटर है जिस पर मैं वर्तमान में काम कर रहा हूं। मैं वास्तव में अन्य लोगों की कोशिश करने के लिए सराहना करता हूं ( वादा-हैंडलबार ) प्रतिक्रिया दें।

वैध उपयोग के मामलों में जोड़ने के लिए, क्या होगा यदि आपको वर्तमान लोकेल के आधार पर अनुवाद डीबी से मूल्य प्राप्त करने की आवश्यकता है?

<div class="howItWorks">
    {{{i18nFetch id=how-it-works locale=locale}}}
</div>

इसके अलावा, एक गतिशील आईडी का उपयोग करके डीबी प्रविष्टि से सीएमएस ब्लॉक जोड़ने के बारे में क्या:

<div class="searchCms">
    {{{cmsLoader 'search-{$term}' term=params.input defaultId='search-default'}}}
</div>

यह सर्वर-साइड रेंडरिंग (यानी एक्सप्रेस-हैंडलबार का उपयोग करके) के लिए विशेष रूप से उपयोगी है।

यहां एक और उपयोग का मामला है: मैं स्वैगर ( सरल-स्वैगर ) के लिए एक दस्तावेज़-जनरेटर लिख रहा हूं, जो बाहरी स्कीमा परिभाषाओं की अनुमति देता है। मैं एक हैंडलबार सहायक लिखना चाहता हूं जो यह पहचानता है कि स्कीमा को बाहरी रूप से परिभाषित किया गया है, प्रदान किए गए यूआरएल पर जाता है जहां वह स्कीमा रहता है, इसे पुनर्प्राप्त करता है, और हैंडलबार्स टेम्पलेट के उस हिस्से को प्रस्तुत करने के लिए उस डेटा का उपयोग करता है। यदि मुझे हैंडलबार की संकलन विधि को कॉल करने से पहले इस डेटा को पुनः प्राप्त करना पड़ा, तो मुझे एक JSON दस्तावेज़ के माध्यम से पुनरावर्ती रूप से पुनरावृति करना होगा, जिसकी संरचना मुझे पहले से नहीं पता है, बाहरी स्कीमा के सभी उदाहरण खोजें, उन्हें पुनः प्राप्त करें, और उन्हें सम्मिलित करें जेएसओएन।

मूल रूप से, किसी भी समय JSON स्कीमा डेटा ( json-schema.org ) को प्रस्तुत करने के लिए एक हैंडलबार टेम्पलेट का उपयोग किया जाता है, एक async रेंडर विधि उपयोगी होगी, क्योंकि JSON स्कीमा हमेशा एक स्कीमा के उप-भागों को बाहरी रूप से परिभाषित करने की अनुमति देता है।

@dwhieb क्या आपने दस्तावेज़-जनरेटर के लिए बूटप्रिंट-स्वैगर पर एक नज़र डाली है? यह लगभग वही है जो आप वर्णन करते हैं (सिवाय इसके कि बाहरी स्कीमा अभी तक लागू नहीं किए गए हैं, लेकिन यह एक बड़ी विशेषता होगी)। यदि आपके पास कोई प्रतिक्रिया है, तो कृपया वहां एक समस्या खोलें।

और, मुझे लगता है कि वादा-हैंडलबार एसिंक हेल्पर्स के साथ काफी अच्छा काम करता है।

मेरे पास एक उपयोग का मामला है जहां सहायकों में वादों का उपयोग करने में सक्षम होना उपयोगी होगा। मैं अपने ब्लॉग के लिए HTML जेनरेट करने के लिए हैंडलबार का उपयोग कर रहा हूं। प्रत्येक लेख के लिए मान्य संरचित डेटा बनाने के लिए, मुझे उन आयामों को प्राप्त करने की आवश्यकता है जिनका मैं लेख छवि के लिए उपयोग कर रहा हूं। अभी, मैं इसे इस तरह कर रहा हूँ:

{{#imageSize post.frontMatter.previewImage}}
  <div itemprop="image" itemscope itemtype="https://schema.org/ImageObject">
    <meta itemprop="url" content="{{#staticResource ../post.frontMatter.previewImage}}{{/staticResource}}">
    <meta itemprop="width" content="{{width}}">
    <meta itemprop="height" content="{{height}}">
  </div>
{{/imageSize}}

imageSize सहायक काम करता है क्योंकि यह फ़ाइल को समकालिक रूप से पढ़ता है, लेकिन आदर्श रूप से इसे एसिंक्रोनस रूप से करने में सक्षम होना चाहिए ताकि पृष्ठों को प्रस्तुत करना I/O द्वारा धीमा न हो। साथ ही, फ़ाइल सिस्टम के बजाय किसी URL पर छवि के लिए ऐसा करना असंभव है।

मैं वादा किए गए हैंडलबार और एक्सप्रेस-एचबीएस का उपयोग करने पर ध्यान दूंगा लेकिन मुझे लगता है कि सहायक कार्यों में वादों का उपयोग करने की क्षमता हैंडलबार के लिए एक बढ़िया अतिरिक्त होगी!

एफडब्ल्यूआईडब्ल्यू, मैं हाइपरस्क्रिप्ट, hyperscript-helpers , ES7 के async/await का उपयोग करके बहुत से अतुल्यकालिक HTML प्रतिपादन कर रहा हूं, और यह एक वास्तविक आनंद रहा है। लेकिन निश्चित रूप से, वह समाधान केवल HTML के लिए काम करता है। हैंडलबार के साथ एक एसिंक समाधान हमें अन्य प्रकार की फाइलों को अतुल्यकालिक रूप से उत्पन्न करने देगा... हालांकि एचटीएमएल के लिए मुझे लगता है कि मैं कभी पीछे मुड़कर नहीं देख रहा हूं!

एक्सप्रेस-एचबीएस एक कोशिश देने जा रहा हूं - लेकिन मुझे लगता है कि 2018 में इसका समर्थन नहीं करना एक अजीब बात है। मुझे पता है कि एक शुद्ध दृष्टिकोण है कि एसिंक सामान दृश्य के हिस्से के रूप में नहीं किया जाना चाहिए बल्कि इसके बजाय नियंत्रक नामक कुछ जादुई चीज में किया जाना चाहिए (जैसे कि एमवीसी किसी भी तरह से "सही" है) - लेकिन यह दो कुंजी के लिए थोड़ा छोटा है कारणों

ए) बाहरी पुस्तकालय - ज्यादातर लोग अब पूरी तरह से एसिंक/प्रतीक्षा के साथ लिख रहे हैं - मुझे लगता है कि मेरे कोड में 10 में से 9 से अधिक फ़ंक्शन एसिंक हैं ... कुछ मामलों में "बस मामले में"। async फ़ंक्शन का समर्थन नहीं करने का अर्थ है कि सभी async लाइब्रेरी अचानक पूरी तरह से दुर्गम हैं

बी) सामान्य नियंत्रक कार्य। मैं तर्क दूंगा कि ऐसा कुछ:

    {{#query "select name, total from summary"}}
          <tr><td>{{this.name}}</td><td>{{this.total}}</td></tr>
    {{/query}}

छोटा, साफ-सुथरा, बनाए रखने में आसान, और मूल रूप से हर बोधगम्य तरीके से बेहतर होता है, जब एक बीस्पोक कंट्रोलर फ़ंक्शन के साथ तुलना की जाती है जो उस सामान को एक चर में चिपका देता है और इसे एक टेम्प्लेट में पास कर देता है, जिसके बारे में टेम्प्लेट को जानना और एक्सेस करना होता है।