Javascript之旅——第七站:说说js的调试

  最近比较吐槽,大家都知道,现在web前端相对几年前来说已经变得很重了,各种js框架,各种面对对象,而且项目多了,就会提取公共模块,

这些模块的UI展示都一样,不一样的就是后台逻辑,举个例子吧,我们做企业差旅的时候,通常都有一个成本中心的js公共模块,客户在预定机票

的时候来填写这个成本中心,而这种成本中心分布在online,offline和app等预定端,这样也是方便后期和客户公司进行月结算。

  我们还知道,项目做大了,复杂化了,SOA化了之后,很多问题就来了,就像web中的一个理论,所有前端的数据都是不可信的,那对方团队

的接口数据又何尝不是,以前项目小的时候,不会那么不自信,也只会在Logic error的时候会记录下日志,正常的业务流程一般很少记录,毕竟

info日志看着不美观,而且还会消耗服务器带宽,也还会拖累web的性能,但是项目大了,当你某天在项目中遇到了奇怪的bug时,你靠着残缺不

全的日志,好不容易用肉眼逐行追溯到了接口,但是参数太多,无法准确的还原接口的参数数据,但是你又100%的自信认定肯定就是接口的返回

问题,但是又拿不出完整的报文,这时候你又没法找接口提供方,当时那个无奈呀,多想最好每行都有日志该多好啊,有了教训后,记流程日志的

趋势越来越盛行,最终也酿造了一个年初的大事件,稀里糊涂的说了一大堆,web后端如此,那现在的重前端不也一样要记录日志么?我们知道既

然是公共的js模块,那这个模块肯定自己封装了一些方法,肯定是绝对不可以让第三方程序去操作它自己的文本结点,比如下面这样:

<!--third  module -->
公司:<input type="text" id="company" value="xxx有限公司" />
员工姓名:<input type="text" id="username" value="张三" />
<!-- -->

<script type="text/javascript">

    //成本中心
    var costCenter = (function () {
        var company = (document.getElementById("company") || "") && document.getElementById("company").value;
        var username = (document.getElementById("username") || "") && document.getElementById("username").value;

        var result = {
            getInfo: function () {
                return { company: company, username: username };
            },
            validation: function () {
                return Boolean(company && username);
            }
        };

        return result;

    })();

</script>

 

为了简化操作,第三方UI提供了公司名和员工姓名的UI结点,并且封装了一个costcenter类来提供读取方法,可以看到,我的预定程序只需读

取costCenter.getInfo就好了,也起到了一个封装的作用,但是问题就出现在这里,项目实战中会因为各种原因导致在costcenter中取不到值,

当然也可能是common ui的bug,但是当时你又不能非常确定是否真的取到了值,但是在逻辑上就算取不到值,原则上你也不能阻止订单提交,

所以为了彻底追踪bug,就写了个logCenter单例类来记录日志。通常用js来记录log有这种方法。

 

<1> ajax

  这种方式很容易想到,但是你使用原生的xmlhttprequest的话,还需要考虑浏览器兼容,但不用原生的话,就要借助于第三方框架,比如

jquery,但是毕竟还是有很多公司是不使用jquery的,所以这个要根据实际的需要来使用了。

//日志中心
    var logCenter = (function () {

        var result = {
            info: function (title, message) {
                //ajax操作
                $.get("http://xxx.com", { "title": title, "message": message }, function () {

                }, "post");

            }
        };

        return result;

    })();

<2>image

   我们的dom中有一个叫做image的对象,所以可以通过动态给它的src赋值来达到请求后台url的目的,同时在url中加上我们需要传递 title和

message信息,这种动态给image.src的方式是不需要考虑浏览器兼容性的问题,非常不错。

//日志中心
    var logCenter = (function () {

        var result = {
            info: function (title, message) {
                //ajax操作
                $.get("http://xxx.com", { "title": title, "message": message }, function () {

                }, "post");

            },

            info_image: function (title, message) {
                //image
                var img = new Image();

                img.src = "http://www.baidu.com?title=" + title + "&message=" + message + "&temp=" + (Math.random() * 100000);
            }
        };

        return result;

    })();

从上图中我们看到network中已经有了url请求,服务器端就可以querystring下url的参数,然后就可以开开心心的把日志记录下来,供后续我们

彻底的排查js前端中的流程信息,到时候谁都不可以扯皮。

时间: 2024-12-29 22:23:33

Javascript之旅——第七站:说说js的调试的相关文章

Javascript之旅——第四站:parseInt中要注意的坑

原文:Javascript之旅--第四站:parseInt中要注意的坑   前些天信用卡站点要接入一个新功能,不过还真比较坑爹,asp站点,大家都知道信用卡的背面是有一个有效期的,在对接银行中这个信息 一定是要传给银行做数据校验,用户在语音输入信用卡有效期后,系统会做一个有效期判断,为了不必要的麻烦,就是判断过期时间一定不能在 一个月内,由于输入的年月日在三个文本框中,再加上我嫌转成时间麻烦,就索性直接拿年,月,日的文本内容直接强转成int类型来判断,此为 背景. 说了这么多,终于说到文章主题了

Javascript之旅——第六站:看看writable特性

原文:Javascript之旅--第六站:看看writable特性 说起js中的那些特性标记,总觉得有些怪怪的,那为什么要说到这个attribute,起源于对一个问题的疑问,我们都知道window对象其实就是 浏览器窗口的一个实例,既然是一个实例,那这个实例就应该有"属性"和"方法",比如下面这样: 我们平时都在使用function的时候,都会定义一些属性,比如name,age等等,并且还可以对他们进行delete,set和update操作. 那么下面问题来了,既然

Javascript之旅——第八站:说说instanceof踩了一个坑

原文:Javascript之旅--第八站:说说instanceof踩了一个坑 前些天写js遇到了一个instanceof的坑,我们的页面中有一个iframe,我在index页面中计算得到了一个array,然后需要传递到Flight页面 这个嵌套的iframe中的一个函数(SearchFlight)中,作为防御性编程,我需要在SearchFlight函数中进行参数检测,也就是判断过来的参数一 定是Array类型.   一:抛出问题 举个例子,下面有两个页面. Index.html页面 1 <!DO

Javascript之旅——第十站:为什么都说闭包难理解呢?

研究过js的朋友大多会说,理解了js的原型和闭包就可以了,然后又说这些都是js的高级内容,然后就又扯到了各种神马的作用域...然后不少 人就会被忽悠的云里雾里...下面我也试着来说说闭包,看我说的这个是否浅显易懂...   一:闭包含义 闭包是个专业词汇,这样才能显得在js中是高大上的货色,官方定义我这里就不敢修改它,定义如下:就是有权访问另一个函数作用域的变量的函数.   二:一个简单的场景 上面的定义大概也能看得懂,但是不知道为什么不把"另一个函数" 改成 "包含函数&q

Javascript之旅——第十一站:原型也不好理解?

写到这篇,我的js系列也快接近尾声了,所以这个系列不会遗留js来实现面向对象的核心--原型,有些人说原型不好理解,其实嘛,要想系统 的理解原型,最便捷的方式就是看看经典的书,少看些博客,博客这东西只是博主自己的个人理解,充其量是些配味的佐料. 一:继承 如果你熟悉C#的话,你肯定会知道,所有的类都是继承于Object的,这样我就拥有Object所具有的功能了,如下图中我定义的Person类. 从图中可以看到,在C#中到处都是继承,下一步我要做的就是自定义继承,如下图中我定义的Student类,让

Javascript之旅——第三站:几个需要注意的运算符

平时写惯了C#,所以会觉得什么样的运算符就应该做什么样的运算,但是有一天你的习惯被其他语言颠覆了,不知道是不是有一股强大的好奇 心,刚好在js中,我的这种习惯就被颠覆了,下面就看看哪些运算符颠覆了我的三观.   一:==运算符 ==运算符之所以可以颠覆,可以从下面几个例子中看出来.   <1> "10"==10 ? 如果这要是放在C#里面,编译器会毫不客气的告诉你,王八羔子,类型都不同,你比个毛线啊...但是在JS里面又会是怎样呢? 从上图中,你可以看到,不管你好奇不好奇,

Javascript之旅——第五站:说说那些所谓的包装类型

最近不看犀牛书了,那本翻译的特烂而且好拗口,尤其是原型那块说的乱七八糟,后来经同事介绍,买了本js高级程序设计,然后就继续 苦逼的看,不吐槽了,继续说说js中有新鲜感的包装类型.   一:String 说到String类型,蛮有意思,平时我们都是这样定义一个string类型,如下图: 但是在js中有一点非常特别,那就是string类型是属于基本类型,不属于引用类型,那就说明string的值是保存在"栈"上面的,而很多语言不是 这样,比如C#,我觉得js不作为引用类型也是情有可原,毕竟它

Sql Server之旅——第七站 为什么都说状态少的字段不能建索引

我们在学sqlserver的时候,大多教科书和前辈们都说状态少的字段不要建索引,由此带来的开销还不如不建索引,但是这句话有多少人真的知道, 或者说有多少人真的对此有比较深刻的理解,而不是听别人道听途说...这样记得快,忘记的也不慢...这篇我来分析一下这句话到底有几个意思.   一:现象 首先我们还是用测试数据来发现问题,我先建立一个Person,有5个字段,建表sql如下: DROP TABLE dbo.Person CREATE TABLE Person(ID INT PRIMARY KEY

Javascript之旅——第二站:对象和数组

原文:Javascript之旅--第二站:对象和数组   一觉睡到中午,本来准备起来洗洗继续睡,不过想想没辙,还得继续这个系列,走过变量的第一站,第二站我们再来看看对象和数组.   一:对象   说起对象,我们不自然就想起了面向对象中自封装的一个类,同样JS中也是遵循这个守则,在web编程中几乎天天用到的就是JSON.是的, 这就是一个对象,不过这个对象下面的字段都是字符串和值类型,如下图. 1 var delivery = { 2 no: 1, 3 sendtime: "2014-11-25&