@mbrodala 보고서에 감사드립니다. 해당 코드펜에 감사드립니다!

@mbrodala codepens 에 감사드립니다.
여기에 오해가 있었는지 궁금합니다.

643 및 #664는 #617에서 보고한 버그를 수정합니다. 이는 #643과 함께 제공되는 이 테스트에서 설명합니다.

  describe('when parsing a template with tags specified followed by the same template with different tags specified', function() {
     it('returns different tokens for the latter parse', function() {
       var template = "(foo)[bar]";
       var parsedWithParens = Mustache.parse(template, ['(', ')']);
       var parsedWithBrackets = Mustache.parse(template, ['[', ']']);
       assert.notDeepEqual(parsedWithBrackets, parsedWithParens);
     });
   });

parse 함수는 캐시 키로 template 만 사용하여 캐싱하므로 다음에 parse 를 사용하여 해당 템플릿을 구문 분석하면 정확히 동일한 토큰을 반환합니다. 지정된 tags 가 다른 경우.

tags 는 선택적 매개변수이며 생략하면 기본적으로 ['{{', '}}'] 인 mustache.tags 로 대체됩니다. 대체 mustache.tags 는 캐시 키의 일부로 사용됩니다.

버그 수정 및 기대치와 관련하여 무슨 일이 일어나고 있는지 알고 있다고 생각합니다. 이에 대해 살펴보고 codepen을 예로 사용하겠습니다.

v2.3.0

Mustache.parse(template, ['[[', ']]']);

2.3.0에서 이것은 ['[[', ']]'] 를 태그로 사용하여 $ template 를 구문 분석하도록 Mustache에 지시합니다. Mustache는 그렇게 하고 올바른 결과를 반환하지만 template 만 사용하여 호출을 캐시합니다. [email protected] 의 447-450행 참조:

    if (tokens == null)
       tokens = cache[template] = parseTemplate(template, tags);

codepen의 다음 호출은 다음과 같습니다.

var output = Mustache.render(
  template,
...

render 는 tags 매개변수를 사용하지 않으므로 parse $ 에 매개변수를 전달하지 않으므로 render 가 호출될 때 $ parse 는 mustache.tags 를 사용합니다. render 호출이 이루어지면 효과적으로 parse " template 를 구문 분석하고 ['{{', '}}'] 를 tags 으로 사용하십시오. parse 는 실제로 잘못된 일을 하고 tags 및 mustache.tags 모두를 완전히 무시하고 캐시 조회를 수행합니다. [['[', ']']] 로 구문 분석된 템플릿의 결과 를 반환하지만 해당 template 에 대한 전체 프로그램에서 parse 에 대한 첫 번째 호출이 ['[[', ']']] 로 이루어졌기 때문입니다. tags .

v2.3.1

Mustache.parse(template, ['[[', ']]']);

구문 분석 결과는 template 및 tags 를 모두 사용하여 캐시됩니다. ['[[', ']]'] 는 cacheKey입니다.

다음 호출:

var output = Mustache.render(
  template,
...

render 는 parse $ 를 호출하고 $#$ template #$ 를 전달하지만 tags 는 생략합니다. 따라서 parse 에는 tags 가 mustache.tags 로 대체되며, 이는 기본 ['{{', '}}'] 로 유지됩니다. parse 는 template 및 ['{{', '}}'] 의 캐시 키에 대해 캐시 조회를 수행하고 parse 가 아직 호출되지 않았기 때문에 예상대로 캐시 누락이 발생합니다. template 및 태그의 조합으로. 따라서 ['{{', '}}'] $ 를 사용하여 $ template 를 구문 분석합니다.

나는 v2.3.1이 올바른 동작을 보인다고 믿습니다. https://codepen.io/mbrodala/pen/QBJoOx 에서 codepen을 약간 변경하고 v2.3.0에 대해 실행한다면:

var template = "[[item.title]] [[item.value]]";
Mustache.parse(template, ['[[', ']]']);
var output = Mustache.render(
  template,
  {
    item: {
      title: "TEST",
      value: 1
    }
  }
);
alert(output);

출력은 예상하지 못한 [[item.title]] [[item.value]] 입니다.

Mustache.parse 및 Mustache.render 호출이 서로 바로 옆에 있고 하나가 아닐 수도 있기 때문에 https://codepen.io/mbrodala/pen/NBEJjX 의 동작이 얼마나 놀라운지 알 수 있습니다. Mustache.parse 는 tags 인수도 취한다는 사실을 깨닫습니다. ( Mustache.parse 가 tags 인수를 취하는 이유는 무엇입니까? mustache.js -- parse 내부적으로는 기본적으로 mustache.tags 어디에도 사용되지 않습니다. ..)

행동의 변화가 실제로 bugfix 릴리스의 기대를 무시한다면 무엇을 해야 할지 정확히 모르겠습니다. 한 가지 가능성은 #664가 되돌려진 다른 버그 수정 버전을 릴리스하는 것입니다. 이 버전은 사실상 모든 캐싱 동작을 제거합니다(#643에서 모든 캐시 조회가 누락됨). 그런 다음 #664를 다음 주요 개정판에 다시 넣을 수 있습니다. 또 다른 가능성은 bugfix 릴리스에서 모든 캐싱을 제거하고(비기능적 캐싱으로 mustache.js 를 릴리스하는 것과 반대) 모든 캐싱을 다음 주요 개정판에 다시 넣는 것입니다. 전자의 옵션은 위험이 덜하지만(코드 변경이 가장 적음) 후자의 옵션이 더 "올바릅니다". @phillipj 생각?

내 POV에서 완전히 이해되는 자세한 연구에 감사드립니다.

변경 사항에 대해 전혀 신경 쓰지 않지만 캐시 적중을 보장하기 위해 tags 를 Mustache.render() 에 전달하는 것이 불가능하고 Mustache.parse() 가 template 를 캐시하도록 광고된다는 점을 감안할 때 tags 에 대한 언급 없음) 이것이 정말로 되돌려져야 하는지 궁금합니다.

tags Mustache.parse 를 호출한다고 가정하면 template 가 이러한 구분 기호를 사용한다고 가정할 수도 있습니다(BTW, "태그" 대 "구분자"는 역시 클리어). 그 다음에 우리는 주어진 template 가 이미 캐시되었는지 여부와 그러한 경우 컴파일된 방법에 상관없이 Mustache.render 에 대한 호출이 작동할 것으로 예상된다고 가정할 수 있습니다. 지금은 사용자 정의 tags 가 사용되는 경우 보장되지 않습니다.

@mbrodala 네, 맞습니다. Mustache.parse(template, ['[[', ']]']); 다음에 Mustache.parse(template, ['((', '))']); 가 뒤따르면 정확히 같은 결과가 나오는 것은 여전히 ​​예상치 못한 일입니다.

다음은 밀짚맨 솔루션/타협입니다("밀짚맨"은 마음에 들지 않지만 브레인스토밍할 가치가 있기 때문입니다). template 단독 및 태그 포함 template 모두에 대해 parse 캐시를 가질 수 있습니다. parse 가 지정된 tags 로 호출되면 $ template 및 tags 에 대해 조회를 수행합니다. tags parse 를 호출하는 render 를 호출하면 template 만 조회합니다. 생각?

소리가 들리지 않고 기본적으로 수정 사항을 그대로 유지하면서이 문제를 해결할 것입니다. 내 POV에서 확인합니다.

@mbrodala 는 tags 을 render 에 전달할 수 없다는 핵심 문제입니까? tags 매개변수를 render 에 추가할 수도 있습니다.

@petrkoutnysw 이것도 대략적으로 겪었던 문제인가요?

적어도 parse() 와 render() 사이의 불일치입니다. 실제로 render() 에 사용자 정의 태그를 전달할 수 있다면 parse() 도 사용하지 않을 것입니다. 이제 적절한 캐싱이 이루어지면 이것이 더욱 분명해집니다.

많은 혼란을 없애기 위해 태그 매개변수를 render()에 추가하는 데 +1 -- 우리는 이 변경 사항에도 약간의 영향을 받았고 링크 b/w 구문 분석 및 렌더링은 항상 필요한 것보다 약간 더 마술처럼 보였습니다.

자, 그렇다면 버그 수정 릴리스에서 캐싱을 비활성화하여 즉각적인 문제를 수정하고 의미론적 버전 관리를 준수하고 다음 주요 릴리스에서 tags와 tags 를 render 메서드에 다시 도입하는 것은 어떻습니까? (다시 말하지만, 나는 내가 제안한 밀짚맨 솔루션의 열렬한 팬이 아닙니다.)

철저한 연습 @raymond-lam에 감사드립니다!

저는 제안된 버그 수정 릴리스에 기대고 있습니다. 주로 semver 문제와 이러한 동작 변경이 예상하지 못하여 프로젝트에 혼란을 초래할 수 있는 프로젝트 때문입니다.

계획된 다음 주요 릴리스에서 캐싱 동작을 다시 도입하여 릴리스 정보에 마이그레이션 지침을 포함할 수 있습니다.

@phillipj #643 및 #664를 롤백하는 pull request #670을 발행했습니다. 캐싱을 모두 비활성화하는 대신 위험 완화를 위해 단순히 v2.3.0 동작(버그 수정 릴리스에서)으로 돌아가는 것이 Mustache v2.xx에 종속된 사람들에게 가장 안전한 것처럼 보입니다. 주요 릴리스에서 다시 도입하기 위해 또 다른 풀 리퀘스트를 발행하겠습니다.

@phillipj #671은 주요 릴리스를 기다리기 위해 캐싱 수정 사항을 다시 도입합니다.

tags 를 `render.xml에 추가하는 문제를 해결하기 위해 문제 #672를 만들었습니다.

이 문제를 조사하고 수정해 주셔서 감사합니다. 👍

@raymond-lam에게 감사의 인사를 전합니다! 여러분 덕분에 예상치 못한 변화가 언제 발생했는지 알 수 있습니다.

v2.3.2 가 출시되었습니다 🚀