شكرًا جزيلاً على التقرير mbrodala ، هذه الشفرات محل تقدير كبير!

mbrodala شكرا على codepens.
أتساءل عما إذا كان هناك سوء فهم هنا.

يعمل كل من 643 و 664 على إصلاح الخلل الذي أبلغت عنه في # 617 ، والذي يتضح من خلال هذا الاختبار المصاحب للرقم 643:

  describe('when parsing a template with tags specified followed by the same template with different tags specified', function() {
     it('returns different tokens for the latter parse', function() {
       var template = "(foo)[bar]";
       var parsedWithParens = Mustache.parse(template, ['(', ')']);
       var parsedWithBrackets = Mustache.parse(template, ['[', ']']);
       assert.notDeepEqual(parsedWithBrackets, parsedWithParens);
     });
   });

كانت الوظيفة parse تقوم بالتخزين المؤقت باستخدام template فقط كمفتاح ذاكرة التخزين المؤقت ، بحيث في المرة التالية التي يتم فيها استخدام parse لتحليل هذا القالب ، سيعيد نفس الرموز المميزة تمامًا ، حتى إذا كانت قيمة tags المحددة مختلفة.

tags هي معلمة اختيارية ، وعندما يتم حذفها ، فإنها تعود إلى mustache.tags ، وهي افتراضيًا ['{{', '}}'] . يتم استخدام التراجع mustache.tags كجزء من مفتاح التخزين المؤقت.

أعتقد أنني أعرف ما يحدث فيما يتعلق بإصلاح الخطأ والتوقعات ، وسأحاول السير فيه ، وسأستخدم codepen كمثال.

الإصدار 2.3.0

Mustache.parse(template, ['[[', ']]']);

في 2.3.0 ، يوجه هذا Moustache إلى تحليل template ، باستخدام ['[[', ']]'] كعلامات. يقوم Moustache بذلك ويعيد النتيجة الصحيحة ، لكنه يخزن المكالمة مؤقتًا باستخدام template فقط. انظر السطور 447-450 من [email protected] :

    if (tokens == null)
       tokens = cache[template] = parseTemplate(template, tags);

المكالمة التالية في codepen هي:

var output = Mustache.render(
  template,
...

render لا يأخذ المعلمة tags ، لذلك لا يتم تمرير واحد إلى parse ، لذلك عندما يتم استدعاء parse render يستخدم $ # $ 20 $ # $ mustache.tags كعلاماتها. لذلك ، عند إجراء هذه المكالمة render ، فهي فعلاً إخبار parse ، "يُرجى تحليل template واستخدام ضمنيًا ['{{', '}}'] كـ tags . " يقوم parse بالشيء الخطأ بالفعل ويقوم بالبحث عن ذاكرة التخزين المؤقت متجاهلاً تمامًا كلاً من tags و mustache.tags . يحدث لإرجاع نتيجة تحليل القالب بـ [['[', ']']] ، لكن فقط لأن الاستدعاء الأول لـ parse في البرنامج بالكامل لهذا template تم إجراؤه بـ ['[[', ']']] كـ tags .

الإصدار 2.3.1

Mustache.parse(template, ['[[', ']]']);

يتم تخزين نتيجة التحليل مؤقتًا باستخدام كل من template و tags ، وهو ['[[', ']]'] كمفتاح تخزين مؤقت.

المكالمة التالية:

var output = Mustache.render(
  template,
...

render calls parse ، تجاوز template لكن مع حذف tags . وبالتالي ، فإن parse لديه tags يتراجع إلى mustache.tags ، والذي يظل هو ['{{', '}}'] . يُجري parse بحثًا عن ذاكرة التخزين المؤقت مقابل مفتاح ذاكرة التخزين المؤقت template و ['{{', '}}'] ، ويتعرض لفقدان ذاكرة التخزين المؤقت ، كما هو متوقع لأن parse لم يتم استدعاؤه بعد مع هذه المجموعة من template والعلامات. لذلك يوزع template باستخدام ['{{', '}}'] .

أعتقد أن الإصدار 2.3.1 يعرض السلوك الصحيح. إذا أردنا تغيير codepen في https://codepen.io/mbrodala/pen/QBJoOx قليلاً وتشغيله مقابل v2.3.0:

var template = "[[item.title]] [[item.value]]";
Mustache.parse(template, ['[[', ']]']);
var output = Mustache.render(
  template,
  {
    item: {
      title: "TEST",
      value: 1
    }
  }
);
alert(output);

الناتج هو [[item.title]] [[item.value]] ، وهو أمر غير متوقع.

أستطيع أن أرى كيف قد يكون السلوك في https://codepen.io/mbrodala/pen/NBEJjX مفاجئًا ، نظرًا لأن المكالمات Mustache.parse و Mustache.render متجاورة تمامًا وقد لا تدرك حتى أن Mustache.parse يتطلب وسيطة tags . (لماذا يأخذ Mustache.parse حتى tags وسيطة؟ لا يتم استخدامه أبدًا في أي مكان في mustache.js - parse ببساطة افتراضيًا داخليًا إلى mustache.tags . ..)

إذا كان التغيير في السلوك يتحدى بالفعل توقعات إصدار bugfix ، فأنا لست متأكدًا تمامًا مما يجب فعله. أحد الاحتمالات هو إصدار نسخة أخرى من إصلاح الأخطاء مع إرجاع # 664 ، والذي في الواقع يزيل كل سلوك التخزين المؤقت (بالنظر إلى أنه في # 643 ، ستفقد جميع عمليات البحث عن ذاكرة التخزين المؤقت). يمكننا بعد ذلك إعادة رقم 664 إلى المراجعة الرئيسية التالية. الاحتمال الآخر هو إزالة كل التخزين المؤقت في إصدار bugfix (بدلاً من تحرير mustache.js مع التخزين المؤقت غير الوظيفي) ، ثم إعادة كل التخزين المؤقت مرة أخرى في المراجعة الرئيسية التالية. من المحتمل أن يكون الخيار الأول مخاطرة أقل (أقل قدر من تغيير الكود) ولكن الخيار الأخير ربما يكون أكثر "صحة". phillipj الأفكار؟

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

لا أمانع في التغيير على الإطلاق ، ولكن نظرًا لأنه من المستحيل تمرير tags إلى Mustache.render() لضمان الحصول على ذاكرة التخزين المؤقت وأن Mustache.parse() يتم الإعلان عنه لتخزين template (بدون ذكر tags هنا) أتساءل عما إذا كان يجب حقًا التراجع عن هذا.

إذا افترضنا أن أحدهم يستدعي Mustache.parse بمجموعة مخصصة من tags يمكننا أيضًا افتراض أن template يستخدم هذه المحددات (راجع للشغل ، يجب أن تكون "العلامات" مقابل "المحددات" مسح أيضا). بعد ذلك يمكننا أن نفترض أنه من المتوقع أن تعمل المكالمة إلى Mustache.render ، بغض النظر عن كيفية تخزين المبلغ المعطى template مؤقتًا وكيفية تجميعه إذا كانت هذه هي الحالة. الآن هذا غير مضمون في حالة استخدام tags المخصص.

mbrodala نعم ، هذا منطقي ، على الرغم من أن Mustache.parse(template, ['[[', ']]']); متبوعًا بـ Mustache.parse(template, ['((', '))']); إعطاء نفس النتيجة بالضبط سيظل غير متوقع.

هنا حل وسط / حل وسط ("رجل القش" لأنني لا أحب ذلك ولكن الأمر يستحق العصف الذهني). يمكن أن يكون لدينا parse مخبأ مقابل كل من template بمفرده و template مع العلامات. عندما يتم استدعاء parse مع تحديد tags ، فإنه يقوم بالبحث عن template و tags . عندما نطلق render ، الذي يستدعي parse بدون tags ، فإننا نقوم بالبحث عن template فقط. أفكار؟

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

mbrodala هي المشكلة الأساسية التي لا يمكنك تمرير tags إلى render ؟ يمكننا أيضًا إضافة معلمة tags إلى render .

petrkoutnysw هل هذه هي المشكلة التي واجهتها أيضًا؟

إنه على الأقل عدم تناسق بين parse() و render() . لن نستخدم حتى parse() إذا تمكنا من تمرير العلامات المخصصة إلى render() بالفعل. والآن مع وجود التخزين المؤقت المناسب في المكان ، يصبح هذا أكثر وضوحًا.

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

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

شكرًا جزيلاً على هذه الإرشادات التفصيلية @ raymond-lam!

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

إعادة تقديم سلوك التخزين المؤقت مرة أخرى في الإصدار الرئيسي التالي المخطط له ، يمكننا تضمين إرشادات الترحيل في ملاحظات الإصدار.

phillipj لقد أصدرت طلب سحب رقم 670 والذي يتراجع # 643 و # 664. بدلاً من تعطيل التخزين المؤقت معًا ، من أجل التخفيف من المخاطر ، فإن العودة ببساطة إلى سلوك الإصدار 2.3.0 (في إصدار خطأ) يبدو أكثر أمانًا للمُعالين في Moustache v2.xx ، سأصدر طلب سحب آخر لإعادة التقديم في إصدار رئيسي.

يعيدphillipj # 671 تقديم إصلاحات التخزين المؤقت ، لانتظار إصدار رئيسي.

تم إنشاء العدد رقم 672 لمعالجة إضافة tags إلى `` العرض.

شكرا جزيلا للنظر في هذا وإصلاحه ، يا رفاق الصخور. 👍

رفع القبعات إلى @ raymond-lam من أجل هذا! شكرًا لك أيضًا ، من الأهمية بمكان أن نعرف متى تحدث تغييرات غير متوقعة في البرية.

تم نشر الإصدار 2.3.2 🚀