Mustache.js: 옵션 추가: 알 수 없는 변수에 대한 경고

로컬에서 개발하는 동안 다른 프레임워크의 이 기능을 좋아하므로 저에게 +1하십시오! 성능에 최소한의 영향을 미치거나 전혀 영향을 미치지 않는 것이 중요하다고 생각합니다. 코어를 그대로 유지하면서 가능할까요? 예를 들어 개발하는 동안 이러한 종류의 동작을 활성화하기 위해 일부 내부 메서드를 재정의합니다.

mustache.dev.js 를 사용하여 빌드된 mustache.js 및 검사 논리를 포함하는 함수 재정의가 가능할까요?

예를 들어 Express와 함께 사용할 때 최종 사용자가 잘못 렌더링된 페이지를 보고 있는 동안 어딘가에 로그가 아니라 500 응답이 되도록 하는 것을 선호합니다. 변수를 사용해야 함); 이것은 500페이지가 얼마나 좋은지와 잘못 렌더링된 페이지가 애플리케이션의 기능에 얼마나 나쁜지에 따라 로컬 개발보다 프로덕션에서 훨씬 더 유용할 수 있습니다. 섹션을 사용하면 템플릿에서 직접 사용하기 위한 하드 오류가 있는 경우에도 누락된 변수를 무시할 수 있습니다. 그리고 문제를 기록해야 하는 더 높은 수준의 사용은 기록 시스템을 제어하므로 테스트 러너 또는 이와 유사한 것의 출력을 방해하는 Mustache의 내부 경고 메커니즘에 대해 걱정할 필요가 없습니다.

https://github.com/ScottFreeCode/mustache.js 에 프로토타입이 있습니다. 테스트를 작성하는 방법을 알아내는 데 도움을 받을 수는 있지만요.

흠, 그래서 if ( {{#thing}} )로 개체의 존재를 사용하면 오류가 발생합니까? (나는 이것이 꽤 흔한 일이라고 생각한다)

아니면 변수의 실제 렌더링( {{ id }} )에서만 오류가 발생합니까? 무슨 생각하고 있었던거야?

편집: 번거롭지 않은 경우를 대비하여 전공에서 기본적으로 활성화하도록 +1할 수 있는 매우 멋진 기능입니다.

내 생각에 첫 번째는 오류이고 두 번째는 '경고'여야 합니다.
둘 다 누락된 값이 있는지 알고 싶습니다.

두 번째 경우에는 기술적으로 깨지지 않을 수 있지만 페이지에 큰 영향을 미칠 수 있습니다.

또한 그 반대의 경우도 좋을 것입니다. 사용하지 않는 변수... 하지만 훨씬 더 많은 영향을 미칠 수 있습니다. :NS

2016년 11월 8일 14시 19분에 David da Silva [email protected]이 다음과 같이 썼습니다.

흠, 그렇다면 객체의 존재를 if({{#thing}})로 사용하면 오류가 발생합니까? (나는 이것이 꽤 흔한 일이라고 생각한다)

아니면 변수의 실제 렌더링({{ id }})만 오류가 발생합니까? 무슨 생각하고 있었던거야?

—
스레드를 작성했기 때문에 이 메시지를 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/janl/mustache.js/issues/599#issuecomment -259133973에서 확인하거나 스레드 https://github.com/notifications/unsubscribe-auth/를 음소거

내 생각에 첫 번째는 오류이고 두 번째는 '경고'여야 합니다.
둘 다 누락된 값이 있는지 알고 싶습니다.

@MatthijsZw 알겠습니다 . 방금 속성에 대해 null 값을 저장할 수 있다는 것을 기억했습니다. 이는 좋은 일이므로 예외가 발생하지 않습니다. (특히 if 경우에 대해 언급)

편집: 내 현재 입장은 둘 다 Err을 선호한다는 것입니다. 나는 일관된 행동을 선호하며 빈 결측값에 대해 null 사용을 시행할 것인데, 이것이 바람직하다고 생각합니다.

또한 그 반대의 경우도 좋을 것입니다. 사용하지 않는 변수... 하지만 훨씬 더 많은 영향을 미칠 수 있습니다. :NS

템플릿이 예상하는 데이터에 대한 스키마를 어떻게든 가져오고 이를 사용하여 GraphQL 쿼리를 생성하거나... 또는 이와 유사한 것을 사용하는 것이 멋질 것이라고 생각합니다.

더 생각해 보면, 여기서 문제의 일부는 누락된 데이터가 _때문에_ 유효하지 않다는 것입니다. 따라서 _만약_ 템플릿이 해당 데이터를 _기대하는_ 것입니다. 따라서 템플릿이 일반 표시할 수 있는 누락된 데이터는 해당 논리에 의해 항상 유효하지 않지만 템플릿이 한 곳에서 특정 데이터를 사용할 수 있고 이를 일종의 참/거짓 플래그로 분기할 수 있다고 생각할 수 있습니다. 누락된 것만큼 거짓이 아니어서 해당 기대치를 충족하지 못하는 경우 유효하지 않지만, 다른 데이터에서는 데이터가 사용 가능하거나 사용 불가능할 수 있으며 사용 가능한지 여부에 따라 분기할 수 있습니다(이 경우 유효하지 않음).

그런 관점에서 null 를 사용하여 이것을 제어하는 ​​것은 나에게 그다지 의미가 없습니다.

• 데이터가 잘못된 경우(예상을 충족하지 못하는 경우) 잘못된 데이터 처리에 대한 템플릿 동작을 제어하는 ​​잘못된 데이터를 어떻게 기대할 수 있습니까?
• 어쨌든 기대는 실제로 템플릿에 있습니다.
• null 는 데이터를 기대하고 데이터 누락에 대해 유효하지 않은 것으로 간주하는 진실성에 대한 분기에 대한 잘못된 값일 수 있지만, 여전히 데이터가 전혀 제공되었는지 여부에 대한 분기가 필요합니다. 데이터가 채워지지 않을 수 있다고 예상하십시오( null 아니더라도 누락된 데이터에 대해 null 를 사용하는 소스에서 오는 경우가 아니라면, 예를 들어 SQL -- 그리고 실제로, 이는 null 를 누락된 것으로 취급하거나 데이터 소스를 기반으로 구성할 수 없음).

우리가 필요로 하는 것은 템플릿 부분에서 다른 기대를 위한 두 가지 유형의 분기입니다. 내가 아는 한 언어에 구애받지 않는 Mustache 사양 때문에 불행한 일이지만 누락 된 데이터가 오류인지 여부에 대한 구성을 허용하지만 다른 유형의 분기에 대한 정보가 없다는 것을 알고 있습니다. 이 점에서 다를 것이다. 흠...

반대로, 나는 현재 관련 없는/잉여/미사용 데이터가 실제로 잘못된 데이터의 문제가 아니라 응용 프로그램/데이터/ 모델이 사용될 것으로 예상됩니다. 즉, 일부 항목이 잠재적으로 사용 가능하지만 템플릿이 관련성 여부를 결정할 수 있는 경우 템플릿이 해당 항목을 인쇄하는지 여부는 중요하지 않지만 일부 항목이 사용자에게 실제로 표시되어야 _필요_하다면 템플릿이 t 그것을 표시하는 것은 오류입니다. 일종의 반전으로서 기대는 템플릿 외부에 있고(모델에서?) 그 기대를 충족하지 못하는 무효성은 템플릿에 있습니다. 아마도 별도로 해결하는 것이 가장 좋을 것 같습니다.

위의 내용은 강한 의견이 약하게 유지되고 있다고 생각합니다.

null 값을 존재하지 않는 값으로 해석하는 IMO는 잘못되었습니다.

{ name: null }

해당 개체에는 잘못된 값이 있는 name 속성이 있으므로 유효하지 않은 것으로 간주되어서는 안 되므로 던질 이유가 아닙니다.

더 적절한 검사는 요청한 속성이 mustache.hasProperty() 에서와 같이 정의되었는지 확인하는 것입니다.

그러나 다른 데이터에서는 데이터가 사용 가능하거나 사용 불가능할 수 있으며 사용 가능 여부에 따라 분기할 수 있습니다(이 경우 유효하지 않음).

내가 전달하려는 것은 X 키에 따라 분기하는 경우(예: {{#X}} , 제공된 데이터는 X 키에 대한 값이 있어야 합니다. 거짓 값이지만 확실히 undefined 아닙니다.

• null "예, 값이 없다는 것을 알고 있습니다. 값이 없음을 명시적으로 표시하고 있습니다"를 의미합니다.
• undefined 대부분 X 키가 정의되지 않았음을 의미합니다( undefined 값으로 키를 정의하는 경우 null 사용하는 것이 좋습니다) . 그리고 키가 정의되지 않은 경우 데이터 선언이 '게으른'(예: 객체 참조가 없을 때 null 사용하지 않음) 또는 사람의 실수(오타, 미끄러짐, 혼동) 때문입니다.

따라서 이 경우 오류를 던지면 이점이 있습니다. (값이 undefined 키에서 분기하려고 함)

다른 경우에는 undefined 또는 null 를 렌더링하려고 하면 이에 대한 사용 사례가 있는지 확실하지 않습니다. 아마도 그 부분에서도 오류가 발생할 수 있습니다.

SQL과 같이 누락된 데이터에 null을 사용하는 소스에서 오는 경우가 아니면

Afaik, Mustache 철학은 모델을 있는 그대로 사용하는 것이 아니라 모델에서 '보기'를 생성하는 것입니다. 공급자가 어떻게 든 그렇지 않은 경우를 대비하여 null 추가할 수 있습니다.

나는 현재 관련 없는/잉여/미사용 데이터가 실제로 유효하지 않은 데이터의 문제가 아니라 애플리케이션/데이터/모델이 예상할 때 해당 데이터를 사용하지 않는 경우 템플릿이 유효하지 않다는 문제라고 생각하고 있습니다. 이용되다

음, 제공된 데이터를 모두 사용하지 않는 것이 일반적이라고 생각합니다. 저는 제가 제안한 GraphQL 쿼리 생성과 같은 유용한 툴링을 위해 주로 아이디어를 던졌습니다.

일부 항목이 실제로 사용자에게 표시되어야 하는 경우 템플릿에 표시되지 않으면 오류입니다.

그러나 "사용자에게 진정으로 표시되어야 하는 것"이 ​​무엇인지 누가/무엇을 결정합니까? 내가 추측하는 템플릿 작가? 사람들이 보기의 모든 데이터를 사용하도록 강제하는 경우 렌더링하려는 각 템플릿에 대해 맞춤형 보기를 생성하도록 강요하는 것입니다.

참고로 제 사용 사례는 분기 없는 수동 설정이었습니다.

나는 '다른 사람들'이 데이터(이벤트)를 수동으로 생성하도록 했고 그 경우 그들이 모든 필드를 채우거나 변수 이름에 오타를 만들었는지 확인할 방법이 없었습니다.

내 템플릿은 "{{ event.name }} on {{ event.date }}"라고 표시됩니다. 이 경우 누락된 값은 끔찍한 페이지를 생성합니다.
모든 필드가 필수이므로 {{ event.date }}를 표시하지 않는 논리를 추가하는 것은 의미가 없습니다.

이 경우 '사용되지 않는' 변수도 알고, 오타나 추가한 항목이 페이지에 '마법처럼' 나타날 것이라고 생각하는 항목을 다시 확인하는 것이 좋습니다. :)

나는 이 사용 사례가 어떻게든 Mustache의 이념을 어기는 것이라고 확신하지만 실제 시나리오입니다.
그리고 두 가지 상황(결측값 + 사용하지 않은 값) 모두 경고를 생성하는 것이 좋습니다.

2016년 11월 9일 10시 53분에 David da Silva [email protected]이 다음과 같이 썼습니다.

그러나 다른 데이터에서는 데이터가 사용 가능하거나 사용 불가능할 수 있으며 사용 가능 여부에 따라 분기할 수 있습니다(이 경우 유효하지 않음).

내가 전달하려는 것은 키 X에 따라 분기하는 경우(예: {{#X}}, 제공된 데이터는 키 X에 대한 값이 있어야 합니다. 참 또는 거짓 값이지만 확실히 정의되지 않은 값은 아닙니다.

null은 "예, 값이 없다는 것을 알고 있습니다. 값이 없음을 명시적으로 표시하고 있습니다"를 의미합니다.
undefined는 대부분 키 X가 정의되지 않았음을 의미합니다(undefined 값으로 키를 정의하는 경우 null을 사용하는 것이 좋습니다). 키가 정의되지 않은 경우 데이터 선언이 '게으른'(예: 객체 참조가 없는 경우 null을 사용하지 않음) 또는 사람의 실수(오타, 실수, 혼동) 때문입니다.
따라서 이 경우 오류를 던지면 이점이 있습니다. (값이 정의되지 않은 키에서 분기를 시도함)

다른 경우에는 정의되지 않았거나 null을 렌더링하려고 시도했지만 이에 대한 사용 사례가 있는지 확실하지 않습니다. 아마도 그 부분에서도 오류가 발생할 수 있습니다.

SQL과 같이 누락된 데이터에 null을 사용하는 소스에서 오는 경우가 아니면

Afaik, Mustache 철학은 모델을 있는 그대로 사용하는 것이 아니라 모델에서 '보기'를 생성하는 것입니다. 공급자가 어떻게 든 그렇지 않은 경우를 대비하여 null을 추가할 수 있습니다.

나는 현재 관련 없는/잉여/미사용 데이터가 실제로 유효하지 않은 데이터의 문제가 아니라 애플리케이션/데이터/모델이 예상할 때 해당 데이터를 사용하지 않는 경우 템플릿이 유효하지 않다는 문제라고 생각하고 있습니다. 이용되다

음, 제공된 데이터를 모두 사용하지 않는 것이 일반적이라고 생각합니다. 저는 제가 제안한 GraphQL 쿼리 생성과 같은 유용한 툴링을 위해 주로 아이디어를 던졌습니다.

일부 항목이 실제로 사용자에게 표시되어야 하는 경우 템플릿에 표시되지 않으면 오류입니다.

그러나 "사용자에게 진정으로 표시되어야 하는 것"이 ​​무엇인지 누가/무엇을 결정합니까? 내가 추측하는 템플릿 작가? 사람들이 보기의 모든 데이터를 사용하도록 강제하는 경우 렌더링하려는 각 템플릿에 대해 맞춤형 보기를 생성하도록 강요하는 것입니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/janl/mustache.js/issues/599#issuecomment -259374603에서 확인하거나 스레드 https://github.com/notifications/unsubscribe-auth/를 음소거

나는 이 사용 사례가 어떻게든 Mustache의 이념을 어기는 것이라고 확신하지만 실제 시나리오입니다. 그리고 두 가지 상황(결측값 + 사용하지 않은 값) 모두 경고를 생성하는 것이 좋습니다.

둘 다 가능한 것 같습니다. CI에 유용할 수 있습니다.

디버깅을 위해 뷰에서 직접 매개변수를 보는 것을 선호합니다.

내 사용 사례는 약간 다릅니다. 저는 Mustache를 사용하여 Gulp를 사용하여 Terraform 템플릿을 변환합니다. 변수가 없으면 특히 자유 형식 문자열로 대체할 때 인스턴스가 올바르게 부팅되지 않을 수 있습니다. 이 기능을 얻기 위해 빠른 원숭이 패치를 생각해 냈지만 이상적이지 않습니다.

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

노트:

• 줄 번호나 완전한 기호 이름을 제공하지 않습니다.
• 다중 스레드 환경에서 작업하는 경우 완전히 안전하지 않을 수 있습니다.

그러나 그것은 내 목적을 위해 잘 작동했으며 필요한 경우 누군가가 조정할 수 있다고 확신합니다.

모든 종류의 구성 관리 환경에서 콧수염을 템플릿 엔진으로 사용하려면 누락된 변수에 대한 하드 오류가 필요합니다. 저는는 Kubernetes에게 배포 문서를 변환, @steverukuts에 사용하는 경우와 유사합니다. 이 사용 사례에서 누락된 변수는 항상 오류입니다.

@stefaneg를 작성한 지 몇 달 후 실제로 Terraform이 JSON 형식으로 작성된 구성을 지원한다는 것을 발견했기 때문에 이제 Mustache를 사용하는 대신 이것을 사용합니다. 이것은 훨씬 더 좋고 프로그래밍이 가능합니다. 이제 이에 대한 Mustache 사용이 더 이상 사용되지 않으며 배포 파이프라인의 다음 개정판에서 제거될 것입니다.

Kubernetes 배포 문서를 살펴보면 이것이 YAML 파일임을 알 수 있습니다. 대부분의 프로그래밍 언어에는 YAML을 읽고 쓸 수 있는 라이브러리가 있으므로 대신 이 작업을 수행하는 것이 좋습니다. 내 실험에서 나는 기계가 읽을 수 있는 형식을 조작하려고 할 때 거의 항상 Mustache보다 더 나은 선택이 있다는 것을 배웠습니다.

참고: 나는 더 이상 Mustache를 사용하지 않지만 이것이 유효한 기능 요청이라고 생각합니다.

해결책은 동일한 구문을 지원하고 이 사용 사례에 정확히 필요한 엄격한 옵션도 있는 핸들바를 사용하는 것입니다.

@steverukuts 지원해야 하는 미리 결정된 조작이 있는 경우, 특히 일부 스마트 기능이 내장되어 있어야 하는 경우 기계 판독 가능 형식을 조작하는 것이 옳습니다. 개방형 구성 도구의 경우 너무 빨리 유연성이 떨어지므로 템플릿이 필요합니다. 임의의 위치에 임의의 값 삽입을 지원하는 도구를 작성해 보십시오. 그러면... 곧 템플릿 엔진을 갖게 됩니다.

직장에서 우리는 지난 몇 년 동안 Kubernetes 리소스를 구성하기 위해 kontemplate 을 사용했습니다. 기본적으로 해당 프로젝트의 sprig 및 사용자 지정 기능의 몇 가지 편리한 기능이 있는 go 템플릿 엔진입니다. 예를 들어 키보다 가벼운 접근 방식으로 만들어졌습니다.

위의 논의와 관련하여; 알 수 없는 변수에서도 폭발합니다.

해결책은 동일한 구문을 지원하고 이 사용 사례에 정확히 필요한 엄격한 옵션도 있는 핸들바를 사용하는 것입니다.

이 문제로 인해 핸들바도 사용하게 되었습니다. 이것은 콧수염에서 지원되지 않는 것이 너무 나쁩니다.