‘前端开发’ 分类的存档

从gmail开始,前端总结出了ajax的概念,也让前端开发工程师们得到了更多的重视,前端技能是一个很庞大的体系,W3C标准,Dom结构,Css样式,Javascript编程 ……

没有评论讨论闭包传入参数:window & undefined

2010年5月21日

引言

最常见的闭包 (Closure) 范式大家都很熟悉了:

(function() {
// ...
})();

很简单,大家都在用。但是,我们需要了解更多。
首先,闭包是一个匿名函数 (Anonymous function), 即是 (function() {}) 这部分。之所以要给 function 添加括弧是为了让它形成一个表达式 (expression), 有了表达式,并且确定它的类型是个函数 (Function 实例), 就可以直接调用它。所以,后面的一对括弧是可以工作的,它的意义是:我要调用 (call) 这个函数。

既然是函数调用,那就可以像一般的函数那样,在调用时传入参数。这就是本次讨论的话题。

传入 window 参数

 

(function(win) {
// ...
})(window);

这样做最直观的好处是书写便利:少写几个字。你可以在闭包内任何地方使用 win, 它都会指向 window 对象。另外,它有利于压缩减少最终代码的体积,经过压缩后 (如 Google Closure Complier), 所有的 win 都会被替换成形如 a 这样的简单变量。win 用得越多,减少的字节数也越多。

不过,便利的同时也会带来陷阱。在 IE 上,window 总是指向当前窗口对象,这个没有问题,但是在某些场景下,使用闭包内的 win 变量会导致拒绝访问错误 (Access denied). 重现方式大致是这样的:当页面引用其他域名的脚本,并且该脚本调用了闭包内的 window.document, 而且这个闭包代码是来自另一个域名的脚本。在这种情况下,使用 win 会保持对 window 最早的引用,通过另一个域的脚本访问 win 会导致 IE 认为脚本产生了跨越冲突,从而拒绝了对 win.document 的访问。解决办法是不使用形参 win, 而是直接使用 window. 需要说明的是,给闭包传入 document 也会导致 IE 出现同样的问题。

传入 undefined

其实把 undefined 作为形参就,实参就可以不用传了,因为 JavaScript 中访问未传入的参数就会得到 undefined. 因此,你可以这样写:

(function(undefined) {
// ...
})();

和上面的讨论一样,你可以在闭包内任何地方使用 undefined, 可以少写几个字(如果把 undefined 换成更短的名字),也可以在减少压缩后体积。

另一个的优势是,你可以认为它是个变量,把它当变量来使用,它的值恒等于 (===) 真正的 undefined. 当外部代码意外地定义了 undefined 的时候——不常见,但确实可能会发生——你可以正常地使用真正的 undefined, 而不会被外部的 undefined 意外影响. 这是由 JavaScript 作用域规则决定的。
无论是否使用这个 undefined 参数,都应该避免使用 undefined 的字符串常量,如:

if(typeof myVar === 'undefined') {
// bad part...
}

因为如果你把字符串写错了,机器不会告诉你,而且会产生一个难以检查出来的bug. 幸运的是,对于 JavaScript 来说,JsLint 可以帮你做这个校验。当 myVar 已定义的时候(通过形参或 var 声明),上面的代码改成这样会更易于调试:

if(myVar === undefined) {
// good part...
}

结论

从上面两个例子来看,我们建议不要传入 window, 但是可以安全地使用第二种方式 (写 undefined 形参);我们还要尽量避免使用字符串常量。
最后,最重要的是,这只是两个特定对象和类型的讨论,举一反三,你会更了解 JavaScript

转自阿里UED:http://ued.alipay.com/2010/05/using-window-and-undefined-as-parameter-in-closure/

7 条评论WEB标准化交流会第七期-人人都是”架构”师

2010年4月24日

今天很荣幸的第三次的参加了WEB标准化交流会
地点是在在北京航空航天大学的第八会议室,这次交流会改变了以往的圆桌讨论方式,改为分享的方式,今天的两场分享都很精彩 第一场是微软的IE9分享,第二场是周爱民老师的前端架构实战

WEB标准化交流会让我认识了不少新朋友、今天更巧的是遇到了一年前项目合作过的同事:)

IE9的分享 重点在于IE系列终于迈向标准化 并且将GPU引入浏览器引擎,对于渲染速度和性能大大提升,同时透露出XP下无论哪个浏览器都是无法使用GPU加速的,虽然不知道这个说法的可信性,但是这次IE的预览,还是有一些收获的,至少让我们看到了浏览器越来越标准,当然更重要的是kill IE6

第二场爱民老师的分享让我比较有收获,几个方面吧

1.解决问题的思路-共性、本质,找到问题的根源
现场的例子:以为运营说需要在这里加一个按钮,他的需求真的是要多加一个按钮么?实际上可能是觉得原来按钮的位置并不合适
2.系统框架、框架、库、应用的概念
说实话,听的确实有些模糊,不过两个例子很精彩,由浅入深的,讲解了是如何一步一步的抽象出最终的系统框架。
从我的理解,库是相互没有依赖关系的,框架是来将库进行一个抽象关联,而系统框架,是更本质的抽象出了某一类业务的底层逻辑包括一些必须的数据和逻辑关联

给我印象比较深的一张图片如下:

当我们更多的关注于插件机制、组建机制、消息机制的时候、我们更应该从需求变更、版本升级、产品整合的视角来看待他们的本质

而我的观点是-人人都是”架构”师

为什么这么说呢?哈,首先我所说的架构是加了引号的

我理解的”架构”呢,更贴近我们的生活,工作,架构可大可小,”系统架构师”可能我们确实需要很多积累、天赋,而我们要把架构的意识引入到我们的日常生活中来

几个例子:
1.职业规划 是不是架构?
2.当我们保存站点文件,站点文件的目录是不是架构?
3.CSS的reset、grid、form等算不算架构呢?
4.我们经常用js写的weiget又算不算架构呢?
……
我相信在我们的生活、工作中、架构无所不在-人人都是”架构”师

6 条评论最近写日期操作的几个JS函数

2010年4月23日
//格式化函数 Date原型扩展
Date.prototype.format = function(format)
{
 var o = {

 "M+" : this.getMonth()+1, // month
 "d+" : this.getDate(),// day
 "h+" : this.getHours(), // hour
 "m+" : this.getMinutes(), // minute
 "s+" : this.getSeconds(), // second
 "q+" : Math.floor((this.getMonth()+3)/3), // quarter
 "S" : this.getMilliseconds() // millisecond
 }

 if(/(y+)/.test(format))
 format = format.replace(RegExp.$1,(this.getFullYear()+"").substr(4 - RegExp.$1.length));
 for(var k in o)
 if(new RegExp("("+ k +")").test(format))
 format = format.replace(RegExp.$1,RegExp.$1.length==1 ? o[k] :( "00"+ o[k]).substr((""+ o[k]).length));
 return format;
}
// 日期比较

function datecompare(startDate, endDate) {
 var re = /^(\d{4})(\-)(\d{1,2})(\-)(\d{1,2})$/;
 var d1 = new Date(startDate.replace(/-/g, "/"));
 var d2 = new Date(endDate.replace(/-/g, "/"));
 if (Date.parse(d1) - Date.parse(d2) == 0) {
 // window.alert("两个日期相等");
 return "1";
 }
 if (Date.parse(d1) - Date.parse(d2) < 0) {
 // window.alert("结束日期 大于 开始日期");
 return "2";
 }
 if (Date.parse(d1) - Date.parse(d2) > 0) {
 // window.alert("结束日期 小于 开始日期");
 return "3";
 }
}
//添加一天
function DateAddOneDay(now){
 return new Date(Date.parse(now) + (86400000 * 1))
}

没有评论编码大全 – 前端相关

2010年4月23日


这是我在本周珍珠奶茶会上做的分享。编码的细节太多太多,对于前端工程师,掌握主流常用的编码就可以了,并知晓后端处理URL编码的基本思路以及浏览器在 处理编码问题上的差异性。

ps:补充一点,encodeURIComponent和encodeURI,可以参照玉伯的例子
http://lifesinger.googlecode.com/svn/tr … _test.html

没有评论如何量身打造一个前端框架

2010年4月15日

转一篇:taobao拔赤的一篇文章 写的很好 查看原文

程序层面,重点是?

框架包含:核心(core)、适配器(adapter)、基础接口(public api)、代码管理(sandbox & plugin)、组件库(widgets),显然,框架的重点在于基础接口、和代码管理机制的设计。widget的实现是基于框架提供的public api,public api interface一旦定型尽量不要更改,也就是说,设计要遵循编程基本原则:面向接口,而不是面向实现,这个原则的基本要求是接口的稳定性。因此,框架版本升级导致接口更改的情况可以不考虑?

框架设计师应当将有限的精力放在adapter、public api、sandbox & plugins上,以保证框架基础逻辑设计思路清晰,widget和外部plugin的实现则是纯粹工作量的堆积,可以由更多的人参与开发,以分担框架设计师的工作。

需不需要对core进行重构?

比较纠结的问题是,要不要对core进行重构?即将适配器以下都由自己重构,完全放弃现有的jquery或者yui,这个看情况,个人认为,使用现成的“库”是比较聪明的选择,开源的初衷不也是这样吗?我们要做的,只是将jquery式的api或者yui式的api转换成我想要的api格式即可,api的实现,有什么重要呢?

开发者的角色?

框架设计:框架设计师着力设计public api和sandbox & plugin,adapter可以另有人做,只要对adapter有规范完整的黑盒测试即可。
widget开发:可以由更多的人基于pbulic api开发大量的widget,入库保证有code review即可。
应用开发:任何人基于sandbox和widget都可以开发app了。

各自的视野?

对于框架的使用者来说,他们的视野仅限于sandbox、plugin usage、widgets,手旁只要准备一本public api手册就天下无敌了。对于框架开发小组来说,着重维护widget和api,把项目中的widgets不断抽离、code review并入库。对于工程师来说,他们的视野是一本手册和一些demo,没有必要理解框架的细节。对于那些业余的人来说,让他们一眼看到这个框架有这么多widget和demo,他们就会傻乎乎的开始用了。。。

因此,框架的开发,在于专业、在于坚持、在于团队,三者缺一不可。。。