Mustache.js: Agregar opción: Advertencia sobre variables desconocidas

Me encanta esta función de otros frameworks mientras se desarrolla localmente, ¡así que +1 de mí! Aunque creo que es importante que tenga un impacto mínimo o nulo en el rendimiento. ¿Quizás incluso sea factible manteniendo el núcleo como está? Por ejemplo, anulando algunos métodos internos para permitir este tipo de comportamiento durante el desarrollo.

¿Quizás un mustache.dev.js que se construye usando mustache.js y la función anula que contiene la lógica de verificación?

Preferiría un error grave, de modo que, por ejemplo, cuando se usa con Express, se convierte en una respuesta 500 y no solo en un registro en algún lugar mientras el usuario final ve una página renderizada incorrectamente (potencialmente renderizada muy incorrectamente, dependiendo de cómo falte se suponía que se iba a utilizar la variable); esto podría ser incluso más útil en producción que en desarrollo local, dependiendo de qué tan buena sea su página 500 vs. qué tan malas serían las páginas mal renderizadas para la funcionalidad de su aplicación. El uso de secciones podría permitir que las plantillas ignoren las variables faltantes incluso con errores graves para uso directo. Y cualquier uso de alto nivel que necesite registrar el problema estaría bajo el control del sistema de registro, por lo que no tendríamos que preocuparnos por, digamos, el mecanismo de advertencia interno de Moustache que golpea la salida de los corredores de prueba o cosas por el estilo.

Tengo un prototipo funcional en https://github.com/ScottFreeCode/mustache.js , aunque me vendría bien un poco de ayuda para averiguar cómo escribir una prueba para él.

Hmm, entonces usar la existencia de un objeto como if ( {{#thing}} ) arrojaría un error? (Creo que esto es bastante común)

¿O solo la representación real de las variables ( {{ id }} ) generaría un error? ¿Que estabas pensando?

Editar: característica muy interesante que haría +1 para habilitar de forma predeterminada en una especialización en caso de que no termine siendo una molestia.

En mi opinión, el primero debería ser un error, el segundo una "advertencia".
Para ambos, me gustaría saber que falta un valor.

Aunque en el segundo caso técnicamente podría no romperse, podría tener un gran impacto en la página.

Además, lo contrario sería bueno: variables no utilizadas ... ¡Pero creo que eso es mucho más impacto! :D

El 8 de noviembre de 2016, a las 14:19, David da Silva [email protected] escribió:

Hmm, ¿usar la existencia de un objeto como un if ({{#thing}}) arrojaría un error? (Creo que esto es bastante común)

¿O solo la representación real de las variables ({{id}}) generaría un error? ¿Que estabas pensando?

-
Estás recibiendo esto porque eres el autor del hilo.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/janl/mustache.js/issues/599#issuecomment -259133973, o silencie el hilo https://github.com/notifications/unsubscribe-auth/ AJ8FmSptdhysYrQpg1ODkIrm12A_TXcYks5q8HbbgaJpZM4J8lKe.

En mi opinión, el primero debería ser un error, el segundo una "advertencia".
Para ambos, me gustaría saber que falta un valor.

@MatthijsZw Ya veo. Acabo de recordar que podría almacenar un null para la propiedad, lo cual sería lo mejor y, por lo tanto, no se produciría ninguna excepción. (mencionando especialmente esto para el caso if )

Editar: Mi posición actual es que prefiero Err en ambos. Prefiero comportamientos consistentes, y harías cumplir el uso de null para valores vacíos perdidos, lo que creo que es preferible.

Además, lo contrario sería bueno: variables no utilizadas ... ¡Pero creo que eso es mucho más impacto! :D

Estoy pensando que sería genial obtener de alguna manera el esquema para los datos que espera una plantilla y usarlo para generar una consulta GraphQL ... o algo similar.

Reflexionando más, creo que parte del problema aquí es que los datos faltantes no son válidos _porque_ - y por lo tanto _sólo si_ - la plantilla está _esperando_ esos datos. Por lo tanto, los datos faltantes que la plantilla simplemente mostraría siempre son inválidos por esa lógica, pero es posible que una plantilla en un lugar espere que ciertos datos estén disponibles y se ramifiquen como una especie de bandera de verdadero / falso (por lo que es inválido si no es tanto falso como ausente y, por lo tanto, no cumple con esa expectativa), pero en otro podría esperar que los datos estén disponibles o no y se ramifiquen si lo están (en cuyo caso nunca es inválido).

En esa perspectiva, usar null para controlar esto no tiene mucho sentido para mí:

• Si los datos son incorrectos, no cumplen con las expectativas, ¿cómo podemos esperar que los datos incorrectos controlen el comportamiento de la plantilla sobre el manejo de datos incorrectos?
• De todos modos, la expectativa está realmente en la plantilla.
• null podría ser un valor falso para las ramas de veracidad que esperan datos y consideran que no son válidos para los datos que faltan, pero eso todavía nos deja con la necesidad de ramificar precisamente si los datos se proporcionaron porque esperar que los datos no se completen (ni siquiera con null , a menos que provenga de una fuente que use null para los datos faltantes, por ejemplo, SQL, y en realidad, eso sugiere que si tratar null como faltante o no debe ser configurable según la fuente de datos).

Lo que necesitamos son dos tipos de sucursales, para las diferentes expectativas por parte de la plantilla. Lo cual, que yo sepa, es desafortunado porque la especificación de Moustache independiente del idioma, si bien permite (pero no exige) la configuración de si los datos faltantes son un error, hasta donde yo sé no tiene nada para un tipo diferente de rama que diferiría en este punto. Mmm...

Por otro lado, actualmente estoy pensando que los datos extraños / excedentes / no utilizados no son realmente una cuestión de que los datos no sean válidos, es una cuestión de que la plantilla no sea válida si no usa esos datos cuando la aplicación / datos / modelo espera que se utilice. Es decir, si algunas cosas son potencialmente utilizables pero la plantilla puede decidir si es relevante, entonces no importa si la plantilla imprime esas cosas, pero si algunas cosas realmente _necesita_ mostrarse al usuario, entonces si la plantilla no lo hace ' t mostrarlo es un error. Como una especie de inversión, la expectativa se encuentra fuera de la plantilla (¿en el modelo?) Y la invalidez de no cumplir con esa expectativa reside en la plantilla. Probablemente sea mejor abordar eso por separado, supongo.

Las anteriores son, supongo, opiniones fuertes débilmente sostenidas.

En mi opinión, la interpretación de los valores null como valores no existentes es incorrecta.

{ name: null }

ese objeto tiene una propiedad name con un valor falso y, por lo tanto, nunca debe considerarse inválido y, por lo tanto, no es motivo para lanzarlo.

Una verificación más apropiada sería verificar si una propiedad solicitada se ha definido como lo hacemos en mustache.hasProperty () .

pero en otro, podría esperar que los datos puedan o no estar disponibles y ramifique si lo están (en cuyo caso nunca son inválidos).

Lo que estaba tratando de transmitir es que, si se ramifica dependiendo de la clave X (por ejemplo, {{#X}} , los datos proporcionados deben tener un valor para la clave X , ya sea una verdad o valor falso, pero definitivamente no undefined .

• null implica "sí, sé que no hay valor. Estoy marcando explícitamente que no hay valor".
• undefined implica principalmente que la clave X ni siquiera está definida (si define una clave con un valor de undefined sería mejor usar null ) . Y si la clave no está definida, se debe a que es 'perezoso' declarar los datos (por ejemplo, no usar null cuando falta una referencia de objeto) o debido a un error humano (error tipográfico, desliz, confusión)

Entonces, en este caso, vería beneficios en lanzar un Error. (tratando de bifurcar en una clave que tiene un valor de undefined )

En el otro caso, tratando de renderizar undefined o null , no estoy seguro de si hay algún caso de uso para eso. Quizás Err en eso también.

a menos que provenga de una fuente que use nulo para los datos faltantes, por ejemplo, SQL

Afaik, la filosofía de Moustache no es usar los modelos como están, sino generar una 'vista' a partir de ellos. Puede agregar null s en caso de que su proveedor de alguna manera no lo haga.

Actualmente estoy pensando que los datos extraños / excedentes / no utilizados no son realmente una cuestión de que los datos no sean válidos, es una cuestión de que la plantilla no sea válida si no usa esos datos cuando la aplicación / datos / modelo espera que lo haga ser usado

Hmm, creo que es bastante común no usar todos los datos proporcionados. Lancé la idea principalmente para las sutilezas de las herramientas, como la generación de consultas GraphQL que sugerí.

Si algunas cosas realmente necesitan mostrarse al usuario, entonces si la plantilla no las muestra, es un error.

Pero, ¿quién / qué decide qué "cosas realmente deben mostrarse al usuario"? ¿El escritor de plantillas, supongo? Si obliga a las personas a utilizar todos los datos de la vista, las está obligando a generar una vista personalizada para cada plantilla que pretenden representar.

Como nota: mi caso de uso fue una configuración manual sin ramificación.

Hice que 'otras personas' crearan los datos (eventos) manualmente y, en ese caso, no tenía forma de verificar que completaron todos los campos o cometieron errores tipográficos en los nombres de las variables.

Mi plantilla diría "{{event.name}} el {{event.date}}". En ese caso, un valor faltante crearía una página horrible.
Todos los campos eran obligatorios, por lo que agregar lógica para no mostrar {{event.date}} no tendría sentido.

En este caso, sería bueno conocer las variables 'no utilizadas', para verificar dos veces si hay errores tipográficos o los elementos que agregaron pensando que aparecerían 'mágicamente' en la página :)

Estoy seguro de que este caso de uso viola la ideología de Moustache de alguna manera, pero es un escenario real.
Y sería genial para ambas situaciones (valores perdidos + valores no utilizados) generar una advertencia.

El 9 de noviembre de 2016, a las 10:53, David da Silva [email protected] escribió:

pero en otro, podría esperar que los datos puedan o no estar disponibles y ramifique si lo están (en cuyo caso nunca son inválidos).

Lo que estaba tratando de transmitir es que, si se ramifica en función de la clave X (por ejemplo, {{#X}}, los datos proporcionados deben tener un valor para la clave X, ya sea un valor verdadero o falso, pero definitivamente no indefinido.

null implica "sí, sé que no hay valor. Estoy marcando explícitamente que no hay valor".
undefined implica principalmente que la clave X ni siquiera está definida (si define una clave con un valor de undefined, sería mejor usar null). Y si la clave no está definida, es porque es 'perezoso' al declarar los datos (por ejemplo, no usar nulo cuando falta una referencia de objeto) o debido a un error humano (error tipográfico, desliz, confusión)
Entonces, en este caso, vería beneficios en lanzar un Error. (tratando de bifurcarse en una clave que tiene un valor indefinido)

En el otro caso, tratando de representar indefinido o nulo, no estoy seguro de si hay algún caso de uso para eso. Quizás Err en eso también.

a menos que provenga de una fuente que use nulo para los datos faltantes, por ejemplo, SQL

Afaik, la filosofía de Moustache no es usar los modelos como están, sino generar una 'vista' a partir de ellos. Puede agregar nulos en caso de que su proveedor de alguna manera no lo haga.

Actualmente estoy pensando que los datos extraños / excedentes / no utilizados no son realmente una cuestión de que los datos no sean válidos, es una cuestión de que la plantilla no sea válida si no usa esos datos cuando la aplicación / datos / modelo espera que lo haga ser usado

Hmm, creo que es bastante común no usar todos los datos proporcionados. Lancé la idea principalmente para las sutilezas de las herramientas, como la generación de consultas GraphQL que sugerí.

Si algunas cosas realmente necesitan mostrarse al usuario, entonces si la plantilla no las muestra, es un error.

Pero, ¿quién / qué decide qué "cosas realmente deben mostrarse al usuario"? ¿El escritor de plantillas, supongo? Si obliga a las personas a utilizar todos los datos de la vista, las está obligando a generar una vista personalizada para cada plantilla que pretenden representar.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/janl/mustache.js/issues/599#issuecomment -259374603, o silencie el hilo https://github.com/notifications/unsubscribe-auth/ AJ8FmcFicDWYjSqibyWac-Sqjg-iFetnks5q8ZgqgaJpZM4J8lKe.

Estoy seguro de que este caso de uso viola la ideología de Moustache de alguna manera, pero es un escenario real. Y sería genial para ambas situaciones (valores perdidos + valores no utilizados) generar una advertencia.

Ambos parecen factibles. Podría ser útil para CI.

Preferiría ver el parámetro directamente en la vista para depurarlo.

Mi caso de uso es un poco diferente: uso Moustache para transformar plantillas de Terraform usando Gulp. Una variable faltante puede hacer que las instancias no se inicien correctamente, especialmente cuando se sustituyen en cadenas de forma libre. Se me ocurrió un parche de mono rápido para obtener esta funcionalidad, pero no es ideal:

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;
}

Notas:

• No le da números de línea o nombres de símbolos completamente calificados
• Probablemente sea totalmente inseguro si está trabajando en un entorno multiproceso

Sin embargo, funcionó bien para mis propósitos y estoy seguro de que alguien puede adaptarlo si es necesario.

El uso de bigote como motor de creación de plantillas en cualquier tipo de entorno de gestión de la configuración requiere errores graves en las variables que faltan. Tengo un caso de uso similar a @steverukuts , que transforma los documentos de implementación de Kubernetes. Las variables que faltan son siempre errores en este caso de uso.

@stefaneg un par de meses después de escribir eso, de hecho, descubrí que Terraform admite la configuración escrita en formato JSON, así que ahora uso esto en lugar de usar Moustache. Esto es mucho mejor y más programable. Ahora hemos desaprobado el uso de Moustache para esto y se eliminará en la próxima revisión de nuestro proceso de implementación.

Después de mirar la documentación de implementación de Kubernetes, veo que estos son archivos YAML. La mayoría de los lenguajes de programación tienen bibliotecas que pueden leer y escribir YAML, así que te sugiero que lo hagas. De mi experimento, aprendí que cuando intentas manipular un formato legible por máquina, casi siempre tienes una mejor opción que Moustache.

Tenga en cuenta: si bien ya no uso Moustache para nada, todavía siento que esta es una solicitud de función válida.

La solución es usar manillares , que admiten la misma sintaxis, y también tiene una opción estricta que es exactamente lo que se necesita en este caso de uso.

@steverukuts Tiene razón sobre la manipulación del formato legible por máquina, si tiene una manipulación predeterminada que necesita admitir, y especialmente si necesita tener algo de inteligencia incorporada. Para una herramienta de configuración abierta, eso se vuelve demasiado inflexible muy rápido, de ahí la necesidad de plantillas. Intente escribir una herramienta que admita la inserción de valores arbitrarios en lugares arbitrarios y ... muy pronto tendrá un motor de plantillas.

En el trabajo, hemos estado usando kontemplate para configurar el recurso de sprig y personalizadas en ese proyecto. Se ha hecho como un enfoque más ligero que el timón, por ejemplo.

En relación con la discusión anterior; también explotará en variables desconocidas.

La solución es usar manillares , que admiten la misma sintaxis, y también tiene una opción estricta que es exactamente lo que se necesita en este caso de uso.

Este problema también me obligó a usar manubrios. Es una lástima que esto no sea compatible con el bigote.