Handlebars.js: 기능 제안 | 동기/비동기 도우미

이것은 과거에 나타났지만 사용 사례가 명확하지 않아 조치를 취하지 않았습니다. 핸들바는 여전히 모든 데이터를 렌더링에 사용할 수 있을 때까지 기다려야 하므로 비동기 평가를 제공하는 것은 컨텍스트를 생성하는 코드가 훨씬 더 효율적인 방식으로 수행할 수 있는 작업에 대한 편의입니다.

기본적으로 이 시점에서 비동기 평가를 추가하는 것은 호환성과 런타임 성능 면에서 상당히 비쌀 것입니다. 당신이 하려는 일에 대한 구체적인 예가 있습니까?

성능 문제에 동의하지만 RegisterHelper & RegisterHelperAsync 또는 이와 유사한 것과 같이 선택적으로 aysnc로 만들 수 있다면 더 좋을 것이라고 생각합니다.

사실 저는 node.js로 작업하면서 이러한 비동기 핸들바에 대해 생각하게 되었습니다. 나는 express.js를 사용하여 일부 응용 프로그램에서 작업하고 있으며 사용하는 템플릿 엔진은 핸들바입니다. 따라서 뷰를 컴파일하는 동안 데이터베이스 호출에서 일부 값을 가져와야 하는 경우 이 동기 작업으로는 불가능합니다.

예를 들어,

Handlebars.registerHelper('getDbValue', function(id) {
     var Model = require('./myModel.js');
     Model.getValue(id, function(data){
           return data;
     });
});

위의 예는 작동하지 않으며 아무 것도 반환하지 않습니다. 다음은 제 개념입니다. 그리고 그것이 완전히 옳은지 아니면 구현할 수 있는지 여부는 모르겠습니다. 비동기 방식의 경우 리턴 대신 콜백 함수를 사용하기만 하면 됩니다.

Handlebars.registerHelperAsync('getDbValue', function(id, callback) {
     var Model = require('./myModel.js');
     Model.getValue(id, function(data){
           callback(data);
           //or
           //callback(new Handlebars.SafeString(data)); //in case of safestring.
     });
});

위와 같은 문제가 더 많이 발생하고 있으며 이 기능에 관심이 있는 사람이 있으면 내 시나리오에 따라 더 많은 예를 보여드릴 수 있습니다.

감사 해요

@robincsamuel , 뷰 생성에 데이터베이스 조회를 포함할 때 MVC 분리의 전체 아이디어는 창에 있습니다. 보기가 렌더링될 때까지 데이터가 필요하다는 것을 모를 수 있다고 주장하고 있다고 생각합니다. 그러나 보기를 생성할 때보다 컨트롤러 수준에서 구현해야 하는 기능을 제안합니다. @kpdecker가 언급한 성능 고려 사항과 결합하여 비동기 도우미는 잘못된 것처럼 보입니다. -- 내 2c

나는 단지 내 문제를 전달하기 위해 그 예를 사용했습니다. 그리고 나는 논쟁하려는 것이 아니라 단지 제안을 한 것입니다. 도우미의 콜백으로 함수를 호출하면 도움이 되기를 바랍니다. 아무튼 시간 내주셔서 감사합니다 :) @kpdecker @jwilm

이 시점에서 프로젝트의 입장은 템플릿을 호출하기 전에 데이터 분석을 수행해야 한다는 것입니다. 템플릿 문제 내부 또는 외부의 비즈니스 논리 외부에서 비동기 해결은 비동기 와 같은 다른 라이브러리가 처리에 훨씬 더 적합한 유틸리티 동작에 가깝습니다.

의견을 말하고 싶습니다. DB 예제를 창 밖으로 던지겠지만, 이것은 돌연변이 템플릿에 정말 도움이 될 수 있습니다. 예를 들어 내부에 "하위 보기"가 있고 여러 다른 템플릿으로 분할하고 싶지 않은 템플릿입니다. 전체 보기(깜박임 효과)를 다시 칠하거나 컨트롤러가 이러한 모든 "미니 보기"에 대한 전체를 빌드하도록 하는 대신 보기의 일부를 업데이트하고 이에 대한 간단한 논리를 갖고 싶습니다.

어떻게 생각해?

@tomasdev 내 말은 :)

이 기능은 https://github.com/barc/express-hbs를 사용하는 경우 Express가 있는 노드에서 사용할 수 있습니다. 그러나 도우미의 비동기 버전은 하위 표현식 및 기타 몇 가지 예외적인 경우와 잘 작동하지 않습니다.

핸들바에 포함하기 위해 이 기능을 재고하거나 최소한 핸들바 코어가 이러한 종류의 확장을 더 잘 지원할 수 있는 방법을 고려하고 싶습니다.

나는 Ghost가 비동기 도우미에 대한 명확하고 유효한(비록 흔하지는 않지만) 사용 사례를 보여주고 있다고 믿습니다.

프론트엔드에서 Ghost의 모든 템플릿은 테마별로 제공됩니다. 테마는 핸들바, CSS 및 클라이언트 JS의 매우 얇은 레이어이며 액세스할 수 있는 유일한 데이터는 우리가 미리 제공하는 것입니다. 컨트롤러 또는 동작 변경 논리에 액세스할 수 없습니다. 이것은 매우 의도적입니다.

테마 API를 확장하기 위해 테마에서 사용하려는 추가 데이터 컬렉션을 정의하는 도우미 추가를 시작하려고 합니다. 예를 들면 다음과 같습니다.

{{#fetch tags}}
.. do something with the list of tags..
{{else}}
No tags available
{{/fetch}}

Ghost에는 내부 및 외부에서 모두 사용할 수 있는 JSON API가 있습니다. 따라서 이 가져오기 쿼리는 찾아보기 태그 기능에 매핑됩니다. 모든 엔드포인트에 대해 ajax/http를 사용할 필요가 없습니다. 대신 비동기 도우미가 API에서 이 데이터를 내부적으로 가져와 평소처럼 계속할 수 있습니다.

나는 이것이 일반적인 사용 사례라고 주장하지 않으며 표준 MVC 모델을 위반하는 것을 인정하지만 그것이 유효하고 유용하다고 믿습니다.

@ErisDS 좋은 소식입니다! 그리고 저 역시 그것이 일반적인 문제라고 주장하지는 않지만 도움이 됩니다.

이 경우에 우리가 현재 비동기 도우미를 사용하고 있는 많은 작업이 내부적으로 동기적이지만 약속으로 구조화된다는 점에 주목할 가치가 있습니다.

자세한 예를 들자면...

Ghost의 모든 데이터는 내부 API를 통해 액세스됩니다. 여기에는 설정과 같은 전역 정보가 포함됩니다. 설정 API에 대한 요청은 데이터베이스에 도달하기 전에 미리 채워진 메모리 내 캐시에 도달하므로 실제로는 변수를 반환하지만 이것을 약속으로 구조화하면 필요한 경우 데이터베이스로 쉽게 이동할 수 있습니다.

또한 모든 것이 일관적인지 확인합니다. 그렇지 않으면 설정 API가 동기식이고 다른 모든 내부 데이터 요청은 비동기식이므로 의미가 없습니다.

모든 것을 약속으로 구성하는 것이 처음에는 상당히 혼란스러울 수 있다는 것을 압니다. 하지만 일단 약속을 갖고 나면 없이 어떻게 살았는지 이해할 수 없는 것 중 하나입니다. ES6에 제너레이터가 추가되면 함수의 비동기식 지원이 JavaScript에 바로 적용됩니다. 이와 유사한 문제: https://github.com/wycats/handlebars.js/issues/141 에서는 핸들바를 만드는 것이 좋을 것이라고 언급했습니다. 수율로 작업합니다.

HTMLbar의 향후 릴리스가 이에 어떻게 영향을 미칠지 모르겠지만 적어도 추가 논의가 필요하다고 생각합니다.

cl 해결을 위한 도우미를 만들려고 시도하는 동안 다른 사용 사례에 부딪쳤습니다. 이것은 내 템플릿에 잘 맞습니다.

        {{#allowedTo 'edit' '/config'}}
            <li>
                <a href="/config">Config</a>
            </li>
        {{/allowedTo}}

그러나 node-acl의 실제 isAllowed 메소드는 비동기식입니다(예를 들어 데이터베이스 백엔드 허용).

해결 방법은 모든 사용자 권한을 미리 가져오는 것입니다( allowedPermissions ). 하지만 그건 좀 가렵습니다.

@kpdecker 이러한 사용 사례에 대한 추가 생각이 있습니까?

@ErisDS 여기에서 원하는 것을 이해하지만 이것이 콜백 또는 약속 형식의 언어로 만들어질지 심각하게 의심됩니다. 이것은 API 관점에서 완전히 수행하기 매우 어려운 일이며 이를 지원하기 위해 템플릿 엔진의 많은 부분을 효과적으로 다시 작성해야 합니다. 내 권장 사항은 업스트림 모델/데이터 소스에서 렌더링 주기를 입력하기 전에 이 모든 것을 처리하는 것입니다.

수율 아이디어는 흥미로운 아이디어이지만 누군가가 거기에 필요한 것을 살펴보고 싶다면 놀라운 연구 프로젝트가 될 것입니다. 아직 내 프로젝트에 있는 기능 중 하나입니다.

내 "2"(음, 몇) 센트를 고려할 수 있습니다.

• MVC는 신성하지 않습니다. MVC와 모순되는 것처럼 보이기 때문에 상황이 잘못된 것은 아닙니다. MVC를 엄격하게 따르는 것보다 대안이 순 긍정적인 이점을 제공하지 않는지 여부를 평가해야 합니다.
• 뷰가 컨트롤러에 직접 모델이 아닌 데이터를 요청하면 어쨌든 MVC를 위반하는 것은 아니겠죠?
• 컨트롤러가 뷰가 필요로 하는 모든 것을 미리 알게 하는 것은 정보의 복제라고 주장할 수 있습니다(즉, "X, Y, Z, W가 필요합니다"라는 정보는 뷰와 컨트롤러에 복제됩니다). 즉, 현재 연습은 MVC보다 훨씬 더 중요한 DRY 원칙을 위반하는 것일 수 있습니다.
• 렌더링되는 보기에 필요한 모델만 로드하기 위한 비동기 도우미의 성능 저하는 데이터베이스에서 더 적은 데이터를 로드하여 쉽게 보상될 수 있습니다.

유용하게 사용할 수 있는 더 나은 예를 제공할 수 있습니다.

우리는 모바일 애플리케이션을 위해 Cordova로 많은 작업을 하고 있으며 많은 언어로 현지화해야 합니다. Cordova는 날짜, 숫자, 통화 등의 형식을 지정하는 데 도움이 되는 기능을 제공합니다.
문제는 모두 비동기 콜백이 필요하다는 것입니다.

예시:

Handlebars.registerHelper('stringToNumber', function(string, type)
{
    type = type || 'decimal';
    navigator.globalization.stringToNumber(string, function(number)
    {
        return number;
    }, function()
    {
        return NaN;
    }, {
        type: type
    });
});

이것은 imo가 있으면 굉장할 것입니다.

npm 에서 handlebars-async 패키지를 찾았습니다 . 그러나 그것은 조금 더 오래되었고 현재 Handlebars 버전에서 작동하는지 모르겠습니다.

나는 또한 약속에 대해 비슷한 것을 썼습니다. promise -handlebars 패키지를 사용하면 도우미 내에서 약속을 반환할 수 있습니다. 내 프로젝트 중 하나에서 사용할 계획이지만 지금까지 프로덕션 환경에서는 사용되지 않았습니다. 그러나 몇 가지 엣지 케이스(예: 비동기 블록 도우미 내에서 비동기 도우미 호출)에 대한 단위 테스트가 있으며 모두 녹색입니다...

@nknapp 정말 놀랍습니다! express-hbs 는 비동기를 지원하고 비동기는 블록 도우미에 대해 작동하지만 중첩된 비동기 도우미는 작동하지 않습니다. 그래서 저는 이것이 작동하는 것을 보는 데 정말로 관심이 있습니다. 이는 express-hbs에 대한 희망이 아직 있음을 의미합니다:+1:

@ErisDS , 거기에 게시해야 한다고 생각하십니까? 나는 이제 express-hbs 가 비동기 도우미를 중첩할 수 없다는 것을 알지 못했습니다. 내 주요 초점은 express 가 아니라 현재 작업 중인 README 생성기입니다. 나는 다른 사람들이 그것을 시도( promised-handlebars )하여 피드백을 주시면 정말 감사하겠습니다.

유효한 사용 사례에 추가하려면 현재 로케일을 기반으로 번역 DB에서 값을 가져와야 하는 경우 어떻게 해야 합니까?

<div class="howItWorks">
    {{{i18nFetch id=how-it-works locale=locale}}}
</div>

또한 다음과 같은 동적 ID를 사용하여 DB 항목에서 CMS 블록을 추가하는 것은 어떻습니까?

<div class="searchCms">
    {{{cmsLoader 'search-{$term}' term=params.input defaultId='search-default'}}}
</div>

이것은 특히 서버 측 렌더링에 유용합니다(즉, express-handlebars 사용).

여기 또 다른 사용 사례가 있습니다. 저는 외부 스키마 정의를 허용하는 Swagger( simple-swagger )용 문서 생성기를 작성하고 있습니다. 스키마가 외부에서 정의될 때 인식하고 해당 스키마가 있는 제공된 URL로 이동하여 검색하고 해당 데이터를 사용하여 Handlebars 템플릿의 해당 부분을 렌더링하는 Handlebars 도우미를 작성하고 싶습니다. Handlebars의 컴파일 메서드를 호출하기 전에 이 데이터를 검색해야 했다면 미리 구조를 알지 못하는 JSON 문서를 통해 재귀적으로 반복하고 외부 스키마의 모든 인스턴스를 찾아 검색하고 삽입해야 합니다. JSON.

기본적으로 Handlebars 템플릿을 사용하여 JSON 스키마 데이터( json-schema.org )를 렌더링하는 경우 JSON 스키마는 항상 스키마의 하위 부분을 외부에서 정의할 수 있도록 하기 때문에 비동기 렌더링 방법이 유용합니다.

@dwhieb 문서 생성기에 대한 bootprint -swagger 를 보셨습니까? 그것은 당신이 설명하는 것과 거의 같습니다(외부 스키마가 아직 구현되지 않았지만 이는 훌륭한 기능이 될 것입니다). 피드백이 있는 경우 문제를 여십시오.

그리고 나는 promise-handlebars 가 비동기 도우미와 잘 작동한다고 생각합니다.

도우미에서 약속을 사용할 수 있는 사용 사례가 있습니다. 핸들바를 사용하여 블로그용 HTML을 생성하고 있습니다. 각 기사에 대해 유효한 구조화된 데이터를 작성하려면 기사 이미지에 사용 중인 치수를 가져와야 합니다. 지금은 다음과 같이 하고 있습니다.

{{#imageSize post.frontMatter.previewImage}}
  <div itemprop="image" itemscope itemtype="https://schema.org/ImageObject">
    <meta itemprop="url" content="{{#staticResource ../post.frontMatter.previewImage}}{{/staticResource}}">
    <meta itemprop="width" content="{{width}}">
    <meta itemprop="height" content="{{height}}">
  </div>
{{/imageSize}}

imageSize 도우미는 파일을 동기적으로 읽기 때문에 작동하지만 I/O로 인해 페이지 렌더링 속도가 느려지지 않도록 비동기적으로 수행할 수 있어야 합니다. 또한 파일 시스템 대신 URL에서 이미지에 대해 이 작업을 수행하는 것은 불가능합니다.

promise-handlebars 및 express-hbs를 사용하는 방법을 살펴보겠습니다. 하지만 도우미 기능에서 promise를 사용하는 기능은 Handlebars에 큰 도움이 될 것입니다!

FWIW, 저는 Hyperscript, hyperscript-helpers , ES7의 async/await 를 사용하여 비동기 HTML 렌더링을 많이 해왔고 정말 즐거웠습니다. 그러나 물론 그 솔루션은 HTML에서만 작동합니다. 핸들바가 있는 비동기 솔루션을 사용하면 다른 종류의 파일을 비동기적으로 생성할 수 있습니다. 하지만 HTML의 경우에는 절대 뒤돌아보지 않을 것입니다!

express-hbs를 시도해 볼 예정이지만 2018년에는 지원하지 않는 것이 이상한 일이라고 생각합니다. 비동기 작업이 뷰의 일부로 수행되어서는 안 되며 대신 컨트롤러라는 마법 같은 작업에서 수행되어야 한다는 순수한 관점이 있다는 것을 알고 있습니다(MVC가 어떻게든 틀림없이 "올바른" 것처럼). 원인

a) 외부 라이브러리 - 대부분의 사람들은 이제 완전히 async/await를 사용하여 작성합니다. 내 코드에서는 10개 중 9개 이상의 함수가 비동기식이라고 생각합니다... 어떤 경우에는 "만약에 대비하여"입니다. 비동기 기능을 지원하지 않는다는 것은 모든 비동기 라이브러리가 갑자기 완전히 액세스할 수 없다는 것을 의미합니다.

b) 일반 컨트롤러 기능. 나는 다음과 같이 주장합니다.

    {{#query "select name, total from summary"}}
          <tr><td>{{this.name}}</td><td>{{this.total}}</td></tr>
    {{/query}}

해당 항목을 변수에 집어넣고 템플릿으로 전달하는 맞춤형 컨트롤러 기능을 사용하는 것과 비교할 때 템플릿이 알고 액세스해야 하는 것과 비교할 때 더 짧고, 깨끗하고, 유지 관리하기 쉽고, 기본적으로 생각할 수 있는 모든 면에서 월등합니다.