理想模式看下服务端模板是如何做的: 1. 模板按文件与目录组织模板
2. 模板使用 include 语句完成复用
这一切看起来很美,前端是否也可以采用这样的模式?但是现实告诉我们,这是一个艰巨的任务。 现实难题
解决方案 为了实现上述“理想模式”,我们推出了 TmodJS——模板预编译器。 TmodJS 采用三种方案来解决难题: 1. 本地构建 模板编写完成后,通过一个本地工具将模板编译成浏览器可执行的代码——JS,这样就可以用脚本的方式来加载模板,不必受浏览器的同源策略限制,模板可以部署到任意 CDN,而无需处理跨域问题。 工具内部采用模板引擎—— artTemplate完成模板编译,输出 JS 文件。artTemplate 也是来自腾讯的开源项目,它支持预编译,编译后的代码可以无需引擎运行。 2.种子文件 为了实现
3. 模板目录 为了让团队成员、自动化工具能更好的管理模板,前端模板不再内嵌到页面中,而是使用专门的目录进行组织维护;使用路径作为模板的 ID,这样与源文件保持对应关系——这样好处就是极大的增加了可维护性。例如:页面头部底部的公用模板可以放在 模板与工程化TmodJS 采用了自动编译机制,一经启动后就无需人工干预,每次模板创建与更新都会自动编译,直到正式上线都无需对代码进行任何修改。实现文件系统的前端模板只是 TmodJS 最基本的任务,它在背后还做了这些优化: 1. 模板压缩与合并 TmodJS 编译之前会压缩掉模板的空白字符,编译为 JS 后又会进行一次压缩,此时输出的 JS 甚至会比原始模板更小(最高可减少一半的体积)。 在默认设置下,TmodJS 会将模板目录所有模板编译后再进行压缩与合并,输出后的 template.js 称之为模板包(内部名称叫 TemplateJS 格式)这种打包的方式非常适合移动端单页 WebApp,输出后的模板包可直接可作为开发阶段与线上运行的文件,适合中小型项目。 2. 依赖管理 当然,将所有前端模板都打包在一个文件中不一定适合每一个项目,因为很多大型项目需要更细致的优化,将模板编译为 AMD、CMD、CommonJS 类型的的模块是一个不错的选择,此时模板内部的 3. 本地调试 因为模板已经被独立出来,所以使用 fiddler 将线上模板映射到本地进行开发调试将十分容易。如果线上模板报错,开启 TmodJS 的
4. 沙箱与扩展 很多开发者习惯在模板中访问页面中全局定义的函数,如果模板内嵌到页面中问题似乎不大,一旦模板外置后这种隐含的依赖关系将会导致严重的维护问题,TmodJS 采用沙箱机制来解决此问题:限制开发者访问外部对象,模板用到的所有变量在闭包中被强制指向模板数据。 为了方便扩展模板的功能,可指定一个外部 JS 作为公用方法(辅助方法),这个 JS 会被合并到到 template.js 中。 5. 安全过滤 模板的变量输出默认都会被过滤函数包裹,在运行时进行过滤,从而避免模板开发者因为疏忽导致站点 XSS 漏洞。例如: 模板
编译代码
6. 与第三方自动化构建工具配合 目前 TmodJS 已有 Grunt 与 Gulp 这两种流行的自动化构建工具的插件,未来将支持更多的自动化工具。 7. 前后端模板共享 TmodJS 与 artTemplate 模板引擎使用同样的模板语法,而 artTemplate 提供了 NodeJS 版本,可以直接读取 TmodJS 的模板目录,这意味着可以轻松的做到前后端模板共享,技术方案自由切换。 经过上面的一些优化,我们达到了下面成果:
|