Compass + cleancss 导致的灵异小问题

:blank伪类尚未被Chrome支持,会导致整条规则被忽略。

问题不大,不过很诡异。代码如下:

SASS:

.some-class
  display: none

.other-class:blank
  display: none

HTML:

<div class="some-class">...</div>

理论上说,这样这个div应该不显示。在本项目中,它的确没显示;但是在另外一个将本项目作为依赖的项目中,它却显示出来了。

经检查,本地开发和部署时,直接使用 compass compile 生成CSS,compass 配置中,设置输出模式(output_style)为 compressed,结果是这样的:

.some-class{display:none}.other-class:blank{display:none}

而在作为依赖时,用到的则是 grunt-contrib-cssmin 处理过的CSS,刚才那句就被压缩成

.some-class,.other-class:blank{display:none}

:blank伪类尚未被Chrome中支持,于是整条规则都被忽略,导致div显示出来。

啊,前端的轮子啊

学习新技术还是不要太激进,保持基础的了解即可。但是不关注也是不行的。

时势造英雄。

IT科技几十年来诞生过不少概念,但直接拿来就能作为宣传材料的不多,HTML5算一个。借助智能手机、微信微博快速普及带来的平台优势,HTML5快速成长,接连攻陷投资界、创业界、广告界,现在说起H5,在我的圈子里几乎无人不知无人不晓。

资金充裕,整个行业自然地位上升,财务上升;继而自然从业者增加;继而就会出产大量的产品。而作为前端从业人员,最大的感觉就是:轮子真TM多啊……这不,我前几天计划学习一下近来出现的各种新技术,今天正好看到Bable最新入门The Complete Guide to ES6 with Babel 6,正好我写xgame-api的时候饱受node不能完全支持ES6之苦,马上坐正准备好好看。

然后就看到:

Keeping up to date

Here’s a little story: while writing these guides, I learned that the require hook in babel-core used by Gulp and Mocha is already set to be deprecated.

跟上变化

讲个段子:就在我写这套入门的时候,babel-core里的require钩子,就是Gulp和Mocha使用的那个,被标记为“弃用”

Babel6是24天之前发布的,这套文章是上周写的,核心API已经发生变化了。这让我不禁去想,紧跟业界潮流的成本会不会太高了?ES6的确提供了不少语法糖,以及终于像样的模块管理。如果现在就开始使用ES6,不仅可以提前享受到这一切,到标准真正到来的时候,可以省去升级的时间。

不过这里面之考虑了标准变化,没有考虑需求变化和产品变化。如果是抽象性很强的代码,比如某种算法库,或者某个功能组件,那么从开发之日起,遇到的变化可能不会太多太大。但如果是业务代码,就不得不遭遇各种各样的修改和变化,于是功能稳定便于维护就更加重要。紧跟潮流,意味着必须付出多余的精力去应对各种不稳定导致的节外生枝,一不小心,业务逻辑就要延期交付鸟。

又有个切身例子。Tiger Prawn(后面简称TP)立项的时候,模块管理无论是AMD还是CMD还是sea.js都难以让人满意,所以我就用了最简单的直接引用和命名空间。前几日用Browserify感觉不错,赶上TP遇到个问题,就寻思着重构下。结果努力一天之后,架构变化还是太复杂,遂放弃。次日修正实际问题只花了半天。生产中,还是优秀的架构设计更重要,毕竟开发和维护效率至上;追新追潮流几乎都可以算是作死的行为。

那么什么时候学习新技术呢?程序员都应该做业余项目,不是私活,而是根据一些平日里瞎想出来的需求,用一些新技术去实现,即使实现不了,也能够实地演练各种新技术。这样,有朝一日新技术成熟了,就可以很快应用到新产品中。

给WebStorm添加FileWatcher支持Browserify

使用WebStorm的FileWatcher可以进行各种文件编译,除了内建类型,添加自定义类型也完全没有问题。

按惯例先介绍本文角色:

Browserify 是一款让我们在浏览器端使用require('modules')来管理模块的工具。它会分析代码中的依赖关系,然后进行编译,打包成一个文件,我们只需要在HTML中引用生成的文件即可。

WebStorm 则是JetBrains出品的开发利器,集成了各种开发工具和环境,价格不贵,速度很快,样式好看,我非常喜欢。

Browserify 也提供了个工具,叫 watchify ,可以监控文件变化,即时编译。不过我更喜欢让WebStorm帮我处理这些事情,所以小小研究了一下,配置成功。

具体步骤

  1. 通过 NPM 安装 Browserify
    npm install browserify -g
    
  2. [Preferences] -> [Tools] -> [File Watchers]

  3. 点击“+”按钮,没有内建方案,所以选择“<custom>”

    WebStorm Preferences

  4. 名字(Name)随便写,描述(Description)可以留空,重点是下面几项

  5. FileType 选择 JavaScript

  6. Scope 监控范围,内建的都不合适,所以点“…”按钮,弹出自定义的监控范围

  7. 新建一个域,名字和项目一样,好认。展开项目目录,选择存放JS文件的目录,点右侧的“Include”和“Include Recursively”将该目录下所有文件和文件夹都包含进来。OK保存。

    WebStorm Scope

  8. Program 是要执行的程序,这里自然是 Browserify,Mac下通常在/usr/local/bin/browserify

  9. Arguments 参数,参考 Browserify 的文档介绍,常规命令是

    browserify index.js -o bundle.js --debug
    

    其中 index.js 是我的入口JS,那么直接去掉 browserify 就好了。

  10. Working Directory 工作目录,点击右侧的“Insert Macros”按钮,选择 “$ProjectFileDir$”。后面接上目录“/js/”。

  11. 完成!

    WebStorm Browserify File Watcher

小优化

  1. 前面我们设置监控范围的时候比较粗放,这样生成 bundle.js 之后会再跑一遍,有点不爽,所以图中我把 bundle.js 过滤掉了

  2. 确保这个File Watcher正常工作后,可以去把 Show console 设置成Never,这样在编辑到一半的时候就不会有错误提示了。

bower小技巧一则

在项目根目录下创建.bowerrc文件,可以改变bower安装组件的默认目录。

早先看到过一个用socket服务在线调试PHP的工具,后来怎么也找不到,于是决定自己造轮子。socket.io提供WebSocket服务,nodejs(今天竟然发布了5.0stable,简直丧心病狂) + express.js做服务器端。以前没有正经用过express.js,不过感觉上把Web所需的内容和nodejs所需的内容混在一起应该不是什么最佳实践,还是分开比较好。

使用express.static('public')可以把public目录映射为web根目录。但是用bower管理依赖的话,默认安装目录在项目的根目录,虽然也可以映射出去,不过实际路径和项目路径有异,Webstorm里的黄色波浪线看起来也很不舒服。

Google一下果然bower可以解决这个问题。在项目根目录下创建.bowerrc文件,按照JSON的写法,写入:

    {
      "directory": "public/components"
    }

就可以指定别的目录作为安装依赖的位置。然后可以移动原来的依赖文件夹,也可以重新执行bower install

Chrome表单验证和keyup导致的灵异问题

chrome的表单验证在keydown之后触发,可能会导致依赖keyup事件的一些东西出问题。

先说下环境,Mac OS El Capitan + Chrome 46,框架是Backbone + Boostrap。

我做了一个自动搜索组件,独立测试时一切正常,放到产品中,别的都没问题,只有回车会出问题。代码在这里

不用说,这个问题很诡异,调试了半天没有头绪,只能通过观察现象去推测:

  1. 没有报错
  2. 除了回车,其它功能正常
  3. 除了回车,keyUpHandler都能被正确触发
  4. 回车后,光标跳到其它元素

看来看去,第4条最可疑——我按的是回车,它会什么会跳到别的单元格呢?

这次运气比较好,表单中的接下来的几个元素刚好是日期,用到Bootstrap Datetimepicker这个插件,focus之后会自动填充日期。于是我发现,每次跳到的“其它元素”,都是原先空白的,而且是required的;不会跳到固定的,或者紧挨着的那个文本框。

于是我便想,会不会是:

  1. 表单submitkeydown之后触发
  2. 触发之后进行表单验证,发现有未填的required元素,于是跳到该元素并提示
  3. Bootstrap Datetimepicker响应focus时间,填入日期,提示消失
  4. 我的Typeahead响应blur事件,隐藏列表
  5. keyup事件触发,但是输入框已没有焦点,就没有触发

这个推测看起来有点道理,于是我把侦听的事件改成keydown,问题果然解决。

再访富国岛

希望孩子慢慢长大,慢慢将我们的世界分享给他。

2011年,我参加工作的第五个年头,201二进宫的第二个年头,我和老婆去越南富国岛度蜜月。这趟旅程给我带来的远不止美好的回忆:第一次出国,各种新奇的经历,让我禁不住重新思考过去五年在201的种种经历,最终决定立刻离开。

所以我现在经常建议年轻人出国转转,修正修正三观。

言归正传。这次国庆本来计划去甲米或者别的什么没去过的敌方,后来订票订晚了,到处都很贵,于是想起来这个性价比极高的地方:上次曾经订下一个5年之约,虽然这还差半年,也算是还愿了。

越南,富国岛,似乎没有太大的变化,Mango Bay有好吃的食物和开放的房间,Bai Sao依然美丽动人,Le Verenda的服务和环境也仍然让人心旷神怡。不过对于我们而言,最大的变化是这次带了姆二。亲子游最大的变化就是一切日程以孩子为准:早上起来吃早饭,然后找个地方玩一下;然后吃午饭,睡午觉;醒了再找个地方玩一会儿,接着就吃晚饭;然后回去洗澡准备睡觉。第二天重演这个过程。

原本想躺在沙滩上发呆,或者坐在露台上看书,或者两个人一起做马杀鸡,结果全成了陪小朋友挖沙土或者游泳。而且感觉时间过得飞快,一睁一闭,就回来上班了!有了孩子就是这样,带了他要后悔,不带的话,可能更后悔。

Anyway,仍然希望孩子慢慢长大,慢慢将我们的世界分享给他。

初尝Gulp

本文从4个方面对比了Grunt和Gulp的优劣,根据我个人的状态,最终还是选择Grunt。不过将来,说不定我也会转投Gulp。

Gulp自出世起,热度就很高。它利用了Node的Stream机制,速度很快;函数式的写法也很便于阅读。这两大优势让它一跃成为最受欢迎的批处理工具,几乎占据了半壁江山(2015前端工具普查)。

我之前一直用Grunt,为了不落后于时代,前几天在一个业余项目中试用了一下Gulp,以下是我的感受。

确实好读

虽然无法得到证实,不过我相信Grunt的设计中有很多都是借鉴Ant得来的——在没有Grunt之前,我曾经用Ant脚本 + Google Closer Compiler + Google Closer Stylesheets 压缩代码——比如,它的配置是JSON格式的,跟XML非常相像。Grunt的问题也在这里:声明任务需要写JSON配置文件,不同的任务需要写在一起,然后通过registerTask('task', ['task1', 'task2:js', 'task3', ....])来组织。这样前后脱节,确实既不好写,也不好读。个把月回来完全看不懂也不算意外……

而Gulp的设计则更加自由,它充分利用JavaScript的函数式写法,一个任务就处理一批文件,从上往下看,结构非常清晰:

    gulp.task('js', function () {
      gulp.src(['js/'])
        .pipe(concat())
        .pipe(replace('@version@', version))
        .pipe(uglify())
        .pipe(gulp.dest('dist/js/app.js'));
    });

胜者:Gulp

速度快,然无卵

Gulp受推崇的另一大原因就是速度快,一般的任务都是毫秒级。

不过,这对于我来说意义不大。作为一名人民币玩家,哥的惯用IDE是WebStorm和PHPStorm,均支持文件实时编译和自动刷新等常用功能。所以我只需要批处理工具帮我压缩文件和打包即可。

这个回合:打平。

Stream VS Native,异步 VS 同步

前面提到,Gulp利用了Node的Stream机制,它的内部是处理文档流。这方面Grunt比较保守,仍然是把文件读进内存,然后进行字符串操作。二者的机制不同不好对比,不过作为从页面仔成长起来的前端工程师,不得不承认我对的理解并不深刻,对文件读取和二进制操作也不甚了了,所以在理解二者和开发业务插件的时候,我宁可选择Grunt。

另外,Gulp的任务是异步的,所以在我的使用场景中——先clean目录,然后各种压缩,最后打包成zip——就很难搞(所以我觉得很多人用Gulp只是为了实时编译预处理文件)。后来用了sequence插件才搞定。

这方面我觉得Grunt虽然保守,但是更接近前端开发者的知识结构,学习成本更低。

胜者:Grunt

杂项

Gulp的团队应该是有代码洁癖的,比如,他们有一个官方插件仓库,这很正常;但是他们竟然还有一个Gulp插件黑名单……简直匪夷所思……

所以Gulp团队显然不愿意重复发明轮子,比如简单的clean目录,他们就不愿意做,而且也不让别人做,因为已经有很多工具可以实现这个功能了……但是对于初学者比如我来说,就会在插件引擎中找半天,最后还是Google到相关指引才得到正确的做法。

这方面Grunt团队做的很好。Grunt插件中有一组是官方提供的,以grunt-contrib为命名空间,基本上,使用这套组件就可以完成我所有的日常工作了。

胜者:Grunt


总结

大趋势上,Gulp的确势头迅猛。但是从实际体验中,我觉得Grunt目前更成熟,也能满足工作所需。

我并不想说Gulp不好,只是现在的我用起来不太顺手。如果哪天我有时间好好搞搞后端,搞搞Node开发,把Stream概念搞清楚,也许我也会转投Gulp。不过目前,还是继续用Grunt吧。

Handlebars 4

Handlebars升级到4.0后,{{#if}}不再作为一层影响查找,以前的`../../`可以改成`../`了。

图文……好像有关。

Handlebars自从升到2.0之后,就放开了,版本号蹭蹭涨,如今已经升到4.0版。

这个版本最显著的变化在于层级结构,以往的版本中,所有的Block Helper都可以形成一个层级。对于{{#each}}{{#with}}这种还好说,层级关系比较明确,很好理解;但是{{#if}},也有可能形成一个层级,这就很奇怪了。尤其像我前文所述,它只是可能形成一个层级,就更诡异了。

所以这个修改其实是件好事儿。

接下来,代码时间。

Before

    {{#each list}}
      {{#if is_true}}
        <p>这里需要向上两层才能找到值。{{../../value}}注意,这里是两层。</p>
      {{/if}}
    {{/each}}
    var data = {
        list: [
          // items..
        ],
        value: 'value'
      }
      , template = Handlebars.compile(hbs);
    template(data);

After

    {{#each list}}
      {{#if is_true}}
        <p>这里需要向上两层才能找到值。{{../value}}那,这里只有一层了</p>
      {{/if}}
    {{/each}}

JavaScript是一样的。

总结

为了写这篇文章又去看了一遍Handlebars的文档,发现新增了不少特性,尤其开始支持子表达式,看来有必要再好好看一遍。

近期要学习实践的新技术

接下来的一段时间里主动学习,更新一下知识。

众所周知,程序员是一个必须随时更新知识技能的职业。这其中,前端程序员尤甚。虽然我自称全栈,多半也要依赖前端技术作为小无相功驱使内力,方能打出少林寺七十二绝技写出其它平台的产品。所以,主动学习,更新知识技能是我必须坚持的。

同时,在前端这个充满变革的领域,我不能把各种新奇的东西都放到实际生产中去。所以,不定期的集中学习就不可避免。

那么,近期要学习实践的新技术有哪些呢?

  1. Bootstrap 4
  2. gulp
  3. Angular 2 直接从2开始吧,计划做个Todo
  4. React + React Native 要不做鸡血君?
  5. Polymer
  6. Material Design Lite
  7. Phonegap 5 自然是迁移游戏泡泡
  8. Eletron 结合别的技术做个写博客的工具。
  9. socket.io
  10. browserify

希望能在年底前搞定。

大招募!2016年春节北海道滑雪之旅

计划明年年初去日本滑雪。

这个人啊,真的跑不了的。有了孩子后,啥都想给他。今年去清迈耍了泼水节,回来后突然特别想带他去滑雪,当然也有吃货俱乐部北海道特辑的原因。加上以前就特别想跟老婆去日本,于是便开始各种YY。

现在准备把YY落地,同时也向各位兄弟姐妹同学同事发出邀请(是的,我不仅好了伤疤忘了痛而且忘得厉害),明年我们一起去北海道打雪仗吧!

继续阅读“大招募!2016年春节北海道滑雪之旅”