什么是javascript模板引擎？如何使用javascript写模板引擎代码思路和实例详解

大家好，关于什么是javascript模板引擎很多朋友都还不太明白，不过没关系，因为今天小编就来为大家分享关于如何使用javascript写模板引擎代码思路和实例详解的知识点，相信应该可以解决大家的一些困惑和问题，如果碰巧可以解决您的问题，还望关注下本站哦，希望对各位有所帮助！

模板引擎的用途

模板引擎可以让（网站）程序实现界面与数据分离，这就大大提升了开发效率，良好的设计也使得代码重用变得更加容易。

我们司空见惯的模板安装卸载等概念，基本上都和模板引擎有着千丝万缕的联系。模板引擎不只是可以让你实现代码分离（业务逻辑代码和用户界面代码），也可以实现数据分离（动态数据与静态数据），还可以实现代码单元共享（代码重用），甚至是多语言、动态页面与静态页面自动均衡（SDE）等等与用户界面可能没有关系的功能。

如何使用javascript写模板引擎代码思路和实例详解

AbsurdJS本身主要是以NodeJS的模块的形式发布的，不过它也会发布客户端版本。考虑到这些，我就不能直接使用现有的引擎了，因为它们大部分都是在NodeJS上运行的，而不能跑在浏览器上。

最初的想法是这样子的：

一个简单的函数，输入是我们的模板以及数据对象，输出么估计你也很容易想到，像下面这样子：

<p>Hello, my name is Krasimir. I'm 29 years old.</p>其中第一步要做的是寻找里面的模板参数，然后替换成传给引擎的具体数据。我决定使用正则表达式来完成这一步。不过我不是最擅长这个，所以写的不好的话欢迎随时来喷。

这句正则表达式会捕获所有以<%开头，以%>结尾的片段。末尾的参数g（global）表示不只匹配一个，而是匹配所有符合的片段。Javascript里面有很多种使用正则表达式的方法，我们需要的是根据正则表达式输出一个数组，包含所有的字符串，这正是exec所做的。

如果我们用console.log把变量match打印出来，我们会看见：

不过我们可以看见，返回的数组仅仅包含第一个匹配项。我们需要用while循环把上述逻辑包起来，这样才能得到所有的匹配项。

如果把上面的代码跑一遍，你就会看见<%name%>和<%age%>都被打印出来了。

下面，有意思的部分来了。识别出模板中的匹配项后，我们要把他们替换成传递给函数的实际数据。最简单的办法就是使用replace函数。我们可以像这样来写：

好了，这样就能跑了，但是还不够好。这里我们以data["property"]的方式使用了一个简单对象来传递数据，但是实际情况下我们很可能需要更复杂的嵌套对象。所以我们稍微修改了一下data对象：

不过直接这样子写的话还不能跑，因为在模板中使用<%profile.age%>的话，代码会被替换成data[‘profile.age']，结果是undefined。这样我们就不能简单地用replace函数，而是要用别的方法。如果能够在<%和%>之间直接使用Javascript代码就最好了，这样就能对传入的数据直接求值，像下面这样：

var template='<p>Hello, my name is<%this.name%>. I\'m<%this.profile.age%> years old.</p>';你可能会好奇，这是怎么实现的？这里John使用了new Function的语法，根据字符串创建一个函数。我们不妨来看个例子：

fn可是一个货真价实的函数。它接受一个参数，函数体是console.log(arg+ 1);。上述代码等价于下面的代码：

通过这种方法，我们可以根据字符串构造函数，包括它的参数和函数体。这不正是我们想要的嘛！不过先别急，在构造函数之前，我们先来看看函数体是什么样子的。按照之前的想法，这个模板引擎最终返回的应该是一个编译好的模板。还是用之前的模板字符串作为例子，那么返回的内容应该类似于：

当然啦，实际的模板引擎中，我们会把模板切分为小段的文本和有意义的Javascript代码。前面你可能看见我使用简单的字符串拼接来达到想要的效果，不过这并不是100%符合我们要求的做法。由于使用者很可能会传递更加复杂的Javascript代码，所以我们这儿需要再来一个循环，如下：

如果使用字符串拼接的话，代码就应该是下面的样子：

当然，这个代码不能直接跑，跑了会出错。于是我用了John的文章里写的逻辑，把所有的字符串放在一个数组里，在程序的最后把它们拼接起来。

下一步就是收集模板里面不同的代码行，用于生成函数。通过前面介绍的方法，我们可以知道模板中有哪些占位符（译者注：或者说正则表达式的匹配项）以及它们的位置。所以，依靠一个辅助变量（cursor，游标），我们就能得到想要的结果。

上述代码中的变量code保存了函数体。开头的部分定义了一个数组。游标cursor告诉我们当前解析到了模板中的哪个位置。我们需要依靠它来遍历整个模板字符串。此外还有个函数add，它负责把解析出来的代码行添加到变量code中去。有一个地方需要特别注意，那就是需要把code包含的双引号字符进行转义（escape）。否则生成的函数代码会出错。如果我们运行上面的代码，我们会在控制台里面看见如下的内容：

等等，貌似不太对啊，this.name和this.profile.age不应该有引号啊，再来改改。

占位符的内容和一个布尔值一起作为参数传给add函数，用作区分。这样就能生成我们想要的函数体了。

剩下来要做的就是创建函数并且执行它。因此，在模板引擎的最后，把原本返回模板字符串的语句替换成如下的内容：

return new Function(code.replace(/[\r\t\n]/g,'')).apply(data);我们甚至不需要显式地传参数给这个函数。我们使用apply方法来调用它。它会自动设定函数执行的上下文。这就是为什么我们能在函数里面使用this.name。这里this指向data对象。

模板引擎接近完成了，不过还有一点，我们需要支持更多复杂的语句，比如条件判断和循环。我们接着上面的例子继续写。

这里会产生一个异常，Uncaught SyntaxError: Unexpected token for。如果我们调试一下，把code变量打印出来，我们就能发现问题所在。

带有for循环的那一行不应该被直接放到数组里面，而是应该作为脚本的一部分直接运行。所以我们在把内容添加到code变量之前还要多做一个判断。

这里我们新增加了一个正则表达式。它会判断代码中是否包含if、for、else等等关键字。如果有的话就直接添加到脚本代码中去，否则就添加到数组中去。运行结果如下：

当然，编译出来的结果也是对的。

My skills:<a rel="external nofollow" rel="external nofollow" rel="external nofollow" href="#">js</a><a rel="external nofollow" rel="external nofollow" rel="external nofollow" href="#">html</a><a rel="external nofollow" rel="external nofollow" rel="external nofollow" href="#">css</a>最后一个改进可以使我们的模板引擎更为强大。我们可以直接在模板中使用复杂逻辑，例如：

除了上面说的改进，我还对代码本身做了些优化，最终版本如下：

如何选择Web前端模板引擎(推荐)

本篇文章给大家带来的内容是关于如何选择Web前端模板引擎（推荐），有一定的参考价值，有需要的朋友可以参考一下，希望对你有所帮助。

模板引擎负责组装数据，以另外一种形式或外观展现数据。浏览器中的页面是 Web模板引擎最终的展现。

无论你是否直接使用模板引擎，Web模板一直都在，不在前端就在后端，它的出现甚至可以追溯到超文本标记语言 HTML标准正式确立之前。

服务器端的模板引擎

我所知道最早的 Web模板引擎是 PHP，它正式诞生于 1997年，工作在服务器端。让我们看看 PHP官方的 intro-whatis：

HPer普遍赞同 PHP本身就是最天然、原生的 PHP模板引擎，因为她本来就是。在 PHP的世界里多次出现过再包装的模板引擎，著名的有 smarty。

其它服务器端语言很多都有 HTML模板引擎，比如 JSP、mustache。

毫无疑问，这些服务器端模板引擎最终生成的结果是 HTML(XML)字符串，处理流程逻辑使用宿主语言本身的语法实现。

它们的共同特征：HTML只是个字符串,最终结果可能还需要类似 Tidy这样的清洁或修正验证工具。

这里提出一个问题：二次封装的 smarty有存在的必要么?

浏览器端的模板引擎

我所知道最早的前端模板引擎是 jCT，它托管于 Google Code，诞生于 2008年，宿主语言是 JavaScript，工作在浏览器中。

今天在 OSC搜索 JavaScript模板引擎你会得到 100+个结果，下边列举一些：

轻量度：tpl.js、T.js

认知度：arttemplate、mustache.js、doT.js、handlebars.js、pug

DOM-tree-based：domTemplate、transparency、plates

VDOM-based：htmltemplate-vdom、virtual-stache、html-patcher

流行框架：Vue.js、ReactJS、riot

Real-DOM：PowJS

它们的共同特征：全都支持插值。

这里还有 templating-engines受欢迎度的对比，甚至 best-javascript-templating-engines投票及正反方的理由。

如何选择

我认为存在即合理，每个引擎、框架总有可取之处，至少在你的应用里，在某个时代，所以本文不会评论某个引擎哪一点不好，那样是不客观的。现在回答前边提到的问题：smarty有存在的必要么？我的答案是：有。理由很简单，看给谁用、看大背景。对于前后端没有分离的应用，或前端人员对后端语言不够熟悉，或因岗位职责需要，那么前端人员掌握一种比较通用的模板语法(语言)是现实的，反之让 PHPer自己去使用 smarty那就太浪费技能了。

下面是通常意义上的引擎选择建议：

前提，选择的引擎能满足数据渲染需求，且不和现有依赖冲突，如果你已经非常熟悉某个引擎，那你已经有答案了。

是一次性的项目需求么?是的话直接选择轻量的，学习复杂度最低的。是要做组件开发么?

引擎支持预编译结果，不必每次都实时编译么?

要跨平台么?有官方提供支持的，首选类 React-JSX的引擎或纯粹的 VDOM引擎。

选择学习或维护复杂度最低的，众所周知，开发者对调试的时间超过写代码的时间深恶痛绝。

最后才是性能对比，性能对比是一件非常细致的工作，他人的对比结果不一定符合你的场景。

我认为应该弱化语法风格的对比，偏好是没有可比性的，一些语法甚至有特殊的背景原因。

为什么最后才是性能对比？

性能的确很重要，但如果性能还没有影响到你的应用体验度，那就忽视它。很难真实地模拟应用场景，通常只有通过真实场景来检验，目前的测试工具还达不到这种效果。

前述问题有些有固定答案，下面讨论余下的问题：如何考虑组件开发、支持预编译、复杂度？

组件开发

进行组件开发已经不再是选择模板引擎的问题了，这是生态环境选择的问题。如果你的应用需要更快地完成，那么时间点是第一位的，就选择流行框架，有足够多的组件让你使用或参考。如果你的应用有独立的生态环境，需要技术选型以便长期维护，那继续看下文。

预编译

预编译应该具备：

编译结果在目标环境中不再需要编译过程。

编译结果可调试性，这意味着结果应该包含原生 ECMAScript代码，而不是纯粹的数据描述。

大家都知道 React-JSX是支持预编译的，官方的说法是 React Without JSX，即总是 build过的。

一些基于字符串处理的引擎也支持预编译。如果你需要预编译，建议抛弃编译结果依然是基于字符串拼接的引擎，那样还不如不预编译，那是 HTML5未被广泛支持之前的技术手段。

至少也要有类似 React-JSX这样的编译结果才具有可调试性。备注：Vue.js支持多种模板引擎，可达到同样的效果。

原 ReactJS代码，其中用到了 Web Components技术：

class HelloMessage extends React.Component{

render(){

return<p>Hello<x-search>{this.props.name}</x-search>!</p>;

}

}编译后：

class HelloMessage extends React.Component{

render(){

return React.createElement(

"p",

null,

"Hello",

React.createElement(

"x-search",

null,

this.props.name

),

"!"

);

}

}不少 VDOM引擎也可以编译类似效果，比如 htmltemplate-vdom。

<script>

var id= 3;

var env={

people: [

{

id:'id1',

name:'John',

inner: [{ title:'a1'},{ title:'b1'}],

city:'New York',

active: true

},

{

id:'id2',

name:'Mary',

inner: [{ title:'a2'},{ title:'b2'}],

city:'Moscow'

}

],

githubLink:'https://github.com/agentcooper/htmltemplate-vdom',

itemClick: function(id){

env.people.forEach(function(person){

person.active= String(person.id)=== String(id);

});

loop.update(env);

}

// Omitted....

};

</script>复杂度

很难用唯一的标准去评判两个引擎哪个复杂度低，这是由使用者的思维模式不同造成的。例如前边列出的引擎在使用上以及预编译结果上的区别，不同使用者感触是不同的，这正是不同引擎存在的合理性、价值性。

有的使用者认为这个应用场景有字符串模板就满足了需求，轻量够用。

有的使用者认为字符串拼接技术的模板引擎不够强壮，不够时代感。

有的使用者认为OOP够理性，够逻辑，够抽象。

有的使用者认为原生 HTML才叫前端。

有的使用者认为 VDOM适用性更广。

这些评判都有各自的理由，着眼点不同，标准也就不同了。但是我们还是可以从它们的共性去考虑它们的复杂度。

字符串类模板通常都很轻量，不在本节讨论范围之内。对于非字符串模板复杂度评判的共性标准是什么？我认为，可以考量数据绑定的复杂度。

本文所指的数据绑定不只是插值，还包括上下文以及事件，甚至是整个运行期的宿主环境。

事实上至少需要达到 VDOM级别的引擎才具有这种能力，因为通过 VDOM可以映射到真实的 DOM节点。

大概有几种模式(组合)：

1.入口参数是个 Object，模板中的变量 x是该对象的.x属性，例：virtual-stache-example

2.特定语法或属性，比如：Vue.js的...，属性 computed、methods

3.抽象的语义化属性，比如：Vue.js的 active这个词适用于多种场景，容易理解且不产生歧义

4.不负责绑定，需要使用者非常熟悉原生方法，用原生方法进行绑定，比如：PowJS

这些模式只是理论方面的，通常是模板引擎设计者要解决的问题。对于使用者来说不如直接问：

1.可以在 HTML模板中直接写最简单的 console.log(context)来调试么?

2.可以在多层 DOM树绑定或传递不同的上下文参数么?

3.可以在多层 DOM树内层向上访问已经生成的 Node么?

模板引擎团队会给你正确的解决办法，但通常和问题字面描述的目标有所差异。我觉得这就是你评判选择的关键，你对官方给出的正确方法的认可度。

嵌入到 DOM中

嵌入到 HTML中

PowJS是这么实现的：

实现模板必须要实现的指令

预编译输出原生 ECMAScript代码

模板语法结构与 ECMAScript函数写法一致

最终，写 PowJS模板就像在写 ECMAScript函数。

GoHub index中的写法

<template>

<details func="repo" param="data" if="is.object(data.content)&&!sel(`#panel details[sha='${data.sha}']`)"

open

let="ctx=data.content"

sha="{{data.sha}}"

origin="{{ctx.Repo}}"

repo="{{data.owner}}/{{data.repo}}"

subdir="{{ctx.Subdir||''}}"

filename="{{ctx.Filename}}"

render=":ctx"

do="this.renew(sel(`#panel details[repo='${data.owner}/${data.repo}']`))"

break

>

<summary>{{ctx.Description}}</summary>

<p if="':';" each="ctx.Package,val-pkg">

<p title="{{pkg.Progress}}:{{pkg.Synopsis}}">{{pkg.Import}}</p>

</p>

</details>

<dl func="list" param="data"

if="!sel(`#panel details[sha='${data.sha}']`)&&':'||'';"

each="data.content,data.sha,val-rep"

do="this.appendTo(sel('#panel'))">

<details sha="{{sha}}" repo="{{rep.repo}}">

<summary>{{rep.synopsis}}</summary>

</details>

</dl>

</template>多数模板引擎都会实现 if、each这些指令，上面的 PowJS模板中还有：

全局对象 is、sel

模板(函数)命名 repo、list

模板(函数)入口形参 data

自定义局部变量 ctx

下层模板(函数)形参推导 data.sha->sha

遍历值到下层模板形参推导(ctx.Package,val-pkg)->pkg、(data.content,val-rep)->rep

DOM节点操作 this.renew、 this.appendTo，这直接渲染到页面 DOM树

流程控制 break

伪节点 if="':';"，渲染时根本不生成 p节点，它是个伪节点，相当于块代码符号"{}"

关键是整个模板结构，指令语义和 ECMAScript函数完全一致：

没有数据绑定，你写的是 ECMAScript函数，传参数好了，要什么绑定

没有事件绑定，每个节点都是真实存在的，直接写 addEventListener就好了

要调试，随便找个 do或 if或 let插入 _=console.log(x),就好了，逗号表达式几乎可以无缝插入所有原生语句

所有的业务逻辑都是使用者自己写的，PowJS只负责把他们粘合成一个函数

导出视图是 ECMAScript源码，下图截取自演示 My Folders

那么 PowJS是最终的选择么？PowJS的理念是原生性，原生的 DOM，原生的 ECMAScript。

原生也同样是 PowJS的问题所在，不是所有的使用者都喜欢原生，我相信有的使用者更喜欢更抽象风格，他们眼中的原生总是带了点"原始"。

原生意味着你可以扩展，引入其它 library进行搭配，但 PowJS永远不会出现 define setter/getter实现的 watcher，那超出了模板引擎的范围，如果有那一定是独立的项目。

最后，我的观点依然是：你的需求才是选择模板的关键，适合你的才是好的。

文章到此结束，如果本次分享的什么是javascript模板引擎和如何使用javascript写模板引擎代码思路和实例详解的问题解决了您的问题，那么我们由衷的感到高兴！