分类
js

记一个踩过三次的坑……

图文无关。太长时间没写文被降权了么,怎么最近流量跌这么厉害……

老后台的架构仍然是PHP渲染页面,这里我选择mustache.php作为模板引擎。在某些场景下(比如搜索),我希望在前端使用复用同样的模板。正如前面一篇文章所说,我选择的是Handlebars.js,它号称支持mustache语法。

然则在使用当中,我发现二者的实现仍然是有区别的。先上模板。

    {{#value}}{{value}}{{/value}}

这段模板很简单,检查value是否存在,如果是的话则将其输出。这时:

  • mustache.php先以value作为逻辑判断依据;接下来,在value里找不到value这个key,便回到上一层,输出value的值
  • 而在handlebars.js眼中,{{value}}的类型也是很重要的,如果是String或者Number,那就直接输出;如果是Object,它就会采用{{#with ..}}{{/with}}操作,从value里面取值,而value里没有value,所以输出空。

当模板为

    {{#has_value}}{{value}}{{/has_value}}

此时,因为has_value是布尔值,所以Handlebars.js放弃把这个对象当做执行环境,而是继续维持当前的层级,所以就能正确输出value的值。


这个问题虽然不很复杂,但是调试起来并不方便,而且文档中也没提过,所以三次踩坑每次都耽误不少时间。记录如此,避免再次遭遇。

分类
js

助力Handlebars

单页应用中,模板引擎是必备工具。这方面的选择比较丰富,旧轮子不断获得改进,新的轮子也不断被发明出来。我比较喜欢Handlebars,原因如下:

  1. 模板语言简单。继承自mustache,用{{content}}标记出要替换的内容即可。
  2. 包含逻辑判断和循环。在mustache基础上加强了这个部分,使得代码更易读。
  3. 不支持复杂的逻辑,尤其是嵌套JS。我认为这是模板引擎的关键,任何复杂的逻辑放在表现层都会使得系统不稳定。
  4. 支持预编译。可以加快实际运行的速度。
  5. 提供扩展功能,可以方便地增加自定义功能。这也是本文重点。

简单,是Handlebars的优势;但是原始版有点过分过头,它既缺少Angular模板中的过滤器,难以格式化输出数据;也没有足够的逻辑判断。使得我们必须在使用模板前进行大量预运算,逻辑据处理成模板能辨识的标记,把数据格式化成用户能识别的内容,这与代码复用的原则相违背。所幸Handlebars提供好用的扩展接口,给我们增添功能,适配业务逻辑的机会。