ETpl的演进

errorrik ETpl, JavaScript, 模板引擎

如果有人看过我写的《AMD系列三部曲 一 二 三》，就会知道我是个唐僧。这次，唐僧想说说ETpl。

ETpl是一个JavaScript的模板引擎。JavaScript最广泛被应用于浏览器端，通常JavaScript模板引擎的作用就是生成HTML串。ETpl当前的版本是3.0，也就是说，算上最初设计时，它经历了3次技术上比较大的选型。

今天，ETpl号称是一个强复用、灵活、高性能的JavaScript模板引擎，有很多别人有或者别人没有的功能，这些都是what。而我一直认为why比what更重要，了解背后的原因、了解思考的过程比知道是什么有更大的收获，所以这次想要啰嗦的，是ETpl在走到今天的过程中，那些what背后的why。如果你能忍受我的八婆把它看完，应该多少能有点收获，越到后面技术点越多噢。

因为本篇比较长，开始先求个star支持下呗，反正不花钱

1.0时，我们做了这些事情

ETpl是没有独立的1.0版本的。在2010年初，我们为一个SPA应用做重构的时候，开发了ER - Enterprise RIA框架的1.0版本，当时ER框架自带了一个模板引擎，这就是ETpl的1.0。当时的想法很简单，我们要解决下面这些最基本的问题：

  1. 在JavaScript里面写HTML片段的字符串是不人道的，应该写到另外的文件中
  2. 有的HTML片段是需要被复用的
  3. 同样的数据在一个片段中可能会重复出现多次

Command语法

我们认为，最基本的单元应该是一个模板片段。我们需要设计一种语法，来描述这样的片段。

  1. 大多数时候我们的模板片段会是HTML，我们不希望放弃Editor本身提供的HTML语法高亮、自动补全等功能，所以我们可以通过特殊格式的HTML注释来描述模板片段
  2. 开发时我们可能每一个文件是一个模板片段，构建时为了优化HTTP请求，这些文件需要合并，我们期望合并可以是简单的，直接合并文件内容就行。所以模板片段需要有开始和结束，我们认为标签式是比较好的方式
  3. 合并后模板片段需要能够被分别辨认，而且模板片段需要能被复用，所以模板片段需要被命名
  4. 最后面临的是命名问题：哪个单词用来描述一个基本的模板片段单元比较合适呢？选来选去，我们选了target

基于以上，ETpl的语法风格在2010年初被最初固定下来了（在很久以后的2013年，我们才让它可定制化）。

1
2
3
[target]
start tag: <!-- target: target-name -->
end tag: <!-- /target -->

然后我们开始设计如何描述复用。自然而然的，把target换成import就行了。在设计的过程中，我们受到一些HTML的启发：input、img之类的标签是可以不用自闭合的，不是每个标签都需要闭合，我们不是写XML。所以，import没有闭合。

1
2
[import]
tag: <!-- import: target-name -->

基于以上，一个模板可以这么写：

1
2
3
4
5
6
7
8
<!-- target: header -->
    <header>...</header>
<!-- /target -->

<!-- target: biz1 -->
    <!-- import: header -->
    <div class="content">...</div>
<!-- /target -->

举一反三的，还是受到HTML的启发：li、td、body等标签是不需要写闭合的，parser能够自动在合适的位置认为标签已经结束。比如遇到li的start，就知道上一个li应该结束了。所以我们决定支持target自动闭合，让模板编写者少写一点东西。

1
2
3
4
5
6
<!-- target: header -->
<header>...</header>

<!-- target: biz1 -->
<!-- import: header -->
<div class="content">...</div>

到这里，从target和import可以看出来，ETpl的语法格式已经被固定下来了：

  1. 起始由command-name和command-value组成，:分隔
  2. 闭合由/command-name组成

罗马不是一天建成的。基于最早的语法形式，我们不断的通过命令扩展功能，加入了if、for，这都是比较常规的事情了。

变量替换

变量替换是模板引擎的基本功能。从下面的例子可以看出，我们使用的变量替换语法比较大众化：

1
Hello ${name}!

ETpl的主要使用场景是HTML生成。在HTML中常用两种转义方式：

  1. HTML转义，要显示变量值可能是原始的来源于用户输入的串，不转义有危险
  2. URL转义，变量值可能用于图片的src或者a的href

我们通过filter的方式，使变量替换过程的中间能够加入一些处理。

1
Hello ${name|html}!

大多数变量替换后的内容会用于直接视图显示，所以我们在不写filter的时候，默认使用html filter进行处理。但是还有一些场景我们是期望输出原始值的，我们引入了一个raw filter用于支持这种情况。这样，我们内置了3个filter，这点一直到现在都没变：

  1. html (default)
  2. url
  3. raw

另外，通过etpl.addFilter(name, filter)方法也可以自己添加filter。

1
2
3
etpl.addFilter('test', function (source) {
    return source + '!';
});

母版

在SPA应用开发的过程中，我们发现在一个应用里，页面类型的种类很可能是固定的几种，基本所有页面都是在相同的页面框架下，不同部分的内容有一定的区分，所以我们立即就加入了母版的功能(有的模板引擎叫做模板继承，其实是一回事)。

母版功能的语法，参考的是Asp.net，使用了master、contentplaceholder、content，下面这个例子应该容易理解：

1
2
3
4
5
6
7
8
9
<!-- target: biz(master = frame) -->
<!-- content:header -->header<!-- /content -->
<!-- content:body -->body<!-- /content -->
<!-- content:footer -->footer<!-- /content -->

<!-- master: frame -->
<header><!-- contentplaceholder: header --></header>
<div><!-- contentplaceholder: body --></div>
<footer><!-- contentplaceholder: footer --></footer>

母版功能再配合import使用，使开发过程中的重复代码量减少很多，特别是对于SPA类型的应用。母版功能是好的，但是，这样的写法真的不友好。我们直到3.0时，才重新改进了它。

Data Getter

根据数据名称生成数据的功能，我们在最早的时候就支持了。可以看看这个例子。

这个功能有什么用呢？看起来是没啥用的，但是它提供了数据的动态性，让数据可以在render的过程决定：

  1. 数据来源于多对象，有优先级。这种场景其实可以通过merge解决，但for in可能更耗时。
  2. 没有数据时需要自动生成一个，然后写入缓存。

这个动态的功能在后来我们做模板编译的时候，成为一个性能瓶颈点，但我们巧妙的解决了。

1.0时代的总结

如果你用过ETpl，你会发现它很多东西是最初就有的，一直到现在都没怎么变。这代表最初的设计有很多是现在还适用的，令人高兴。但是有的东西已经发生了变化（比如母版），我们后面会反思这点。

我们就这样走过了两年多。在这两年里，周围的很多商业系统都采用了SPA的模式，也一直是使用这个ER里自带的模板引擎生成HTML，然后通过UI组件二次进行富交互的行为管理。在这两年里，前端模板开始像雨后春笋一样冒出来，但是我们一直没有跟进，一直在停留。直到……

2.0时，我们做了这些事情

在2012年的时候，我们的很多SPA应用面临同样的问题：由于业务量的爆炸，一次性把所有JS都压缩到一个文件的构建方案已经不能满足需求。各个产品线都各自设计了按需加载的方案，有还算靠谱的或者不靠谱的。在这样的背景下，我们决定开始强制使用AMD。这不单能从根本上解决这个问题，还能获得一些模块组织、依赖管理、包管理方面的好处。这是一个艰难的决定，这意味着我们原有的很多libraries和frameworks都需要AMD化，包括ER框架。当时ER框架里不单自带了模板引擎，还自带了ESUI控件库。我们决定按照规范把他们分离出来，作为独立的package提供。这也符合前端发展的趋势。

既然要独立提供，就来一次进化吧。这一次，ETpl的升级吸收了很多意见，增加了很多实用的功能，体积也控制住了：

模板编译

JavaScript模板引擎所谓的模板编译，指的不是编译成机器码，而是解析模板语法，转换成JavaScript代码，再经过new Function，变成可以在当前环境下执行的function。至于这个过程中有什么编译，render过程有什么JIT，由当前运行的JS引擎决定，不是这里关心的内容了。

在2012年，模板编译已经快成为标配了，几乎所有流行的模板引擎都是编译的。显然模板编译能让性能更高，特别是使用一个模板多次render的场景。我们以前没这么做，是因为在现有应用中没有遇到性能瓶颈，而有其他很多事情让我们无暇顾及他。但是当我们决定要去做一个大升级的时候，这无论如何都是不应该缺席的。

1
2
3
4
5
6
// 没有模板编译
var result = etpl.render(source, data);

// 有模板编译
var render = etpl.compile(source);
var result = render(data);

由于ETpl的灵活性（功能强大的filter、data getter功能等），这些东西都会使性能变差。我们期望坚持我们的特点，在此之上做到相对较高的性能。所以，我们采用了一些方法优化我们的编译产物。下面列举一些我还记得的：

一个是根据不同平台生成不同的代码。这个优化主要是因为鸡国用户的老操作系统老浏览器比例还很大。据我所知artTemplate是最早采用这种优化方法的。

1
2
3
4
5
6
7
8
9
10
11
12
13
var RENDER_STRING_DECLATION = 'var r="";';
var RENDER_STRING_ADD_START = 'r+=';
var RENDER_STRING_ADD_END = ';';
var RENDER_STRING_RETURN = 'return r;';

if ( typeof navigator != 'undefined' 
    && /msie\s*([0-9]+)/i.test( navigator.userAgent )
    && RegExp.$1 - 0 < 8
) {
    RENDER_STRING_DECLATION = 'var r=[],ri=0;';
    RENDER_STRING_ADD_START = 'r[ri++]=';
    RENDER_STRING_RETURN = 'return r.join("");';
}

还有数据访问。由于下面的理由，我们不能把${team.name}直接编译成data.team.name，我们只能编译成getVariable('team.name'):

  1. data支持getter方法
  2. null和undefined的处理
  3. 防止中间变量（for、var）更改数据

但是在render运行时切分team.name是非常耗时的事情，所以后来我们编译成了getVariable('team.name', ['team', 'name'])，将这部分的工作放到了编译时。

然后，然后我就不记得了，总之还做过一些。好吧，忘了就忘了，重要的是，我们在支持这么多动态特性下，与性能著称的模板引擎们相比运行时间相比几乎是差不多的（感兴趣的可以自己运行性能测试用例，IE6下请自觉减少运行的数量级）。我们曾经在一个性能要求非常严苛的NodeJS项目中应用，原先用的mustache性能满足不了需求，后来换了etpl，性能测试就通过了。由于项目涉及保密，就不说了。

性能与功能的取舍总是需要平衡的，我们找到了自己的点：强复用、灵活、高性能的JavaScript模板引擎。

p.s. 我记得前段时间，某模板引擎跳出来说自己性能最高，还给出了测试用例。10同学跑了一下，发现ETpl和mustache差不多。我们觉得不应该啊，再一看测试用例，是1000次编译*10000次运行。妈蛋测试不能这样做啊，1000次编译你还要编译干嘛？而且就算要做，也是两个测试用例，编译性能是一个测试用例，运行性能是一个测试用例啊。真能混淆视听。

移动可用

由于模板编译已经把性能考虑掉了，这里主要考虑的是体积的大小。移动方向负责人Firede给的指标是，ETpl语法压缩+GZip后不能超过4k。

关键是ETpl的特点是复用能力和灵活性啊，有这么多功能就有这么多代码，我们总不能砍功能最后变成再做一个doT或者artTemplate出来吧那就没必要再写了啊，妈蛋只能进行体积优化了啊。我知道的另外一个复用功能比较强大的模板引擎nunjucks语法压缩+GZip后是19k。

我专门抽了将近一周时间一点一点砍体积。说实话这是个体力活，是个精细化的活。优化过程中还经常会出现觉得这么做体积能减小一点，做了以后发现和预想的不一样，增加了几个字节，只好撤销，重新读代码去寻找优化点。优化进行了4天后（达到小于4k后，已经和自己较劲上了，根本就停不下来啊），体积是3.7k，感觉已经接近x尽人亡了。好多点都已经不记得了，就说两个记得的比较大的点吧。

把相似的代码尽量放到一起。下面的代码可以看出来，Command.prototype.open = function (context) {相同片段的代码都放的比较近，更利于GZip。同样的，很多Constructor中代码比较接近，所以作为Constructor的function都放到了一起声明。可读性党在这里会不会跳出来？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
UseCommand.prototype.open = function (context) {
    context.stack.top().addChild(this);
};

BlockCommand.prototype.open = function (context) {
    Command.prototype.open.call(this, context);
    (context.imp || context.target).blocks[this.name] = this;
};

ElifCommand.prototype.open = function (context) {
    var elseCommand = new ElseCommand();
    elseCommand.open(context);

    var ifCommand = autoCloseCommand(context, IfCommand);
    ifCommand.addChild(this);
    context.stack.push(this);
};

再看看下面inherits的实现，简化了不少。注释已经写的很清楚了。可维护性党在这里会不会跳出来？

1
2
3
4
5
6
7
8
function inherits(subClass, superClass) {
    var F = new Function();
    F.prototype = superClass.prototype;
    subClass.prototype = new F();
    subClass.prototype.constructor = subClass;
    // 由于引擎内部的使用场景都是inherits后，逐个编写子类的prototype方法
    // 所以，不考虑将原有子类prototype缓存再逐个拷贝回去
}

支持不写target

不是所有模板片段都需要被复用，他们可以作为单独的模板片段，编译一次，多次使用。这在很多小的字符串片段的生成中还是比较常见的。所以有的模板就不需要被命名。

1
2
3
4
var helloRender = etpl.compile('Hello ${name}');
helloRender({
    name: 'ETpl'
});

这里支持的技术方法很简单：

  1. 原来每个target都是具名的，这点内部实现还是不变。当遇到模板源码的起始不是target的时候，就自动创建一个target，并自动生成一个不重复的名字。
  2. compile方法返回第一个target的编译结果。

通过配置项定义语法风格

最初我们的初衷是期望在写模板的时候，不要丢失Editor对HTML的一些语法高亮、自动补全等功能的支持，所以模板语法是写在HTML注释里的。后来我们发现不少人不喜欢这种风格：

  1. 习惯了其他的风格，比如<%和%>
  2. HTML注释要输入的开始和结束很长啊，分别是4个字符和3个字符

所以我们决定支持一些配置项，让用户可以自己定制语法风格。最开始支持的是commandOpen和commandClose。再后来，我们又发现由于mustache的流行，很多人习惯 的变量替换风格。所以我们又支持了variableOpen和variableClose。

于是，如果你有如下的配置：

1
2
3
4
5
6
etpl.config({
    commandOpen: '<%',
    commandClose: '%>',
    variableOpen: '\{\{',
    variableClose: '\}\}'
})

你的模板可能会是这样：

1
2
3
4
5
6
<% target: header %>
<header>...</header>

<% target: biz1 %>
<% import: header %>
<div class="content">Hello {{name}}!</div>

多引擎实例

随着业务规模的爆炸，一个应用开发人数增多，以及开发过程管理不够科学，有的团队遇到了模板片段命名上出现冲突的问题。简单的一个例子，两个功能都有列表页，大家都为模板片段起名叫list，就会冲突。

对业务功能进行统一管理，并制定合理的规范，在执行上有效监督，是能避免这个问题的。但是不一定每个团队都能做到这一点，而且既然发现问题，在技术手段上能解决，我们就解决。

解决的方法很简单，就是etpl支持多引擎实例，不同引擎实例之间完全隔离，就可以拥有相同名称不同内容的模板，甚至不同引擎可以各自定义自己的模板语法格式。

1
2
3
4
5
6
7
8
var engine = new etpl.Engine({
    commandOpen: '<%',
    commandClose: '%>',
    variableOpen: '\{\{',
    variableClose: '\}\}'
})
var render = engine.compile('Hello {{name}}!');
render({name: 'myName'});

etpl这个变量本身是默认一开始就初始化好的一个引擎实例。

在模板里定义数据

我们对提供模板中声明数据的能力一直持谨慎的态度，但后来我们决定支持它。

  1. 有的东西在写模板时也可以被抽取成为数据，在内容串中多次用到
  2. 一些特性、行为选择可以抽取作为数据配置项
1
2
3
4
5
6
<!-- var: name = 'etpl' -->

Hello ${name}!
<!-- if: score > 90 -->
${name} is clever!
<!-- /if -->

动态调用

原先我们通过import可以实现复用，其效果相当于把目标模板片段的源码嵌入相应位置。但是请看下面的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<!-- target: grade -->
<h3>class1</h3>
<!-- var: members = class1.members -->
<!-- import: members -->

<h3>class2</h3>
<!-- var: members = class2.members -->
<!-- import: members -->

<!-- target: members -->
<ul>
    <!-- for: ${members} as ${member} -->
    <li>${member.name}</li>
    <!-- /for -->
</ul>

members模板片段提供了把一群人打印出来的能力，但是这群人的数据名称被固定了，必须是members。在我们只能使用import时，一般同学会写两遍，很聪明的同学会想到上面这样的方法来复用，真是难为了。

所以，我们在2.0通过use支持了动态调用的特性，其效果相当于JavaScript中的函数调用。调用传入数据的方式是名称对应，不是顺序对应，因为模板片段声明时只会声明名称，不会声明其用到的数据。模板引擎能这么玩还是不多见的，所以说复用和灵活是ETpl最大特点。

1
2
3
4
5
6
7
8
9
10
11
12
13
<!-- target: grade -->
<h3>class1</h3>
<!-- use: members(members=class1.members) -->

<h3>class2</h3>
<!-- use: members(members=class2.members) -->

<!-- target: members -->
<ul>
    <!-- for: ${members} as ${member} -->
    <li>${member.name}</li>
    <!-- /for -->
</ul>

filter支持参数

在1.0时代，filter是一个非常简单的功能。在2.0中，我们对它专门进行了设计，增加了很多特性。

对参数的支持

我们希望filter在运行时能够根据一些参数，进行不同行为的处理。比如下面的应用场景，支持参数是非常有用的：

1
${birthday | dateFormat('yyyy-MM-dd')}

在addFilter时，我们有两种方案可以选择：

1
2
3
4
5
6
7
8
9
10
11
// 1，参数紧跟在filter函数的source参数后
etpl.addFilter('dateFormat', function (source, format) {
    // ......
});

// 2，闭包根据
etpl.addFilter('dateFormat', function (source) {
    return function (format) {
        // ......
    };
});

方案2的优势是，如果后续filter还有什么扩展，能够更方便。最后，由于性能和filter开发的易理解上的考虑，我们最终选择了方案1。

对管道的支持

1
${content | cut(200) | highlight(${keyword})}

我们发现，在一些场景下，一个完成独立功能的filter不足以完成一些需求，这个时候，我们可能需要add一个新的filter，其功能是另外两个filter的组合。这事情是多此一举的。我们从shell的管道得到启发，我们让filter功能也支持了管道。

换一个简单的例子：${team.name | slice(1, 3) | html}，下面是其模板编译的结果说明：

1
2
3
4
5
6
7
8
9
10
11
12
filters.html(
    filters.slice(
        toString(
            getVariable(
                ‘team.name’,
                [‘team’,’name’]
            )
        ),
        1,
        3
    )
)

从上面的模板编译结果说明，我们发现在getVariable和filters.slice之间，有一个toString，为什么呢？

参数类型的考虑

在仔细设计filter功能的时候，我们对参数类型的问题，进行了一次深入的讨论。包括后来，很多使用者也问过我们为什么是这样。我们通过下面的应用场景对这个问题进行说明：

1
2
3
4
5
{
    name: 'erik'
    birthday: new Date(2007, 6, 11),
    sex: 1
}
1
${name | html} was born in ${birthday | dateFormat('yyyy-MM-dd')}.

filter应该接受数据的原始类型，还是字符串呢？

接受原始类型，dateFormat会比较容易处理。但是存在如下问题：

  1. 管道的输入和输出应该保持一致性，否则容易导致混乱
  2. 每个filter开发都需要做类型判断和转换。比如cut filter的功能是字符串截断，它需要内部将输入转换成字符串，因为输入可能是数字，不转换就会报错。

我们认为：

  1. 默认情况下，在变量替换中，将默认一开始就把数据转换成字符串。filter的返回也应该是字符串。从而保证filter管道的数据类型一致性。
  2. 我们也应该提供一种途径，方便一些特殊的filter进行处理，使其内部不需要进行字符串到所需数据类型的反序列化。我们选择的方式是${*variable | filter}：当variable使用*前缀时，ETpl默认不将variable转换成字符串，直接将原始数据传递给filter进行处理。这时filter中的处理过程是干净的，模板编写者需要知道filter是怎么干的，从而决定是否给filter原始数据。

所以，上面的模板例子，正确形式应该是这样：

1
${name | html} was born in ${*birthday | dateFormat('yyyy-MM-dd')}.

约定输入必须是字符串，我们也才能顺利实现后面的 处理模板内容块 功能。

处理模板内容块

filter的功能能够对目标内容进行一些处理，但是变量替换中的filter只能处理数据中的内容，我们可能需要对一些模板里的内容，使用filter进行处理。我们通过一个叫做filter的命令，实现了这样的功能。下面的代码是我们对于需求的最初设想：

1
2
3
4
5
<!-- filter: markdown -->
## markdown document

This is the content, also I can use `${variables}`
<!-- /filter -->

我们很兴奋的支持了这个功能，但是迄今为止还没在应用中用到。

母版的母版

在1.0时代，我们支持了母版功能，但是只有target可以指定master。遇到下面这样的场景，就得写多个母版，每个母版里还有很多重复的内容。

所以在2.0里，我们支持了这样的功能，母版也能指定母版：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<!-- master: up-down -->
<header>
    <!-- contentplaceholder: header -->header<!-- /contentplaceholder -->
</header>
<div>
    <!-- contentplaceholder: body -->body<!-- /contentplaceholder -->
</div>

<!-- master: up-left-right(master = up-down) -->
<!-- content: header -->my header<!-- /content -->
<!-- content: body -->
    <aside><!-- contentplaceholder: body-side --></aside>
    <main><!-- contentplaceholder: body-main -->child body<!-- /contentplaceholder --></main>
<!-- /content -->

<!-- target: biz(master = up-left-right) -->
<!-- content: body-side -->biz aside<!-- /content -->
<!-- content: body-main -->biz main<!-- /content -->

2.0时代的总结

由于ETpl独立化的契机，我们精心设计了2.0，加入了很多我们认为应该支持的功能。在这个过程中我们依然是谨慎的，我们没有忘记“复用、灵活”的初衷，并且努力实现“高性能，小体积”。从1.0到2.0，我们完成了 还算好用 到 敢见人 的转变。

3.0时，我们做了这些事情

在2.0中，我们已经做了一些比较完善的工作。但是在设计2.0的时候，我们期望尽量能够平滑的升级。我们增加特性，也要保证在现有系统中存在的模板能够正常的运行。但是不可否认，从1.0沿袭下来的2.0在母版功能的语法上存在不好用的地方，可以改进。

  1. master和target为什么非要区分？master也是模板片段，直接用来渲染按道理应该是可以的。
  2. contentplaceholder是什么东西？谁能记住这个不止一个单词的货色妈蛋？

我们一直有所感觉，但没有着手去做这个事情。因为我们知道这是一个breaking change，在一个已经被广泛应用的东西上做breaking change是需要谨慎、需要足够充足的理由的，但我们一直没找到，直到……

引用代入

直到灰大提出了issue31!

这是个令人振奋的功能，迄今为止我没有见过市面上哪个模板引擎提供了这样的功能。我把它叫做引用代入，意思是：在我import一个模板片段的时候，我能够对它中间的部分内容进行复写。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<!-- target: header -->
<header><!-- block: header -->default header<!-- /block --></header>

<!-- target: main -->
<div><!-- block: main -->default list<!-- /block --></div>

<!-- target: footer -->
<footer><!-- block: footer -->default footer<!-- /block --></footer>

<!-- target: biz -->
<!-- import: header -->
<!-- import: main -->
    <!-- block: main -->specical list<!-- /block -->
<!-- /import -->

这能够有效避免在大应用中的母版爆炸问题，有效减少代码量！具体他是什么，能做什么，上面的issue里写得很清楚了，感兴趣的人去看看吧，相信大家会有收获。

这个feature给了我们给ETpl升级一位版本号的理由，因为它太令人振奋了。当然迄今为止用到这个feature的人并不多，因为大家还没明白它的好处，但我强烈建议大家去看看上面的issue！！！这里也有一个引用代入的例子。

对母版功能的语法重设计

我承认标题吹牛逼了，我们其实没有重设计。流行的模板引擎早已经有成熟的语法了，我们就是改成那样而已。这事情的意义是：梗终于被拔掉了。

方案是：我们砍掉了master、content、contentplaceholder，引入了block。

回顾上面多重母版的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<!-- master: up-down -->
<header>
    <!-- contentplaceholder: header -->header<!-- /contentplaceholder -->
</header>
<div>
    <!-- contentplaceholder: body -->body<!-- /contentplaceholder -->
</div>

<!-- master: up-left-right(master = up-down) -->
<!-- content: header -->my header<!-- /content -->
<!-- content: body -->
    <aside><!-- contentplaceholder: body-side --></aside>
    <main><!-- contentplaceholder: body-main -->child body<!-- /contentplaceholder --></main>
<!-- /content -->

<!-- target: biz(master = up-left-right) -->
<!-- content: body-side -->biz aside<!-- /content -->
<!-- content: body-main -->biz main<!-- /content -->

在3.0时代就变成了这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<!-- target: up-down -->
<header><!-- block: header -->header<!-- /block --></header>
<div><!-- block: body -->body<!-- /block --></div>

<!-- target: up-left-right(master = up-down) -->
<!-- block: header -->my header<!-- /block -->
<!-- block: body -->
    <aside><!-- block: body-side --></aside>
    <main><!-- block: body-main -->child body<!-- /block --></main>
<!-- /block -->

<!-- target: biz(master = up-left-right) -->
<!-- block: body-side -->biz aside<!-- /block -->
<!-- block: body-main -->biz main<!-- /block -->

爽很多，有木有？但是毕竟是breaking change，很多ETpl2语法编写的模板迁移成本会很高。所以我们还提供了etpl2to3的工具帮助老的产品线自动转换，基本迁移就可以无缝了。

支持完全自定义模板语法

我们之前通过 commandOpen / commandClose / variableOpen / variableClose 配置项支持用户对部分语法部分进行定制，但是var: a = 1中间的冒号算怎么回事，怎么觉得这么别扭呢？

所以，我们增加了一个参数：commandSyntax，让用户能够对命令的语法规则进行定制。看看这个例子，经过定制后，ETpl语法和nunjucks是一样的。

1
2
3
4
5
6
7
8
9
10
<% target myTpl %>
<% import header %>
<div class="main">Hello {{name}}!</div>
<% import footer %>

<% target header %>
<header>Header Content</header>

<% target footer %>
<footer>Footer Content</footer>

commandSyntax类型是一个正则，默认值是^\s*(\/)?([a-z]+)\s*(?::([\s\S]*))?$，第一个match是结束标记，第二个match是command name，第三个match是command value。使用符合规则的正则就能很方便的定制ETpl的语法咯。

在2.0的时候我们也隐约感觉应该开放这样的定制点，但时间总是有限的，我们还在做其他的事情。当我们决定升级3.0的时候，我们就会把之前觉得不太紧急的升级点，仔细考虑，一并做掉。所以自定义模板语法的支持，在3.0才算是真正完全实现。

最后

跌跌撞撞的，ETpl存在到现在也有4年多了。中间的升级一直断断续续，我们走的不快，但是还算稳。在这个过程中，对于lib类型的产品，我们有一些感想：

  1. 很多基因在最开始的时候就已经被决定了。我们一开始最关注提供中大型应用中的模板复用性和灵活性，到最后这也是我们最厉害的地方。
  2. 定位很重要，定位一定是一个取舍。讲性能我们比不过artTemplate，讲体积我们比不过doT，我们有我们的特点和生存空间。
  3. 结合应用实际很重要。我们的功能点有很多是来源于应用后的反馈。绝对不能只高屋建瓴的空想。
  4. 用户量越多，包袱越大。就像我们没法随意更改其语法。所以每个设计点都应该谨慎决策。
  5. 用户通常只能看到你的第一价值观。就像我们提供了语法定制的功能，但是绝大多数用户是不会用的，他们会根据是否喜欢你提供的默认语法形式，决定用不用你。

我们仍有没做的功能，比如预编译。原因如下：

  1. 预编译后的代码大多数时候比模板本身要大，可见预编译对浏览器端应用是没有价值的。
  2. 对于NodeJS应用，服务启动时编译一次的成本并不高。
  3. filter功能对于预编译是一个障碍，我们无法平滑的完成预编译的过程，filter可能是一个位于复杂环境的function。

所以，我们还未决定是否进行预编译的支持。当然，主要是因为我们现在还没有时间仔细的审视这个问题并给出方案。在未来的某个时候，我们将会考虑。

如果你觉得本篇blog有点收获，求个star支持下呗，反正不花钱

知识共享许可协议