Mustache.js: Option hinzufügen: Warnung bei unbekannten Variablen

Ich liebe dieses Feature von anderen Frameworks bei der lokalen Entwicklung, also +1 von mir! Ich denke, es ist wichtig, dass es minimale bis keine Auswirkungen auf die Leistung hat. Vielleicht sogar machbar, während der Kern so bleibt, wie er ist? ZB durch Überschreiben einiger interner Methoden, um diese Art von Verhalten während der Entwicklung zu ermöglichen.

Vielleicht ein mustache.dev.js das mit mustache.js und die Funktion überschreibt, die die Prüflogik enthält?

Ich würde einen harten Fehler vorziehen, damit es zum Beispiel bei der Verwendung mit Express zu einer 500-Antwort und nicht nur zu einem Protokoll wird, während der Endbenutzer eine falsch gerenderte Seite sieht (möglicherweise sehr falsch gerendert, je nachdem, wie die fehlenden Variable sollte verwendet werden); Dies kann in der Produktion sogar noch nützlicher sein als in der lokalen Entwicklung, je nachdem, wie gut Ihre 500-Seite ist und wie schlecht die falsch gerenderten Seiten für die Funktionalität Ihrer Anwendung wären. Die Verwendung von Abschnitten könnte es Vorlagen immer noch ermöglichen, fehlende Variablen zu ignorieren, selbst bei schwerwiegenden Fehlern für die direkte Verwendung. Und jeder höherstufige Benutzer, der das Problem protokollieren muss, würde das Protokollsystem kontrollieren, sodass wir uns keine Sorgen machen müssten, dass beispielsweise der interne Warnmechanismus von Moustache die Ausgabe von Testläufern oder ähnliches überlagert.

Ich habe einen funktionierenden Prototyp unter https://github.com/ScottFreeCode/mustache.js , obwohl ich etwas Hilfe gebrauchen könnte, um herauszufinden, wie man einen Test dafür schreibt.

Hmm, also würde die Verwendung der Existenz eines Objekts als if ( {{#thing}} ) einen Fehler auslösen? (Ich denke das ist ziemlich üblich)

Oder würde nur das tatsächliche Rendern von Variablen ( {{ id }} ) einen Fehler auslösen? Was hast du dir dabei gedacht?

Bearbeiten: Sehr coole Funktion, für die ich +1 geben würde, um sie standardmäßig in einem Major zu aktivieren, falls es nicht zu einem Problem wird.

Meiner Meinung nach sollte das erste ein Fehler sein, das zweite eine 'Warnung'.
Für beides würde ich gerne wissen, dass ein Wert fehlt.

Auch wenn es im zweiten Fall technisch möglicherweise nicht kaputt geht, könnte es einen großen Einfluss auf die Seite haben.

Auch anders herum wäre schön: ungenutzte Variablen… Aber das ist viel mehr Einfluss, denke ich! :D

Am 8. November 2016 um 14:19 schrieb David da Silva [email protected] :

Hmm, also würde die Verwendung der Existenz eines Objekts als if ({{#thing}}) einen Fehler auslösen? (Ich denke das ist ziemlich üblich)

Oder würde nur das tatsächliche Rendern von Variablen ({{ id }}) einen Fehler auslösen? Was hast du dir dabei gedacht?

—
Sie erhalten dies, weil Sie den Thread verfasst haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/janl/mustache.js/issues/599#issuecomment -259133973 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/ AJ8FmSptdhysYrQpg1ODkIrm12A_TXcYks5q8HbbgaJpZM4J8lKe.

Meiner Meinung nach sollte das erste ein Fehler sein, das zweite eine 'Warnung'.
Für beides würde ich gerne wissen, dass ein Wert fehlt.

@MatthijsZw Ich null Wert für die Eigenschaft speichern könnten, was eine gute Sache wäre und daher keine Ausnahme auftreten würde. (besonders erwähnenswert für den Fall if )

Bearbeiten: Meine derzeitige Position ist, dass ich es vorziehen würde, bei beiden zu irren. Ich bevorzuge konsistente Verhaltensweisen, und Sie würden die Verwendung von null für leer fehlende Werte erzwingen, was meiner Meinung nach vorzuziehen ist.

Auch anders herum wäre schön: ungenutzte Variablen… Aber das ist viel mehr Einfluss, denke ich! :D

Ich denke, es wäre cool, das Schema für die Daten, die eine Vorlage erwartet, irgendwie abzurufen und damit eine GraphQL-Abfrage zu generieren ... oder etwas Ähnliches.

Bei weiterer Betrachtung denke ich, dass ein Teil des Problems hier darin besteht, dass fehlende Daten ungültig sind, _weil_ -- und daher _nur wenn_ -- die Vorlage diese Daten _erwartet_. Fehlende Daten, die die Vorlage einfach nur anzeigen würde, sind nach dieser Logik immer ungültig, aber es ist denkbar, dass eine Vorlage an einer Stelle erwartet, dass bestimmte Daten verfügbar sind, und darauf als eine Art Wahr/Falsch-Flag verzweigt (also ist es ungültig, wenn es nicht so sehr falsch ist, als dass es fehlt und daher diese Erwartung nicht erfüllt), aber in einem anderen Fall könnte es erwarten, dass Daten verfügbar sein können oder nicht, und verzweigen, ob dies der Fall ist (in diesem Fall ist es niemals ungültig).

Aus dieser Perspektive macht es für mich nicht wirklich viel Sinn, null zu verwenden, um dies zu steuern:

• Wenn die Daten falsch sind – also die Erwartungen nicht erfüllen – wie können wir erwarten, dass die falschen Daten das Verhalten der Vorlage beim Umgang mit falschen Daten steuern?
• Die Erwartung steht sowieso wirklich in der Vorlage.
• null könnte ein falscher Wert für Verzweigungen auf Wahrheit sein, die Daten erwarten und diese für ungültig halten, weil die Daten fehlen, aber das lässt uns immer noch die Notwendigkeit, genau zu verzweigen, ob die Daten überhaupt geliefert wurden, weil wir erwarten, dass die Daten möglicherweise nicht ausgefüllt werden (nicht einmal mit null , es sei denn, sie stammen aus einer Quelle, die null für fehlende Daten verwendet, z null als fehlend behandeln oder nicht basierend auf der Datenquelle konfigurierbar sein sollte).

Was wir brauchen, sind zwei Arten von Verzweigungen, für die unterschiedlichen Erwartungen seitens der Vorlage. Was meines Wissens bedauerlich ist, da die sprachunabhängige Moustache-Spezifikation zwar die Konfiguration ermöglicht (aber nicht vorschreibt), ob fehlende Daten ein Fehler sind, meines Wissens jedoch nichts für einen anderen Zweigtyp bietet, der würde in diesem Punkt abweichen. Hmm...

Auf der anderen Seite denke ich derzeit, dass es bei überflüssigen/überzähligen/nicht verwendeten Daten nicht wirklich darum geht, dass die Daten ungültig sind, sondern dass die Vorlage ungültig ist, wenn sie diese Daten nicht verwendet, wenn die Anwendung/Daten/ Modell erwartet, dass es verwendet wird. Das heißt, wenn einige Dinge potenziell verwendbar sind, aber die Vorlage entscheiden kann, ob sie relevant sind, dann spielt es keine Rolle, ob die Vorlage diese Dinge druckt, aber wenn einige Dinge dem Benutzer wirklich angezeigt werden müssen, dann, wenn die Vorlage dies tut. nicht anzeigen, das ist ein Fehler. Als eine Art Umkehrung liegt die Erwartung außerhalb der Vorlage (im Modell?) und die Ungültigkeit, diese Erwartung nicht zu erfüllen, liegt in der Vorlage. Wahrscheinlich am besten, das separat anzugehen, würde ich mir vorstellen.

Die oben genannten sind, glaube ich, starke Meinungen, die schwach vertreten sind.

IMO interpretiert null Werte als nicht vorhandene Werte, ist falsch.

{ name: null }

dieses Objekt hat eine name Eigenschaft mit einem falschen Wert und sollte daher niemals als ungültig angesehen werden und ist daher kein Grund zum Werfen.

Eine angemessenere Prüfung wäre, zu prüfen, ob eine angeforderte Eigenschaft definiert wurde, wie wir es in mustache.hasProperty() tun.

aber in einem anderen Fall könnte es erwarten, dass Daten verfügbar sein können oder nicht, und verzweigen, ob dies der Fall ist (in diesem Fall ist es niemals ungültig).

Was ich zu vermitteln versuchte, ist, dass, wenn Sie in Abhängigkeit vom Schlüssel X (zB {{#X}} verzweigen, die bereitgestellten Daten einen Wert für den Schlüssel X , entweder ein truey oder falscher Wert, aber definitiv nicht undefined .

• null impliziert "Ja, ich weiß, dass es keinen Wert gibt. Ich markiere ausdrücklich, dass es keinen Wert gibt".
• undefined impliziert meistens, dass der Schlüssel X nicht einmal definiert ist (wenn Sie einen Schlüssel mit einem Wert von undefined Sie besser null ) . Und wenn der Schlüssel nicht definiert ist, liegt es entweder daran, dass die Daten "faul" sind (zB null wenn eine Objektreferenz fehlt) oder an menschlichen Fehlern (Tippfehler, Ausrutscher, Verwirrung).

In diesem Fall würde ich also Vorteile darin sehen, einen Fehler auszulösen. (Versuch, auf einen Schlüssel zu verzweigen, der einen Wert von undefined )

Im anderen Fall, wenn Sie versuchen, entweder undefined oder null zu rendern, sind Sie sich nicht sicher, ob es dafür einen Anwendungsfall gibt. Vielleicht Err auch in diesem Fall.

es sei denn, es stammt aus einer Quelle, die null für fehlende Daten verwendet, z. B. SQL

Afaik, die Philosophie von Moustache besteht darin, die Modelle nicht so zu verwenden, wie sie sind, sondern eine "Ansicht" daraus zu generieren. Sie könnten null s hinzufügen, falls Ihr Anbieter dies nicht tut.

Ich denke derzeit, dass es bei überflüssigen/überzähligen/nicht verwendeten Daten nicht wirklich darum geht, dass die Daten ungültig sind, sondern dass die Vorlage ungültig ist, wenn sie diese Daten nicht verwendet, wenn die Anwendung/Daten/Modell dies erwartet verwendet werden

Hmm, ich denke, es ist ziemlich üblich, nicht alle bereitgestellten Daten zu verwenden. Ich habe die Idee hauptsächlich für Tooling-Feinheiten eingebracht, wie die von mir vorgeschlagene GraphQL-Abfragegenerierung.

Wenn dem Benutzer wirklich einiges angezeigt werden muss, ist dies ein Fehler, wenn die Vorlage es nicht anzeigt

Aber wer/was entscheidet, was "dem Benutzer wirklich angezeigt werden muss"? Der Vorlagenschreiber, vermute ich? Wenn Sie Personen zwingen, alle Daten in der Ansicht zu verwenden, zwingen Sie sie, für jede Vorlage, die sie rendern möchten, eine maßgeschneiderte Ansicht zu generieren.

Als Hinweis: Mein Anwendungsfall war eine manuelle Einrichtung ohne Verzweigung.

Ich habe 'andere Leute' die Daten (Ereignisse) manuell erstellen lassen und in diesem Fall hatte ich keine Möglichkeit zu überprüfen, ob sie alle Felder ausgefüllt oder Tippfehler in den Variablennamen gemacht haben.

Meine Vorlage würde "{{ event.name }} on {{ event.date }}" sagen. In diesem Fall würde ein fehlender Wert eine schreckliche Seite erzeugen.
Alle Felder waren erforderlich, daher wäre es nicht sinnvoll, eine Logik hinzuzufügen, um {{ event.date }} nicht anzuzeigen.

In diesem Fall wäre es auch gut, "nicht verwendete" Variablen zu kennen, um auf Tippfehler oder Elemente zu überprüfen, die sie hinzugefügt haben, weil sie dachten, sie würden "magisch" auf der Seite erscheinen :)

Ich bin mir sicher, dass dieser Anwendungsfall irgendwie gegen die Ideologie von Moustache verstößt, aber es ist ein echtes Szenario.
Und für beide Situationen (fehlende Werte + nicht verwendete Werte) wäre es großartig, eine Warnung zu generieren.

Am 9. November 2016 um 10:53 Uhr schrieb David da Silva [email protected] :

aber in einem anderen Fall könnte es erwarten, dass Daten verfügbar sein können oder nicht, und verzweigen, ob dies der Fall ist (in diesem Fall ist es niemals ungültig).

Was ich vermitteln wollte, ist, dass, wenn Sie in Abhängigkeit von Schlüssel X (zB {{#X}}) verzweigen, die bereitgestellten Daten einen Wert für Schlüssel X haben sollten, entweder ein wahrer oder ein falscher Wert, aber definitiv nicht undefiniert.

null impliziert "ja, ich weiß, dass es keinen Wert gibt. Ich markiere ausdrücklich, dass es keinen Wert gibt".
undefined impliziert meistens, dass Schlüssel X nicht einmal definiert ist (wenn Sie einen Schlüssel mit dem Wert undefined definieren, sollten Sie besser null verwenden). Und wenn der Schlüssel nicht definiert ist, liegt es entweder daran, dass die Daten "faul" sind (z.
In diesem Fall würde ich also Vorteile darin sehen, einen Fehler auszulösen. (Versuch, auf einen Schlüssel zu verzweigen, der den Wert undefiniert hat)

Im anderen Fall, wenn Sie versuchen, entweder undefiniert oder null zu rendern, sind Sie sich nicht sicher, ob es dafür einen Anwendungsfall gibt. Vielleicht Err auch in diesem Fall.

es sei denn, es stammt aus einer Quelle, die null für fehlende Daten verwendet, z. B. SQL

Afaik, die Philosophie von Moustache besteht darin, die Modelle nicht so zu verwenden, wie sie sind, sondern eine "Ansicht" daraus zu generieren. Sie könnten Nullen hinzufügen, falls Ihr Anbieter dies nicht tut.

Ich denke derzeit, dass es bei überflüssigen/überzähligen/nicht verwendeten Daten nicht wirklich darum geht, dass die Daten ungültig sind, sondern dass die Vorlage ungültig ist, wenn sie diese Daten nicht verwendet, wenn die Anwendung/Daten/Modell dies erwartet verwendet werden

Hmm, ich denke, es ist ziemlich üblich, nicht alle bereitgestellten Daten zu verwenden. Ich habe die Idee hauptsächlich für Tooling-Feinheiten eingebracht, wie die von mir vorgeschlagene GraphQL-Abfragegenerierung.

Wenn dem Benutzer wirklich einiges angezeigt werden muss, ist dies ein Fehler, wenn die Vorlage es nicht anzeigt

Aber wer/was entscheidet, was "dem Benutzer wirklich angezeigt werden muss"? Der Vorlagenschreiber, vermute ich? Wenn Sie Personen zwingen, alle Daten in der Ansicht zu verwenden, zwingen Sie sie, für jede Vorlage, die sie rendern möchten, eine maßgeschneiderte Ansicht zu generieren.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/janl/mustache.js/issues/599#issuecomment -259374603 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/ AJ8FmcFicDWYjSqibyWac-Sqjg-iFetnks5q8ZgqgaJpZM4J8lKe.

Ich bin mir sicher, dass dieser Anwendungsfall irgendwie gegen die Ideologie von Moustache verstößt, aber es ist ein echtes Szenario. Und für beide Situationen (fehlende Werte + nicht verwendete Werte) wäre es großartig, eine Warnung zu generieren.

Beides scheint machbar. Es könnte für CI nützlich sein.

Ich würde es vorziehen, den Parameter zum Debuggen direkt in der Ansicht anzuzeigen.

Mein Anwendungsfall ist ein bisschen anders: Ich verwende Moustache, um Terraform-Vorlagen mit Gulp zu transformieren. Eine fehlende Variable kann dazu führen, dass Instanzen nicht richtig booten, insbesondere wenn sie in Freiform-Strings ersetzt werden. Ich habe mir einen schnellen Monkey-Patch ausgedacht, um diese Funktionalität zu erhalten, aber es ist kaum 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;
}

Anmerkungen:

• Es gibt Ihnen keine Zeilennummern oder vollqualifizierten Symbolnamen
• Es ist wahrscheinlich völlig unsicher, wenn Sie in einer Multithread-Umgebung arbeiten

Für meine Zwecke hat es jedoch gut funktioniert und ich bin mir sicher, dass jemand es bei Bedarf anpassen kann.

Die Verwendung von Moustache als Template-Engine in jeder Art von Konfigurationsverwaltungsumgebung erfordert harte Fehler bei fehlenden Variablen. Ich habe einen ähnlichen Anwendungsfall wie @steverukuts , der Kubernetes-Bereitstellungsdokumente transformiert. Fehlende Variablen sind in diesem Anwendungsfall immer Fehler.

@stefaneg ein paar Monate nachdem ich geschrieben hatte, dass ich tatsächlich entdeckt habe, dass Terraform im JSON-Format geschriebene Konfigurationen unterstützt, verwende ich dies jetzt anstelle von Moustache. Das ist viel besser und programmierbarer. Wir haben die Verwendung von Moustache dafür jetzt eingestellt und es wird in der nächsten Überarbeitung unserer Bereitstellungspipeline entfernt.

Nachdem ich mir die Dokumentation zur Bereitstellung von Kubernetes angesehen habe, sehe ich, dass es sich um YAML-Dateien handelt. Die meisten Programmiersprachen haben Bibliotheken, die YAML lesen und schreiben können, daher empfehle ich Ihnen, dies stattdessen zu tun. Aus meinem Experiment habe ich gelernt, dass Sie beim Versuch, ein maschinenlesbares Format zu manipulieren, fast immer eine bessere Option als Moustache haben.

Bitte beachte: Obwohl ich Moustache für nichts mehr verwende, bin ich immer noch der Meinung, dass dies eine gültige Funktionsanfrage ist.

Die Lösung ist die Verwendung Lenker , die die gleiche Syntax unterstützt, und haben auch eine strenge Option , die genau das , was in diesem usecase benötigt wird.

@steverukuts Sie haben Recht, wenn Sie das maschinenlesbare Format manipulieren, wenn Sie eine vorbestimmte Manipulation haben, die Sie unterstützen müssen, und insbesondere, wenn Sie einige Smarts eingebaut haben müssen. Für ein offenes Konfigurationstool wird dies sehr schnell zu unflexibel, daher sind Vorlagen erforderlich. Versuchen Sie, ein Werkzeug zu schreiben, das das Einfügen beliebiger Werte an beliebigen Stellen unterstützt, und ... Sie haben sehr bald eine Vorlagen-Engine.

Bei der Arbeit haben wir in den letzten Jahren kontemplate zum Konfigurieren von Kubernetes-Ressourcen verwendet. Es ist im Grunde die Go-Templating-Engine mit einigen praktischen Funktionen von sprig und benutzerdefinierten in diesem Projekt. Es wurde als leichterer Ansatz als beispielsweise Helm entwickelt.

In Bezug auf die obige Diskussion; es wird auch bei unbekannten Variablen explodieren.

Die Lösung ist die Verwendung Lenker , die die gleiche Syntax unterstützt, und haben auch eine strenge Option , die genau das , was in diesem usecase benötigt wird.

Dieses Problem zwang mich dazu, auch Lenker zu verwenden. Es ist schade, dass dies in Schnurrbart nicht unterstützt wird.