模板,从服务端到客户端

编注:这是 2012 年的一篇旧文。

在浏览器中使用模板是一个日渐热门的趋势。将服务端的逻辑应用到客户端上,还有越来越多的类MVC模式(模型-视图-控制器:model-view-controller)的使用都使得在浏览器中“模板”的角色越来越重要。在过去,“模板”从来都是服务端的事情,但事实上在客户端开发中,模板的作用是非常强大又具有表现力的。

为什么要使用模板?

大体上来说,借助模板是一种能很好地将视图(views)中标记和逻辑分开的方法,还能将代码的重用性和可维护性最大化。如果使用的是语法与最终所得结果很相近的语言(比如HTML),你就能又快又好地把任务完成了。虽然模板可以用来输出任何形式的文本,但由于我们想要讨论的客户端开发是有关于HTML的,所以在这篇文章里,我们还是以HTML作为例子。

现在的动态应用中,客户端常常需要频繁地刷新界面。这个效果可以通过服务端将HTML片段插入到客户端的文档中。这样做的话,服务器要能支持传送HTML的片段(与之相对:传送完整的页面)。还有就是,作为一个要处理这些标记片段的客户端的开发者,你应该会想能完全控制你的模板。而模板引擎(Smarty)、流量(Velocity)还有ASP这些服务器端的内容你都不用了解,也不用管那些“面条式代码”(spaghetti code):例如在HTML文档里是不是出现的臭名昭著的<?或者<%。

那么现在来看看客户端模板吧。

第一印象

对初学者而言,理解“模板”的含义很重要,foldoc(免费在线计算机词典)中的解释是:模板是一种文档,不过文档中有形参,再通过模板处理系统的特定语法用实参代替形参。

让我们来看看最基本的模板长什么样子:

如果你写过HTML,那么你一定很熟悉上面的代码。上文的HTML中有一些占位符。这些占位符将会被真实的数据取代。例如这个对象:

把数据和模板结合起来,就会得到下面的HTML代码:

将模板和数据分离开来对于维护HTML来说是一件好事。比如说,如果想要更改标签或者添加类(class)就只需要更改模板就可以了。另外,对于需要迭代出现的元素(比如<li>),程序员只需要写一次就好了。

模板引擎

模板的语法是根据你需要的模板引擎来决定的(例如:占位符{{title}})。引擎是负责分析模板,用提供的数据替换占位符(变量、函数、循环等等)。

有些模板引擎看起来没有什么逻辑性。这指的不是在模板中只能插入简单的占位符,而是说智能标签(intelligent tags)方面的特性很少(比如数组迭代器,条件渲染等等)。有些引擎就有很多特性和很好的可扩展性。关于这一点就不在这展开讲了,你需要问问自己,在模板中你是否需要、需要多少逻辑。

每个模板引擎都有自己的API,不过通常你都能找到像render()和compile()这样的方法。渲染的过程就是将真正的数据放入模板然后呈现出来。也就是说,渲染就是用真正的数据替代了占位符。如果在此期间木板上有什么逻辑,就会被执行。编译模板指的是解析模板,然后将它转换成一个JavaScript函数。模板中的逻辑都会被解释为纯JS(plain JavaScript),给定的数据会被传入这些JS函数中,这么做可以最大程度地优化HTML。

Mustache实例

上文中的例子可以借助模板引擎实现,例如使用了Mustache模板语法的mustache.js。关于这种语法更多信息,我会在后面告诉你的。现在先来看看下面的JS代码能得到什么效果:

现在我们需要在页面上显示模板,你需要写这么一行代码:

第一个客户端模板就完成了!在代码文件中加入下面这句,你就可以试一试上面的例子了,或者看下在线演示

组织模板

如果你和我一样,不喜欢HTML文档里出现很长的内容,既造成了阅读的困难还增加了维护的负担。理想情况下,我们可以把模板分开维护,既能享受模板的语法高亮的便利,又能保证HTML的可读性。

但事情总不会十全十美的。如果一个项目中要使用非常多的模板,出于避免过多Ajax请求而影响性能的原因,我们不希望这么多文件被分开加载下来。

场景1:脚本标签

常见的解决方案就是把所有的模板直接放在<scrpit>标签中,<script>标签的可选类型要稍作更改,比如改成type=”type/template”(浏览器在渲染或解析时会将这个属性忽略)。

这样的做,你就可以把所有的模板都放在HTML文档中,避免了额外的Ajax请求。

script标签中的内容会后面被JavaScript当做模板来使用。请看下面的代码,这次我们用的是Handlebars模板引擎再结合一些jQuery,模板就用刚刚的里的。也可以直接看在线演示

最终效果和上文的Mustache例子是一样的。Handlebars也可以使用Mustache格式的模板,所以在这里我们就用一样的模板了。不过要注意,它们之间还是有一个很重要的区别:Handlebars是先得到一个中间结果,再通过这个中间值得到HTML的。它先是将模板编译成一个JS函数(称之为compiledTemplate),然后数据再被传入这个函数中执行,再返回最终结果。

场景2:预编译模板

虽然说将渲染模板包装在一个方法里看起来要方便多了,但是将编译和渲染分开也有显而易见的优点。最重要的是,分开以后,可以把编译放在服务器端完成。我们可以在服务器上执行JS代码(比如使用Node),有些模板引擎支持这样的预编译。

我们可以用一个JS文档(叫它comiled.js吧)将多个预编译好的文件放在一起。这个文件的内容看起来可能是这样的:

然后在应用中,我们只需要将数据传入这些预编译好的模板中:

这个方法远比上文中讨论过的将所有的模板放在<script type=”text/javascript”>中要好,客户端会忽略编译过程。取决于你的应用套件(application stack),这个解决方式并不一定很难实现,我们会在下文看到它具体的实现。

Node.js示例

任何模板预编译脚本至少要满足下面的要求:

  1. 读取模板文件,
  2. 编译模板,
  3. 最后的结果可以被合并入一个或多个文件、

下文中的Node.js脚本就实现了上面说的那3点(使用Hogan.js模板引擎):

这段代码先是读取了在templates目录下所有的文件,再编译了这些模板,最后将它们写入compiled.js。

注意!现在得到的结果是完全没有优化过的代码,也没有做任何错误处理。不过它还是完成我们想要它做的事,也不需要很长的代码来预编译模板。

场景3:AMD和RequireJS

随着异步牵引模块(通常我们都称之为AMD)越来越多地被使用,为了更好地组织你的APP,建议将模块解耦。RequireJS是现在主流的模块加载器之一,在模块定义中,你可以特定某些依赖,在实际的模块里你就可以使用它们了(工厂模式)。

在使用模块时,RequireJS有一个text插件用于规定基于文本的依赖。默认是将AMD的依赖当做JavaScript来处理,不过模板并不是JS而是文本(比如HTML格式的模板),所以我们需要用上这个插件:

这样,就能在单独的文件中管理各个模板了,虽然这么做是挺好的,但无疑增加了很多额外的Ajax请求,而且仍然需要在客户端编译模板。但是,可以用RequireJS中的r.js来优化这些额外的请求。这个决定了依赖,将模板或者依赖植入模块定义中,大大减小了请求数。

你会发现我们还没有说到预处理,事实上有两个方法可以完成预处理。可以写一个r.js的插件或者别的程序来预处理模板。这么做的话就会改动了模块定义:我们需要在优化之前先使用一个模板*字符串*,然后再使用一个模板*方法*。不过这些问题也不是很难处理,你可以去检测它的变量类型或者将逻辑抽象出来(写在插件中或者直接写在应用中)。

监听模板

在场景2和场景3中,如果将模板当做未编译的资源我们还能将应用构建地更好。就像你在写CoffeeScript、Less或者SCSS,在开发时,可以监听模板文件的变化,一旦发现文件出现变化,就立刻自动重新编译,就像从CoffeeScript编译到JavaScript一样。这样我们在代码中处理的模板都是已经预编译过了的,还方便了在开发过程汇中将预编译模板做相关的内联优化。

 

性能问题

用客户端模板完成UI更新时的渲染是常见的方法。还是那句话,想要达到性能最优,那就要在第一次请求页面时尽可能少的请求额外的资源。这样浏览器在渲染HTML页面时不会因为要去加载JS资源或者别的数据而中断渲染。这听起来挺难的,特别是在又要动态加载内容又要尽可能减少加载时间的页面上。理想情况下,模板是既可以在客户端也可以在服务端使用的,这样可以提供最优的性能还能保持它的可维护性。

有两个问题还需要考虑一下:

  1. 我的应用中哪里是有最多动态加载的呢?又是哪部分需要最短的加载时间的呢?
  2. 处理种种问题的程序是要放在客户端还是服务端呢?

实际问题实际分析。确实使用预处理过的模板,客户端可以比较轻易地快速渲染出效果。但是如果你需要重用模板,你会偏爱逻辑较少的模板一些。

结论

我们已经看到了客户端模板的种种好处,比如:

  • 服务器和API最好只负责提供数据(比如JSON);客户端模板就能直接把数据套上了。
  • 客户端方向的开发者可以自如地使用HTML和JS。
  • 使用模板的话,你就必须把逻辑和表现分离开。
  • 模板可以预编译好然后缓存起来,这样服务器每次都只要发送数据就可以了。/li>
  • 不在服务器端渲染而在客户端渲染,多少会影响性能。

上述的文字已经介绍了很多关于(客户端)模板的知识,希望现在你对这些内容有了更深的认识。

收藏 评论

关于作者:kmokidd

简介还没来得及写 :) 个人主页 · 我的文章 · 14

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部