Handlebars.js: 스트림 지원?

이것이 무엇을 수반하는지 또는 어떤 이점이 있는지는 정확히 명확하지 않습니다. 사용 사례는 무엇입니까?

파일/http 스트림 입력을 통한 더 빠른 구문 분석. 사용 사례는 빌드 스크립트 및/또는 gulp와의 호환성일 수 있습니다.

템플릿을 읽는 것은 컴파일 파이프라인의 느린 부분이 아니라 실제 구문 분석입니다. IO 대기 시간이나 구문 분석 전에 템플릿을 메모리에 로드하는 비용에 대해 우려할 만큼 충분히 큰 템플릿을 삽입하는 경우 , 템플릿에 하드 코딩된 데이터가 너무 많은지 궁금합니다.

그것과 우리의 파서 생성기 는 스트림 모드를 지원하지 않으므로 여기에서 비용/편익은 내 머리에서 실제로 작동하지 않습니다.

스트림을 사용하면 템플릿 문자열이 메모리에서 끝나지 않기 때문에 적은 메모리 소비 및 가비지 수집으로 동시에 많은 템플릿을 구문 분석할 수 있습니다.

메가 바이트를 푸시하는 경우 기껏해야 미세 최적화입니다.
템플릿을 파서에 넣으면 CPU에서 더 많은 문제가 발생합니다.
파서 자체에 바인딩됩니다.

지역 사회의 누군가가 조사를 해야 한다면 다음을 고려할 수 있습니다.
그것을 받아들이는 것이지만, 나는 그것이 기본적으로
파서.

2015년 12월 11일 금요일 오후 9시 23분 Steven Vachon [email protected]
썼다:

스트림을 사용하면 적은 수로 많은 템플릿을 동시에 구문 분석할 수 있습니다.
메모리 소비 및 가비지 수집.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/wycats/handlebars.js/issues/1150#issuecomment -164105284
.

스트리밍이 클라이언트 및 서비스 작업자에게 제공되면 다시 방문할 가치가 있습니까? https://jakearchibald.com/2016/streams-ftw/#creating -one-stream-from-multiple-sources-to-supercharge-page-render-times

또한 Dustjs는 https://wiki-offline.jakearchibald.com/ (설명 https://www.youtube.com/watch?v=d5_6yHixpsQ&feature=youtu.be&t=4m22s)을 구축할 때 정말 유용했습니다. 내 데이터가 더 느리게 도착했고 빠른 첫 번째 렌더링을 원했습니다.

Dustjs는 약속과 스트림을 템플릿 값으로 처리하지만 불행히도 Dustjs의 구문에 대해서는 할 말이 없습니다.

목록에 추가할 리소스가 하나 더 있습니다. https://jakearchibald.com/2016/streaming-template-literals/ (이 문제로 연결됨)