Handlebars.js: اقتراح ميزة | مساعدات متزامنة / غير متزامنة

تم إنشاؤها على ٢٣ يناير ٢٠١٤  ·  24تعليقات  ·  مصدر: handlebars-lang/handlebars.js

تسجيل المساعد على أنه Sync أو Async ، فإنه يساعد على الاستماع إلى عمليات الاسترجاعات والحصول على البيانات من رد الاتصال.

التعليق الأكثر فائدة

سأقوم بتجربة Express-hbs - لكنني أعتقد أنه في عام 2018 سيكون من الغريب عدم دعمه. أعلم أن هناك وجهة نظر خالصة مفادها أن الأشياء غير المتزامنة لا ينبغي إجراؤها كجزء من العرض ولكن بدلاً من ذلك في شيء سحري يسمى وحدة التحكم (كما لو كان MVC "صحيحًا" بشكل لا يقبل الجدل) - ولكن هذا قصير النظر قليلاً لمفتاحين أسباب

أ) المكتبات الخارجية - معظم الناس الآن يكتبون بالكامل بدون مزامنة / انتظار - أعتقد في الكود الخاص بي أن أكثر من 9 وظائف من أصل 10 وظائف غير متزامنة ... في بعض الحالات "فقط في حالة". يعني عدم دعم وظيفة غير متزامنة أن جميع المكتبات غير المتزامنة فجأة يتعذر الوصول إليها تمامًا

ب) وظائف تحكم عامة. أود أن أزعم أن شيئًا كهذا:

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

أقصر وأنظف وأسهل في الصيانة ومتفوق بشكل أساسي بكل طريقة يمكن تصورها عند مقارنتها بوظيفة تحكم مخصصة تلتصق بهذه الأشياء في متغير وتمررها إلى قالب ، والذي يجب على القالب بعد ذلك معرفته والوصول إليه.

ال 24 كومينتر

حدث هذا في الماضي لكننا لم نتخذ إجراءً حيال ذلك لأن حالة الاستخدام لم تكن واضحة. نظرًا لأن المقاود لا يزال يتعين عليها الانتظار حتى تتوفر جميع البيانات لتقديم التقييم غير المتزامن ، فهو ببساطة وسيلة راحة لشيء يمكن للكود الذي ينشئ السياق القيام به بطريقة أكثر فاعلية.

إن إضافة التقييم غير المتزامن في هذه المرحلة سيكون مكلفًا للغاية من حيث التوافق وأداء وقت التشغيل الذي لا أرى فيه حالة استخدام في الوقت الحالي. هل لديك مثال ملموس لما تحاول القيام به؟

أتفق مع مشكلات الأداء ، لكنني أعتقد أنه سيكون أفضل ، إذا كان بإمكاننا جعله aysnc اختياريًا ، على سبيل المثال ، RegisterHelper & RegisterHelperAsync أو أي شيء من هذا القبيل.

في الواقع ، فكرت في هذه المقاود غير المتزامنة ، أثناء عملي مع node.js. أنا أعمل على بعض التطبيقات باستخدام express.js ومحرك النموذج الذي أستخدمه هو المقاود. لذلك ، إذا كنت بحاجة إلى الحصول على بعض القيمة من استدعاء قاعدة البيانات ، أثناء تجميع العرض ، فلن يكون ذلك ممكنًا مع هذا العمل المتزامن ،

فمثلا،

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 ، عند تضمين عمليات البحث في قاعدة البيانات في إنشاء العرض ، تظهر فكرة فصل MVC بالكامل في النافذة. أعتقد أنك تجادل بأنك قد لا تعرف أنك بحاجة إلى البيانات حتى يتم تقديم العرض ، ولكن بالنسبة لي ، يقترح ذلك الوظائف التي يجب تنفيذها على مستوى وحدة التحكم بدلاً من إنشاء العرض الخاص بك. بالاقتران مع اعتبارات الأداء التي ذكرها kpdecker ، يبدو أن المساعدين غير المتزامنين على خطأ. - 2 ج

لقد استخدمت هذا المثال للتو للتعبير عن مشكلتي. وأنا لا أحاول الجدال ، لكني قدمت اقتراحًا. آمل أن يساعدنا إذا استدعينا دالة مع رد اتصال من المساعد. على أي حال ، شكرًا على وقتك : ) kpdeckerjwilm

في هذه المرحلة ، يتمثل موقف المشروع في أنه يجب إجراء تحليل البيانات قبل استدعاء النموذج. خارج منطق العمل داخل أو خارج اهتمامات القالب ، يعد القرار غير المتزامن أكثر من سلوك الأداة المساعدة الذي تكون المكتبات الأخرى مثل غير المتزامن أكثر ملاءمة للتعامل معه.

أريد أن أعلق على شيء ما. على الرغم من أنها ستطرح من النافذة مثال قاعدة البيانات ، فقد يكون هذا مفيدًا حقًا للقوالب الطفرية. على سبيل المثال ، نموذج يحتوي على "عروض فرعية" بداخله ، ولا تريد تقسيمه إلى عدة نماذج أخرى. أريد فقط تحديث جزء في العرض ، ولدي منطق بسيط لذلك ، بدلاً من إعادة رسم العرض بالكامل (تأثير الخفقان) أو جعل وحدة التحكم الخاصة بي لبناء كل شيء لكل هذه "العروض المصغرة"

ما رأيك؟

tomasdev يعني ذلك :)

تتوفر هذه الميزة في العقدة مع express إذا كنت تستخدم https://github.com/barc/express-hbs. ومع ذلك ، فإن الإصدار غير المتزامن من المساعدين لا يلعب بشكل جيد مع التعبيرات الفرعية وبعض حالات الحافة الأخرى.

أود أن أرى هذه الميزة معاد النظر فيها لتضمينها في المقاود ، أو على الأقل ضع في اعتبارك كيف يمكن أن يدعم المقود الأساسي هذا النوع من الامتداد بشكل أفضل.

أعتقد أن Ghost يوضح حالة استخدام واضحة وصالحة (على الرغم من أنها قد تكون غير شائعة) للمساعدين غير المتزامنين ، لأن طبقة العرض الخاصة بنا قابلة للتخصيص.

في الواجهة الأمامية ، يتم توفير جميع قوالب Ghost بواسطة السمة. الموضوع عبارة عن طبقة رقيقة جدًا من المقاود و CSS والعميل JS ، والبيانات الوحيدة التي يمكنه الوصول إليها هي تلك التي نقدمها مسبقًا. ليس لديه حق الوصول إلى وحدة تحكم أو أي سلوك لتغيير المنطق. هذا متعمد جدا

من أجل توسيع واجهة برمجة تطبيقات السمة ، نريد البدء في إضافة مساعدين يحددون مجموعات بيانات إضافية قد يرغب الموضوع في الاستفادة منها. على سبيل المثال شيء مثل:

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

يحتوي Ghost على واجهة برمجة تطبيقات JSON والتي تتوفر داخليًا وخارجيًا. لذا فإن طلب الجلب هذا سيعين وظيفة علامات التصفح الخاصة بنا. لا يحتاج إلى استخدام ajax / http لجميع نقاط النهاية ، وبدلاً من ذلك ، يمكن للمساعد غير المتزامن جلب هذه البيانات من واجهة برمجة التطبيقات داخليًا والاستمرار في العمل كالمعتاد.

لا أجادل في أن هذه حالة استخدام شائعة ، وأوافق على أنها تخرق نموذج MVC القياسي ، لكنني أعتقد أنها صالحة ومفيدة.

ErisDS أخبار سارة! وأنا أيضًا لا أجادل في أن مشكلتها الشائعة ، لكنها تساعد.

تجدر الإشارة في هذه الحالة ، إلى أن العديد من العمليات التي نستخدمها حاليًا مساعدين غير متزامنين من أجلها متزامنة تحت الغطاء ، لكنها منظمة على أنها وعود.

لإعطاء مثال مفصل ...

يتم الوصول إلى جميع البيانات الموجودة في Ghost عبر واجهة برمجة تطبيقات داخلية. يتضمن هذا معلومات عالمية مثل الإعدادات. وصلت الطلبات إلى واجهة برمجة التطبيقات للإعدادات إلى ذاكرة تخزين مؤقت مملوءة مسبقًا في الذاكرة قبل الوصول إلى قاعدة البيانات ، لذلك نحن في الواقع نعيد متغيرًا فقط ، ولكن من خلال هيكلة هذا كتعهد ، من السهل الانتقال إلى قاعدة البيانات إذا احتجنا إلى ذلك.

كما يضمن أيضًا تناسق كل شيء - وإلا ستكون واجهة برمجة التطبيقات للإعدادات متزامنة ، وستكون جميع طلبات البيانات الداخلية الأخرى غير متزامنة ، وهو أمر لا معنى له.

أعلم أن هيكلة كل شيء بالوعود يمكن أن يكون مربكًا للغاية في البداية ، لكن من بين تلك الأشياء التي لا تفهمها كيف عشت بدونها بمجرد أن تحصل عليها. مع وجود المولدات في ES6 ، سيتم دعم الدقة غير المتزامنة للوظائف في JavaScript - وهذه المشكلة المماثلة: https://github.com/wycats/handlebars.js/issues/141 يذكر أنه سيكون من الجيد عمل المقاود العمل مع العائد.

لست متأكدًا من كيفية تأثير الإصدار القادم من أشرطة HTML على هذا ، لكنني أعتقد أنه يتطلب على الأقل مزيدًا من المناقشة.

ركض في حالة استخدام أخرى أثناء محاولة إنشاء مساعد لدقة التحكم في الوصول. هذا من شأنه أن يتناسب بشكل جيد مع القوالب الخاصة بي:

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

لكن طريقة isAllowed الفعلية من node-acl غير متزامنة (تسمح لقاعدة البيانات الخلفية على سبيل المثال).

الحل هو جلب جميع أذونات المستخدم مسبقًا ( المسموح بها ) ، ولكن هذا نوع من الحكة

kpdecker هل من أفكار أخرى حول حالات الاستخدام هذه؟

ErisDS أنا أفهم الرغبة هنا ولكني أشك بشدة في أن هذا سوف يصل إلى اللغة في رد الاتصال أو شكل الوعود. هذا شيء يصعب جدًا القيام به بشكل نظيف من منظور واجهة برمجة التطبيقات ويتطلب منا بشكل فعال إعادة كتابة أجزاء كبيرة من محرك القالب لدعمه. توصيتي هي أن يتم التعامل مع كل هذا قبل أن يتم إدخال دورة العرض بواسطة نموذج المنبع / مصدر البيانات.

تعتبر فكرة العائد فكرة مثيرة للاهتمام ، ولكن إذا أراد شخص ما إلقاء نظرة على ما هو مطلوب هناك ، فسيكون هذا مشروعًا بحثيًا رائعًا ، لكن دعم المتصفح لذلك يبدو بعيدًا جدًا بالنسبة لي وأنا بصراحة لم أتلاعب به أي من هذه الميزات حتى الآن في أي من مشاريعي.

فقط سنتان (حسنًا ، زوجان) قد ترغب في التفكير فيهما:

  • MVC ليس مقدسًا. الأشياء ليست خاطئة لمجرد أنها تبدو متناقضة مع MVC. يتعين على المرء أن يقيم ما إذا كانت البدائل لا توفر فوائد إيجابية صافية مقارنة باتباع MVC بدقة.
  • إذا طلب العرض من المتحكم البيانات ، وليس النماذج مباشرة ، فهذا لا يمثل انتهاكًا لـ MVC على أي حال ، أليس كذلك؟
  • ربما يمكن القول إن جعل المتحكم يعرف مسبقًا كل ما يحتاجه العرض هو تكرار المعلومات (أي أن المعلومات "X ، Y ، Z ، W ضرورية" يتم تكرارها في المشاهدات ووحدات التحكم.) بعبارة أخرى ، قد تكون الممارسة انتهاكًا لمبدأ DRY ، وهو أكثر أهمية من MVC، imo.
  • قد يتم تعويض أداء المساعدين غير المتزامنين لأغراض تحميل النماذج الضرورية فقط للعروض التي يتم تقديمها بسهولة عن طريق تحميل بيانات أقل من قاعدة البيانات.

قد أكون قادرًا على تقديم مثال أفضل حيث سيكون من المفيد الحصول عليه.

نحن نعمل كثيرًا مع كوردوفا لتطبيقات الهاتف المحمول ونحتاج إلى الترجمة للعديد من اللغات. تقدم كوردوفا وظائف للمساعدة في تنسيق التواريخ والأرقام والعملات وما إلى ذلك.
المشكلة هي أنهم جميعًا يحتاجون إلى رد اتصال غير متزامن.

مثال:

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

سيكون هذا رائعا أن يكون لديك imo.

لقد وجدت حزمة المقاود غير المتزامن في npm. لكنها أقدم قليلاً ولا أعرف ما إذا كانت تعمل مع إصدار المقاود الحالي.

لقد كتبت للتو شيئًا مشابهًا للوعود. تسمح لك المقاود الموعودة بالحزمة بإعادة الوعود من داخل المساعدين. أخطط لاستخدامه في أحد مشاريعي ، لكن حتى الآن لم يتم استخدامه في بيئة إنتاج. ولكن هناك اختبارات وحدة للعديد من حالات الحافة (مثل استدعاء المساعدين غير المتزامنين من داخل مساعدي الكتل غير المتزامنة) وكلها خضراء ...

nknapp هذا يبدو مذهلاً! يحتوي Express-hbs على دعم غير متزامن ، ويعمل غير المتزامن مع مساعدي الكتلة ، ولكن لا يعمل تداخل المساعدين غير المتزامنين - لذلك أنا مهتم حقًا برؤية هذا يعمل - يعني أنه لا يزال هناك أمل في Express-hbs: +1:

ErisDS ، هل تعتقد أنني يجب أن أنشره هناك. لم أتمكن الآن من أن express-hbs لا يمكنه التداخل غير المتزامن المساعد. تركيزي الأساسي ليس express ، لكن منشئ README الذي أعمل عليه حاليًا. سأقدر حقًا أن يقوم الآخرون بتجربته ( المقاود الموعودة ) لإبداء الملاحظات.

للإضافة إلى حالات الاستخدام الصالحة ، ماذا لو احتجت إلى جلب القيم من قاعدة بيانات الترجمة بناءً على اللغة الحالية؟

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

علاوة على ذلك ، ماذا عن إضافة كتلة CMS من إدخال قاعدة بيانات باستخدام معرف ديناميكي مثل:

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

هذا مفيد بشكل خاص للتصيير من جانب الخادم (على سبيل المثال ، استخدام المقاود السريع ).

إليك حالة استخدام أخرى: أنا أكتب منشئ توثيق لـ Swagger (اختيال بسيط ) ، والذي يسمح بتعريفات مخطط خارجي. أرغب في كتابة مساعد "Handlebars" الذي يتعرف على الوقت الذي يتم فيه تعريف المخطط خارجيًا ، وينتقل إلى عنوان URL المقدم حيث يوجد هذا المخطط ، ويسترده ، ويستخدم هذه البيانات لعرض هذا الجزء من قالب المقاود. إذا اضطررت إلى استرداد هذه البيانات قبل استدعاء طريقة التحويل البرمجي لـ Handlebars ، فسيتعين عليّ التكرار بشكل متكرر من خلال مستند JSON الذي لا أعرف هيكله مسبقًا ، والعثور على جميع مثيلات المخططات الخارجية ، واستردادها ، وإدراجها في جسون.

بشكل أساسي ، في أي وقت يتم فيه استخدام قالب المقاود لعرض بيانات مخطط JSON ( json-schema.org ) ، ستكون طريقة العرض غير المتزامن مفيدة ، لأن مخطط JSON يسمح دائمًا بتعريف الأجزاء الفرعية من المخطط خارجيًا.

dwhieb هل ألقيت نظرة على bootprint-swagger لمولد التوثيق؟ إنه تقريبًا ما تصفه (باستثناء أن المخططات الخارجية لم يتم تنفيذها بعد ، ولكن ستكون هذه ميزة رائعة). إذا كان لديك أي ملاحظات ، يرجى فتح مشكلة هناك.

وأعتقد أن المقاود الموعودة تعمل جيدًا مع المساعدين غير المتزامنين.

لدي حالة استخدام حيث تكون القدرة على استخدام الوعود في المساعدين مفيدة. أنا أستخدم المقاود لإنشاء 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 لأنه يقرأ الملف بشكل متزامن ، ولكن من الناحية المثالية يجب أن يكون قادرًا على القيام بذلك بشكل غير متزامن حتى لا يتم إبطاء عرض الصفحات بواسطة الإدخال / الإخراج. أيضًا ، القيام بذلك مع صورة في عنوان URL ، بدلاً من نظام الملفات ، أمر مستحيل.

سأبحث في استخدام المقاود الموعودة و hbs السريعة لكنني أعتقد أن القدرة على استخدام الوعود في الوظائف المساعدة ستكون إضافة رائعة إلى المقاود!

FWIW ، لقد كنت أقوم بالكثير من عرض HTML غير المتزامن باستخدام Hyperscript ، hyperscript-helpers ، ES7's async/await ، لقد كانت متعة حقيقية. لكن بالطبع ، هذا الحل يعمل فقط مع HTML. سيسمح لنا الحل غير المتزامن مع المقاود بإنشاء أنواع أخرى من الملفات بشكل غير متزامن ... ولكن بالنسبة إلى HTML ، أعتقد أنني لا أنظر إلى الوراء أبدًا!

سأقوم بتجربة Express-hbs - لكنني أعتقد أنه في عام 2018 سيكون من الغريب عدم دعمه. أعلم أن هناك وجهة نظر خالصة مفادها أن الأشياء غير المتزامنة لا ينبغي إجراؤها كجزء من العرض ولكن بدلاً من ذلك في شيء سحري يسمى وحدة التحكم (كما لو كان MVC "صحيحًا" بشكل لا يقبل الجدل) - ولكن هذا قصير النظر قليلاً لمفتاحين أسباب

أ) المكتبات الخارجية - معظم الناس الآن يكتبون بالكامل بدون مزامنة / انتظار - أعتقد في الكود الخاص بي أن أكثر من 9 وظائف من أصل 10 وظائف غير متزامنة ... في بعض الحالات "فقط في حالة". يعني عدم دعم وظيفة غير متزامنة أن جميع المكتبات غير المتزامنة فجأة يتعذر الوصول إليها تمامًا

ب) وظائف تحكم عامة. أود أن أزعم أن شيئًا كهذا:

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

أقصر وأنظف وأسهل في الصيانة ومتفوق بشكل أساسي بكل طريقة يمكن تصورها عند مقارنتها بوظيفة تحكم مخصصة تلتصق بهذه الأشياء في متغير وتمررها إلى قالب ، والذي يجب على القالب بعد ذلك معرفته والوصول إليه.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات