AMD and CMD are dead之KMDjs内核之依赖分析

有人说js中有三座大三:this、原型链和scope tree,搞懂了他们就算是js成人礼。当然还有其他不同看法的js成人礼,如熟悉js的:OOP、AP、FP、DOP、AOP。当然还听说一种最牛B的js成人礼:熟悉jQuery……=   =!因为$里面可以放下全世界,比如$(“全世界”)…

这篇文章主要讲KMDjs利用Uglify2去分析出一个函数的所有依赖,之后才能正确地加载相关的js文件。该文涉及到js中三座大山中的scope tree….先看下面这段程序:

function test() {
    var user = new User();
}

很显然,该函数依赖User。我一定要去加载User.js才能正确执行该函数。那么我是不是可以写一段非常牛B的正则找到new  和()之间的User。当然,这样一定是不对的,因为js里创建对象的实例可以省略括号,比如:

function test() {
    var user = new User;
}

那么,是不是可以写一段非常牛B的正则,去查找new与分号之间的东西?相对于这个函数,是可以的!但是如果,这个函数长成这个样子:

function test(User) {
    var user = new User;
}

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

可以看得到,该函数不依赖任何对象,User是test的参数传递进来…,那么我是不是可以写一段非常牛B的正则,先找到test(User)中的User参数,然后再通过正则找到new后面的所有对象,最后把第二次查找到的结果过滤掉第一次查找到的参数。好问题来了,如果程序长这样子:

function test(User) {
    var xxx = "(User)";
    var user = new User;
}

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }可能有人会说了,只能说明你的正则不牛B。牛B的正则是可以确认是字符串中的,还是非字符串中的。那么再看下一段程序:

function test() {
    var User = function (name) {
        this.name = name;
    }
    var u = new User();
}

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

可以看得出,User根本不是参数,而是直接在test内部定义!那么这个函数其实是不依赖User。那么,刚刚憋出的两段牛B的正则就彻底废掉了。再比如:

function test() {
    var vp = Bom.getViewport();
}

可以看到,直接访问Bom的静态方法,都不需要new,就能访问Bom下的getViewport方法。所以,该函数依赖Bom。那么,刚刚憋出的两段牛B的正则再次彻底废掉了。再比如:

function test() {
    var vp = new Array();
    var el = document.getElementById("xx");
}

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

可以发现,window下的Array和document还需要过滤掉…,再比如

function test() {
    var h = 1;
    //这里 h a 都是可以找到,不能判定为赖
    function a(e) {
        //这里面h a e i都是可以找到,不能判定为赖
        var i = 2;
        function b(f) {
            //这里面h a e i b f c都是可以找到,不能判定为赖
            function c(g) {
                //这里面h a e b f都是可以找到,不能判定为赖
            }
        }
    }
}

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

如上面注释所描述,会有一串scope tree。那么…怎么办?uglify2有强大无比的ast.walk和UglifyJS.TreeWalker!如:

http://lisperator.net/blog/using-uglifyjs-for-code-refactoring/

这是官方重构代码的简单例子。受此文启发,我便为kmdjs写了个完美的依赖分析:

function getRef(fn) {
    var U2 = UglifyJS;
    var ast = U2.parse(fn.toString());
    ast.figure_out_scope();
    var result = [];
    ast.walk(new U2.TreeWalker(function (node) {
        if (node instanceof U2.AST_New) {
            var ex = node.expression;
            var name = ex.name;
            if (!isInScopeChainVariables(ex.scope, name)) {
                result.push(name);
            }
        }
        if (node instanceof U2.AST_Dot) {
            var ex = node.expression;
            var name = ex.name;
            if (!isInScopeChainVariables(ex.scope, name)) {
                result.push(name);
            }
        }
    }));
    return result;
}

function isInScopeChainVariables(scope, name) {
    var vars = scope.variables._values;
    if (Object.prototype.hasOwnProperty.call(vars, "$" + name)) {
        return true;
    }
    if (scope.parent_scope) {
        return isInScopeChainVariables(scope.parent_scope, name);
    }
    return false;
}

意外惊喜,在kmdjs加入lazy(kmdjs.get)之后,lazy内部的依赖不会加载!且看下面这段代码

function test(DDDDD) {
    kmdjs.get("HelloKMD.Ball", function (Ball) {
        //因为Ball是参数,属于该scope tree中的对象,所以不依赖
        var ball = new Ball(100, 100, 28, 1, 2, "KMD.js");

    });
}.csharpcode, .csharpcode pre
{
	font-size: small;
	color: black;
	font-family: consolas, "Courier New", courier, monospace;
	background-color: #ffffff;
	/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
	background-color: #f4f4f4;
	width: 100%;
	margin: 0em;
}
.csharpcode .lnum { color: #606060; }

完!

github:https://github.com/kmdjs/kmdjs
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

AMD and CMD are dead之KMDjs内核之依赖分析,布布扣,bubuko.com

时间: 2024-08-04 10:28:53

AMD and CMD are dead之KMDjs内核之依赖分析的相关文章

AMD and CMD are dead之KMDjs内核之分号

在老版本的kmdjs中,强制了分号的要求.但是总感觉不爽,因为在开发Ket - Kmdjs Extension Tools的时候,总需要导入一些开源的库,然后痛苦就来了,总是报错,一查,就是缺少分号!!后来一想,既能jslint可以检测哪里缺少分号,那么是不是可以在使用jslint在缺少的地方加分号?把jslint当作库来用,而不是工具,所以立刻看了看jslint源码,然后码了一段: 上面程序依赖于:http://jslint.com/webjslint.js 期间还遇到了,部分程序加了分号,部

AMD and CMD are dead之KMD.js之懒

缘由 "懒"在软件设计中,有着重大的意义.最常见的两种"懒",便是: 懒得计算 懒得加载 "懒得计算"常见于服务器端: 比如Multiplayer Online Role-PlayingGame,客户端主动计算,游戏服务器平滑过渡,在性能.游戏同步性找一个合适恰当的点.其目的是节约服务器端CPU.内存等的消耗,把许多消耗性能的计算分布在玩家电脑上: 比如cache,任何cache的目的都是:懒得重新计算,因为我已经计算过了. 比如web应用的表单

AMD and CMD are dead之JS工程化终极解决方案KMD.js版本0.0.1发布

回顾 经过两天晚上疯狂的开发调试,伴随着大量掉落的头发和酸痛的颈椎,KMD.js赢来了第一个稳定版本.在此期间KMD规范也有所修改和完善. 这两天主要完成的功能有: 按需加载 版本控制 模块管理 便捷调试 依赖打包 性能优化 依赖可视 在此,要感谢那些伟大的项目(虽然部分将要死去),但依然感谢: windjshttp://windjs.org/cn/ jsbeautifierhttp://jsbeautifier.org/ class.js http://ejohn.org/blog/simpl

AMD and CMD are dead之Why Namespace?

缘由 当我看到_Franky兄的微博的时候: 我觉得我有必要出来详细说说KMDjs到底有什么本质上的优势了,连教主_Franky.貘吃馍香都不能理解他的好处,那么可想而知,在前端圈.或是全端圈.或是IT圈,能够理解KMDjs优势的码夫更加是屈指可数. Why Namespace? KMDjs是能方便组织Namespace,并且Class Base.针对namespace,我还专门集成可视化库至KMDjs方便查看Namespace Tree.那么Why Namespace?不用会死吗?答案是:不会

AMD and CMD are dead之KMD.js版本0.0.2发布

更新 正式从UglifyJS切换至UglifyJS2 增加依赖可视化功能 压缩代码更加方便 统一风格:如main的class名也不能省略 优化了kmdjs管道 修复了无数bug 通过src开启debug模式 代码格式强制分号结束,不然报错 问题 1.从UglifyJS切换至UglifyJS2,主要是UglifyJS2把AST更加严格规范化,而且提供了方便的ast.walk遍历js代码的语法树,把任何代码分析得无比透彻,比巨复杂无比的正则表达式稳定靠谱多了,通过UglifyJS,使开发者能把js代

AMD and CMD are dead之KMD规范

What's KMD? 乱世出英雄,KMD名字的由来充满了杀气. Kill AMD and CMD KMD为替代混乱的AMD和CMD世界而生,一统天下.或者让这个混乱的世界更加混乱,导致: KMD AMD CMD三分天下 KMD的目标从来都是远大的: JS工程化终极解决方案 使用KMDjs的工程师从来都是: 尼玛,什么东西,这么NB? KMD规范 1.通过define定义命名空间和类 define("MyApp.User", { init: function (name,age) {

AMD and CMD are dead之js模块化黑魔法

缘由 在2013-03-06 13:58的时候,曾甩下一片文章叫:<为什么不使用requirejs和seajs>,并放下豪言说发布一款完美的模块化库,再后来就把那篇文章删了,再然后就没有然后.该用seajs还用seajs,甚至我码的SCJ都是用requirejs组织起来的. 时光飞逝,岁月流转.弹指间,来到了2014年6月15日,也就是昨日,突然码兴大发,一发不可收拾,也许跟最近小说和诗写得比较猛,把码意给压抑了,便有了这次喷发. js问题 作为一名前MS必应团队资深当耐特(.NET)石专家,

AMD and CMD are dead之KMD.js依赖可视化工具发布

使用 require("MyAapp.DepTree", function (DepTree) { DepTree(({ renderTo: "holder", width: "820", height: "580", data: [ { "name": "System" }, { "name": "Util" }, { "name&qu

浅析JS模块规范:AMD,CMD,CommonJS

随着JS模块化编程的发展,处理模块之间的依赖关系成为了维护的关键. 模块化 AMD,CMD,CommonJS是目前最常用的三种模块化书写规范. CommonJS CommonJS规范是诞生比较早的.NodeJS就采用了CommonJS.是这样加载模块: var clock = require('clock'); clock.start(); 这种写法适合服务端,因为在服务器读取模块都是在本地磁盘,加载速度很快.但是如果在客户端,加载模块的时候有可能出现"假死"状况.比如上面的例子中cl