Mustache.js: Добавить вариант: Предупреждение о неизвестных переменных

Мне нравится эта функция из других фреймворков при локальной разработке, так что +1 от меня! Я думаю, что важно, чтобы это минимально или не влияло на производительность. Может быть, даже выполнимо, оставив ядро ​​как есть? Например, переопределив некоторые внутренние методы, чтобы включить такое поведение во время разработки.

Может быть, mustache.dev.js построенный с использованием mustache.js и переопределения функции, содержащей логику проверки?

Я бы предпочел жесткую ошибку, так что, например, при использовании с Express он становится ответом 500, а не просто журналом где-то, в то время как конечный пользователь видит неправильно отображенную страницу (потенциально очень неправильно отображаемую, в зависимости от того, как отсутствующий предполагалось использовать переменную); это может быть даже более полезным в производстве, чем при локальной разработке, в зависимости от того, насколько хороша ваша страница 500 по сравнению с тем, насколько плохо отображаемые страницы будут для функциональности вашего приложения. Использование разделов может позволить шаблонам игнорировать отсутствующие переменные даже с серьезными ошибками для прямого использования. И любое высокоуровневое использование, которое должно регистрировать проблему, будет контролировать систему регистрации, поэтому нам не придется беспокоиться, скажем, о том, что внутренний механизм предупреждения Mustache затирает выходные данные от участников тестирования или тому подобное.

У меня есть рабочий прототип на https://github.com/ScottFreeCode/mustache.js , хотя мне бы пригодилась помощь, чтобы разобраться, как написать для него тест.

Хм, значит, использование существования объекта как if ( {{#thing}} ) вызовет ошибку? (Думаю, это довольно часто)

Или только фактическое отображение переменных ( {{ id }} ) вызовет ошибку? О чем ты думал?

Изменить: очень крутая функция, которую я бы +1, чтобы включить по умолчанию в основном, если это не станет проблемой.

На мой взгляд, первое должно быть ошибкой, второе - «предупреждением».
Я хотел бы знать, что для обоих отсутствует значение.

Хотя во втором случае он может технически не сломаться, это может оказать огромное влияние на страницу.

Кроме того, было бы неплохо сделать наоборот: неиспользуемые переменные ... Но я думаю, это гораздо больше! : D

8 ноября 2016 года в 14:19 Давид да Силва [email protected] написал:

Хм, значит, использование существования объекта как if ({{#thing}}) вызовет ошибку? (Думаю, это довольно часто)

Или только фактическое отображение переменных ({{id}}) вызовет ошибку? О чем ты думал?

-
Вы получаете это, потому что вы являетесь автором темы.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/janl/mustache.js/issues/599#issuecomment -259133973 или отключите поток https://github.com/notifications/unsubscribe-auth/ AJ8FmSptdhysYrQpg1ODkIrm12A_TXcYks5q8HbbgaJpZM4J8lKe.

На мой взгляд, первое должно быть ошибкой, второе - «предупреждением».
Я хотел бы знать, что для обоих отсутствует значение.

@MatthijsZw Понятно . Я только что вспомнил, что для свойства можно сохранить значение null , что было бы неплохо, и поэтому исключений не возникнет. (особо отмечая это для случая if )

Изменить: Моя текущая позиция заключается в том, что я бы предпочел ошибиться в обоих. Я предпочитаю последовательное поведение, и вы бы принудительно использовали null для пустых и отсутствующих значений, что я считаю предпочтительным.

Кроме того, было бы неплохо сделать наоборот: неиспользуемые переменные ... Но я думаю, это гораздо больше! : D

Я думаю, что было бы круто получить схему для данных, которые ожидает шаблон, и использовать ее для создания запроса GraphQL ... или чего-то подобного.

При дальнейшем размышлении, я думаю, что отчасти проблема здесь в том, что отсутствующие данные недействительны _because_ - и, следовательно, _only if_ - шаблон _ ожидает_ этих данных. Таким образом, отсутствующие данные, которые шаблон будет просто отображать, всегда недействительны по этой логике, но вполне возможно, что шаблон может в одном месте ожидать, что определенные данные будут доступны, и разветвляется на них как какой-то флаг истинного / ложного (так что это недействителен, если он не столько ложен, сколько отсутствует и, следовательно, не соответствует этому ожиданию), но в другом случае он может ожидать, что данные могут быть или не могут быть доступны, и ветвится в зависимости от того, есть ли они (в этом случае он никогда не является недействительным).

С этой точки зрения использование null для управления этим не имеет для меня особого смысла:

• Если данные неверны - не соответствуют ожиданиям - как мы можем ожидать, что неправильные данные будут контролировать поведение шаблона при обработке неправильных данных?
• В любом случае ожидание действительно заложено в шаблон.
• null может быть ложным значением для ветвей по правдивости, которые ожидают данных и считают их недопустимыми из-за отсутствия данных, но это по-прежнему оставляет нам необходимость в ветвлении относительно того, были ли данные предоставлены вообще, потому что мы ожидайте, что данные могут не быть заполнены (даже с null , если только они не поступают из источника, который использует null для недостающих данных, например, SQL - и на самом деле это подсказывает, следует ли обрабатывать null как отсутствующий или не должен настраиваться в зависимости от источника данных).

Нам нужны два типа веток для разных ожиданий со стороны шаблона. Что, насколько мне известно, прискорбно, потому что спецификация Mustache, не зависящая от языка, хотя и позволяет (но не требует) конфигурировать, являются ли отсутствующие данные ошибкой, насколько я знаю, нет ничего для другого типа ветки, которая будет отличаться по этому поводу. Хм...

С другой стороны, я в настоящее время думаю, что посторонние / избыточные / неиспользуемые данные на самом деле не связаны с недействительными данными, а с тем, что шаблон недействителен, если он не использует эти данные, когда приложение / данные / модель ожидает, что он будет использоваться. То есть, если какой-то материал потенциально пригоден для использования, но шаблон может решить, является ли он актуальным, тогда не имеет значения, печатает ли шаблон этот материал, но если какой-то материал действительно _должен_ быть отображен для пользователя, то, если шаблон не ' t показать, что это ошибка. Как своего рода разворот, ожидание лежит вне шаблона (в модели?), И недействительность несоблюдения этого ожидания лежит в шаблоне. Я полагаю, что лучше всего заняться этим отдельно.

Вышесказанное, я полагаю, является сильным мнением, которого придерживаются слабо.

ИМО неправильно интерпретирует значения null как несуществующие.

{ name: null }

у этого объекта есть свойство name с ложным значением, и поэтому он никогда не должен рассматриваться как недопустимый и, следовательно, не является причиной для выброса.

Более подходящей проверкой было бы проверить, определено ли запрошенное свойство, как мы это делаем в mustache.hasProperty () .

но в другом случае можно ожидать, что данные могут быть доступны, а могут и нет, и разветвляться по тому, есть ли они (в этом случае они никогда не являются недействительными).

Я пытался передать то, что, если вы выполняете переход в зависимости от ключа X (например, {{#X}} , предоставленные данные должны иметь значение для ключа X , либо правдивое, либо правдивое. ложное значение, но определенно не undefined .

• null подразумевает: «Да, я знаю, что нет никакого значения. Я явно отмечаю, что нет никакого значения».
• undefined основном подразумевает, что ключ X даже не определен (если вы определяете ключ со значением undefined вам лучше использовать null ) . А если ключ не определен, это либо из-за того, что он «ленив» объявляет данные (например, не использует null при отсутствии ссылки на объект), либо из-за человеческой ошибки (опечатка, промах, путаница)

Итак, в этом случае я бы увидел преимущества в выдаче ошибки. (попытка перехода по ключу со значением undefined )

В другом случае, пытаясь отобразить либо undefined или null , не уверен, есть ли для этого какой-либо вариант использования. Может быть, ошибся и в этом.

если он не исходит из источника, который использует null для отсутствующих данных, например SQL

Афайк, Философия усов заключается не в том, чтобы использовать модели как есть, а в том, чтобы генерировать на их основе «вид». Вы можете добавить null s на случай, если ваш провайдер почему-то этого не сделает.

В настоящее время я думаю, что посторонние / избыточные / неиспользуемые данные на самом деле не связаны с недействительными данными, а с тем, что шаблон недействителен, если он не использует эти данные, когда приложение / данные / модель ожидают, что это использоваться

Хм, я думаю, что довольно часто не использовать все предоставленные данные. Я добавил эту идею в основном из-за тонкостей инструментов, таких как создание запроса GraphQL, которое я предложил.

если что-то действительно нужно отобразить для пользователя, то, если шаблон не отображает это, это ошибка

Но кто / что решает, что «действительно нужно отображать пользователю»? Я предполагаю, автор шаблона? Если вы заставляете людей использовать все данные в представлении, вы вынуждаете их создавать индивидуальное представление для каждого шаблона, который они намереваются отобразить.

В качестве примечания: моим вариантом использования была ручная настройка без ветвления.

Я попросил «других людей» создать данные (события) вручную, и в этом случае у меня не было возможности проверить, заполнили ли они все поля или допустили опечатки в именах переменных.

В моем шаблоне будет сказано «{{event.name}} на {{event.date}}». В этом случае отсутствующее значение создаст ужасную страницу.
Все поля были обязательными, поэтому добавление логики, чтобы не отображать {{event.date}} не имело бы смысла.

В этом случае было бы неплохо знать «неиспользуемые» переменные, чтобы дважды проверить их на предмет опечаток или добавленных элементов, думая, что они «волшебным образом» появятся на странице :)

Я уверен, что этот вариант использования каким-то образом нарушает идеологию Mustache, но это реальный сценарий.
И в обеих ситуациях (отсутствующие значения + неиспользованные значения) было бы здорово генерировать предупреждение.

9 ноября 2016 года в 10:53 Давид да Силва [email protected] написал:

но в другом случае можно ожидать, что данные могут быть доступны, а могут и нет, и разветвляться по тому, есть ли они (в этом случае они никогда не являются недействительными).

Я пытался передать то, что если вы переходите в зависимости от ключа X (например, {{#X}}, предоставленные данные должны иметь значение для ключа X, либо истинное, либо ложное значение, но определенно не неопределенное.

null подразумевает: «Да, я знаю, что значения нет. Я явно отмечаю, что значения нет».
undefined в основном подразумевает, что ключ X даже не определен (если вы определяете ключ со значением undefined, вам лучше использовать null). И если ключ не определен, это либо из-за того, что он «ленив» объявляет данные (например, не использует null при отсутствии ссылки на объект), либо из-за человеческой ошибки (опечатка, промах, путаница).
Итак, в этом случае я бы увидел преимущества в выдаче ошибки. (пытается перейти по ключу со значением undefined)

В другом случае, пытаясь отобразить либо undefined, либо null, не уверен, есть ли для этого какой-либо вариант использования. Может быть, ошибся и в этом.

если он не исходит из источника, который использует null для отсутствующих данных, например SQL

Афайк, Философия усов заключается не в том, чтобы использовать модели как есть, а в том, чтобы генерировать на их основе «вид». Вы можете добавить нули, если ваш провайдер почему-то этого не делает.

В настоящее время я думаю, что посторонние / избыточные / неиспользуемые данные на самом деле не связаны с недействительными данными, а с тем, что шаблон недействителен, если он не использует эти данные, когда приложение / данные / модель ожидают, что это использоваться

Хм, я думаю, что довольно часто не использовать все предоставленные данные. Я добавил эту идею в основном из-за тонкостей инструментов, таких как создание запроса GraphQL, которое я предложил.

если что-то действительно нужно отобразить для пользователя, то, если шаблон не отображает это, это ошибка

Но кто / что решает, что «действительно нужно отображать пользователю»? Я предполагаю, автор шаблона? Если вы заставляете людей использовать все данные в представлении, вы вынуждаете их создавать индивидуальное представление для каждого шаблона, который они намереваются отобразить.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/janl/mustache.js/issues/599#issuecomment -259374603 или отключите поток https://github.com/notifications/unsubscribe-auth/ AJ8FmcFicDWYjSqibyWac-Sqjg-iFetnks5q8ZgqgaJpZM4J8lKe.

Я уверен, что этот вариант использования каким-то образом нарушает идеологию Mustache, но это реальный сценарий. И в обеих ситуациях (отсутствующие значения + неиспользованные значения) было бы здорово генерировать предупреждение.

Оба варианта кажутся возможными. Это может быть полезно для CI.

Я бы предпочел видеть параметр прямо в представлении для отладки.

Мой вариант использования немного другой: я использую Mustache для преобразования шаблонов 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, поэтому теперь я использую это вместо использования Mustache. Это намного лучше и удобнее. Мы отказались от использования Mustache для этого, и он будет удален в следующей версии нашего конвейера развертывания.

Посмотрев документацию по развертыванию Kubernetes, я вижу, что это файлы YAML. В большинстве языков программирования есть библиотеки, которые могут читать и писать YAML, поэтому я предлагаю вам сделать это вместо этого. Из своего эксперимента я узнал, что когда вы пытаетесь манипулировать машиночитаемым форматом, у вас почти всегда есть лучший вариант, чем Mustache.

Обратите внимание: хотя я больше ни для чего не использую Mustache, я все же считаю, что это действительный запрос функции.

Решение состоит в том, чтобы использовать ручки , которые поддерживают тот же синтаксис, а также имеют строгую опцию, которая как раз и требуется в этом случае использования.

@steverukuts Вы правы насчет манипулирования машиночитаемым форматом, если у вас есть предопределенное манипулирование, которое вам нужно поддерживать, и особенно если вам нужно иметь в нем какой-то ум. Для инструмента конфигурации с открытым концом он очень быстро становится слишком негибким, отсюда и необходимость в шаблонах. Попробуйте написать инструмент, поддерживающий вставку произвольных значений в произвольные места, и ... у вас очень скоро появится механизм шаблонов.

На работе мы использовали kontemplate для настройки ресурса Kubernetes последние несколько лет. По сути, это движок шаблонов go с некоторыми удобными функциями от sprig и пользовательскими функциями в этом проекте. Это был более легкий подход, чем, например, штурвал.

Что касается обсуждения выше; он также взорвется от неизвестных переменных.

Решение состоит в том, чтобы использовать ручки , которые поддерживают тот же синтаксис, а также имеют строгую опцию, которая как раз и требуется в этом случае использования.

Эта проблема заставила меня использовать руль. Жаль, что это не поддерживается в усах.