Mustache.js: إضافة خيار: تحذير من المتغيرات غير المعروفة

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

ربما mustache.dev.js الذي تم إنشاؤه باستخدام mustache.js وتجاوز الوظيفة التي تحتوي على منطق التحقق؟

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

لدي نموذج أولي عملي على https://github.com/ScottFreeCode/mustache.js ، على الرغم من أنه يمكنني استخدام بعض المساعدة في معرفة كيفية كتابة اختبار له.

حسنًا ، فإن استخدام وجود كائن كـ if ( {{#thing}} ) سيؤدي إلى حدوث خطأ؟ (أعتقد أن هذا شائع جدًا)

أم أن العرض الفعلي للمتغيرات فقط ( {{ id }} ) سيؤدي إلى حدوث خطأ؟ بماذا كنت تفكر؟

تحرير: ميزة رائعة جدًا أود أن أقوم بإجراء 1+ لتمكينها افتراضيًا في تخصص رئيسي في حال لم يكن الأمر متاعب.

في رأيي يجب أن يكون الأول خطأ ، والثاني "تحذير".
لكليهما أود أن أعرف أن هناك قيمة مفقودة.

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

وأيضًا ، سيكون العكس جيدًا: المتغيرات غير المستخدمة ... ولكن هذا تأثير أكبر بكثير ، على ما أعتقد! :د

في 8 تشرين الثاني (نوفمبر) 2016 ، الساعة 14:19 ، كتب David da Silva [email protected] :

حسنًا ، فإن استخدام وجود كائن على أنه إذا ({{#thing}}) سيؤدي إلى حدوث خطأ؟ (أعتقد أن هذا شائع جدًا)

أم أن العرض الفعلي للمتغيرات ({{id}}) فقط من شأنه أن يؤدي إلى حدوث خطأ؟ بماذا كنت تفكر؟

-
أنت تتلقى هذا لأنك قمت بتأليف الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub https://github.com/janl/mustache.js/issues/599#issuecomment -259133973 ، أو تجاهل الموضوع https://github.com/notifications/unsubscribe-auth/ AJ8FmSptdhysYrQpg1ODkIrm12A_TXcYks5q8HbbgaJpZM4J8lKe.

في رأيي يجب أن يكون الأول خطأ ، والثاني "تحذير".
لكليهما أود أن أعرف أن هناك قيمة مفقودة.

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

تحرير: موقفي الحالي هو أنني أفضل الخطأ في كليهما. أنا أفضل السلوكيات المتسقة ، وستفرض استخدام null للقيم الفارغة المفقودة ، وهو ما أعتقد أنه الأفضل.

وأيضًا ، سيكون العكس جيدًا: المتغيرات غير المستخدمة ... ولكن هذا تأثير أكبر بكثير ، على ما أعتقد! :د

أعتقد أنه سيكون من الرائع الحصول على مخطط البيانات التي يتوقعها القالب بطريقة ما ، واستخدامه لإنشاء استعلام GraphQL ... أو شيء مشابه.

لمزيد من التفكير ، أعتقد أن جزءًا من المشكلة هنا هو أن البيانات المفقودة غير صالحة _because_ - وبالتالي _فقط if_- القالب هو _توقع_ تلك البيانات. لذا ، فإن البيانات المفقودة التي يمكن أن يعرضها النموذج بشكل عادي هي دائمًا غير صالحة لهذا المنطق ، ولكن من الممكن تصور أن القالب في مكان ما قد يتوقع أن تكون بيانات معينة متاحة ويتفرع عنها كنوع من علامة الصواب / الخطأ (لذا فهي غير صالح إذا لم يكن خاطئًا بقدر ما هو مفقود ، وبالتالي لا يلبي هذا التوقع) ، ولكن في حالة أخرى ، قد يتوقع أن تكون البيانات متاحة أو غير متاحة وتتفرع عما إذا كانت (في هذه الحالة لن تكون غير صالحة أبدًا).

من هذا المنظور ، فإن استخدام null للتحكم في هذا الأمر لا يبدو منطقيًا بالنسبة لي:

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

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

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

ما ورد أعلاه ، على ما أعتقد ، آراء قوية ضعيفة.

تفسير IMO لقيم null أنها قيم غير موجودة هو أمر خاطئ.

{ name: null }

هذا الكائن له خاصية name ذات قيمة خاطئة ، وبالتالي يجب ألا يُنظر إليه على أنه غير صالح ، وبالتالي ليس سببًا للرمي.

قد يكون الفحص الأكثر ملاءمة هو التحقق مما إذا كان قد تم تحديد الخاصية المطلوبة كما نفعل في mustache.hasProperty () .

ولكن في حالة أخرى ، قد تتوقع أن تكون البيانات متاحة أو غير متاحة وتتفرع عما إذا كانت (في هذه الحالة لا تكون غير صالحة أبدًا).

ما كنت أحاول نقله هو أنه إذا كنت تتفرع اعتمادًا على المفتاح X (على سبيل المثال ، {{#X}} ، يجب أن تحتوي البيانات المقدمة على قيمة للمفتاح X ، إما صحيح أو قيمة زائفة ، ولكنها بالتأكيد ليست undefined .

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

لذلك ، في هذه الحالة ، سأرى فوائد في إلقاء خطأ. (محاولة التفرع على مفتاح بقيمة undefined )

في الحالة الأخرى ، محاولة عرض إما undefined أو null ، لست متأكدًا مما إذا كان هناك أي حالة استخدام لذلك. ربما يخطئ في ذلك أيضًا.

ما لم يكن قادمًا من مصدر يستخدم البيانات الفارغة المفقودة ، مثل SQL

عفيق ، فلسفة موستاش ليست استخدام النماذج كما هي ، ولكن لتوليد "عرض" منها. يمكنك إضافة null s في حال لم يقم المزود الخاص بك بطريقة ما.

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

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

إذا كانت هناك حاجة فعلاً إلى عرض بعض العناصر للمستخدم ، فعندئذٍ إذا لم يعرضها النموذج ، فهذا خطأ

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

كملاحظة: كانت حالة الاستخدام الخاصة بي عبارة عن إعداد يدوي بدون تفريع.

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

سيقول النموذج الخاص بي "{{event.name}} على {{event.date}}". في هذه الحالة ، قد تؤدي القيمة المفقودة إلى إنشاء صفحة مروعة.
كانت جميع الحقول مطلوبة ، لذا فإن إضافة منطق لعدم عرض {{event.date}} لن يكون له معنى.

في هذه الحالة ، سيكون من الرائع معرفة المتغيرات "غير المستخدمة" أيضًا ، للتحقق مرة أخرى من الأخطاء المطبعية أو للعناصر التي أضافوها معتقدين أنها ستظهر "بطريقة سحرية" على الصفحة :)

أنا متأكد من أن حالة الاستخدام هذه تنتهك أيديولوجية Moustache بطريقة ما ، لكنها سيناريو حقيقي.
وسيكون من الرائع لكلا الموقفين (القيم المفقودة + القيم غير المستخدمة) إنشاء تحذير.

في 9 تشرين الثاني (نوفمبر) 2016 ، الساعة 10:53 ، كتب David da Silva [email protected] :

ولكن في حالة أخرى ، قد تتوقع أن تكون البيانات متاحة أو غير متاحة وتتفرع عما إذا كانت (في هذه الحالة لا تكون غير صالحة أبدًا).

ما كنت أحاول نقله هو أنه إذا قمت بالتفرع اعتمادًا على المفتاح X (على سبيل المثال {{#X}} ، يجب أن تحتوي البيانات المقدمة على قيمة للمفتاح X ، إما قيمة صحيحة أو خاطئة ، ولكنها بالتأكيد ليست غير محددة.

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

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

ما لم يكن قادمًا من مصدر يستخدم البيانات الفارغة المفقودة ، مثل SQL

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

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

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

إذا كانت هناك حاجة فعلاً إلى عرض بعض العناصر للمستخدم ، فعندئذٍ إذا لم يعرضها النموذج ، فهذا خطأ

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو قم بعرضها على GitHub https://github.com/janl/mustache.js/issues/599#issuecomment -259374603 ، أو تجاهل الموضوع https://github.com/notifications/unsubscribe-auth/ AJ8FmcFicDWYjSqibyWac-Sqjg-iFetnks5q8ZgqgaJpZM4J8lKe.

أنا متأكد من أن حالة الاستخدام هذه تنتهك أيديولوجية Moustache بطريقة ما ، لكنها سيناريو حقيقي. وسيكون من الرائع لكلا الموقفين (القيم المفقودة + القيم غير المستخدمة) إنشاء تحذير.

كلاهما يبدو ممكنا. يمكن أن يكون مفيدًا لـ CI.

أفضل رؤية المعلمة مباشرة في طريقة العرض لتصحيح الأخطاء.

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

var mustache = require("mustache");

var errors = [];
var lookup = mustache.Context.prototype.lookup;

mustache.Context.prototype.lookup = function(name) {
    var value = lookup.bind(this)(name);

    if (value === undefined) {
        console.error("Unknown symbol", name);
        errors.push(name);
    }

    return value;
}

var render = mustache.render;

mustache.render = function(template, view, partials) {
    var result = render.bind(this)(template, view, partials);

    if (errors.length > 0) {
        throw {message: "Unknown symbols: " + errors.join(", ")};
    }

    return result;
}

ملحوظات:

• لا يمنحك أرقام الأسطر أو أسماء الرموز المؤهلة بالكامل
• ربما يكون الأمر غير آمن تمامًا إذا كنت تعمل في بيئة متعددة الخيوط

ومع ذلك ، فقد نجحت بشكل جيد مع أغراضي وأنا متأكد من أن شخصًا ما يمكنه تكييفها إذا لزم الأمر.

يتطلب استخدام الشارب كمحرك نموذجي في أي نوع من بيئة إدارة التكوين أخطاء جسيمة في المتغيرات المفقودة. لدي حالة استخدام مشابهة لـ steverukuts ، تحويل مستندات نشر kubernetes. المتغيرات المفقودة هي دائمًا أخطاء في حالة الاستخدام هذه.

stefaneg بعد شهرين من كتابتي ، اكتشفت في الواقع أن Terraform يدعم التكوين المكتوب بتنسيق JSON ، لذا الآن أستخدم هذا بدلاً من استخدام Moustache. هذا أفضل بكثير وأكثر قابلية للبرمجة. لقد توقفنا الآن عن استخدام Moustache لهذا الغرض وستتم إزالته في المراجعة التالية لخط أنابيب النشر الخاص بنا.

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

يرجى ملاحظة: بينما لم أعد أستخدم Moustache لأي شيء ، ما زلت أشعر أن هذا طلب ميزة صالح.

الحل هو استخدام المقاود ، التي تدعم نفس الصيغة ، ولديها أيضًا خيار صارم وهو بالضبط ما هو مطلوب في حالة الاستخدام هذه.

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

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

فيما يتعلق بالمناقشة أعلاه ؛ سوف تنفجر أيضًا على متغيرات غير معروفة.

الحل هو استخدام المقاود ، التي تدعم نفس الصيغة ، ولديها أيضًا خيار صارم وهو بالضبط ما هو مطلوب في حالة الاستخدام هذه.

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