您的位置:奥门新浦京网址 > Wed前段 > 如何调试Javascript,IE开发者工具教程

如何调试Javascript,IE开发者工具教程

发布时间:2019-10-14 18:31编辑:Wed前段浏览(99)

    谈谈前后端的分工协作

    2015/05/15 · HTML5 · 1 评论 · Web开发

    原文出处: 小胡子哥的博客(@Barret李靖)   

    前后端分工协作是一个老生常谈的大话题,很多公司都在尝试用工程化的方式去提升前后端之间交流的效率,降低沟通成本,并且也开发了大量的工具。但是几乎没有一种方式是令双方都很满意的。事实上,也不可能让所有人都满意。根本原因还是前后端之间的交集不够大,交流的核心往往只限于接口及接口往外扩散的一部分。这也是为什么很多公司在招聘的时候希望前端人员熟练掌握一门后台语言,后端同学了解前端的相关知识。

    Chrome控制台 如何调试Javascript

    2015/01/12 · JavaScript · Chrome

    原文出处: ctriphire   

    上面的文章已经大致介绍了一下console对象具体有哪些方面以及基本的应用,下面简单介绍一下如何利用好chrome控制台这个神器好好调试javascript代码(这个才是我们真正能用到实处的地方)

    1、先说一下源码定位

    大家打开测试网页   看到页面右下方有一个推荐的图标吗?右击推荐图标,选择审查元素,打开谷歌控制台,如下图所示

    图片 1

    我们现在想知道votePost方法到底在哪?跟着我这样做,在Console面板里面输入votePost然后回车

    图片 2

    直接点击上图标红的链接,控制台将定位到Sources面板中,展示如下图所示

    图片 3

    大家看了上面这个图片之后估计头都要晕了吧,这么多js都整在一行,让人怎么看呀,不用担心,按下图操作即可(也就是点击中间面板左下方的Pretty print就行了)

    图片 4

    这时我们再回到Console面板时会惊奇的发现原来的链接后面的1现在变成91了(其实这里的数字1或者91就是代表votePost方法在源码中的行号 )现在看出Pretty print按钮的强大之处了吧

    知道了怎么样查看某一个按钮的源码,那接下来的工作便是调试了,调试第一步需要做的便是设置断点,其实设置断点很简单,点击一下上图所示的92即可,这时你会发现92行号旁边会多了一个图标,这里解释一下为什么不在91处设置断点,你可以试下,事实上根本就没法在91处上设置断点,因为它是函数的定义处,所以没法在此设置断点。

    图片 5

    设置好了断点后,你就会在右边Breakpoints方框里看到刚刚设置的断点。

    我们先来介绍一下用到的调试快捷键吧(事实上我们也可以不用下表所示的快捷键,直接点击上图所示右侧栏最上层的一排按钮来进行调试,具体用哪个按钮,把鼠标放到按钮上方一会就会显示它相应的提示)

     

    快捷键 功能
    F8 恢复运行
    F10 步过,遇到自定义函数也当成一个语句执行,而不会进入函数内部
    F11 步入,遇到自定义函数就跟入到函数内部
    Shift + F11 步出,跳出当前自定义函数

    其中值得一提的是,当我们点击“推荐”按钮进行调试的时候会发现,不管我们是按的F10进行调试还是按F11进行逐步调试,都没法进行$.ajax函数内部,即使我们在函数内部设置了断点也没有办法进入,这里按F8才是真正起效果的,不信你试试。

    当我们在调试的时候,右侧Scope Variables里面会显示当前作用域以及他的父级作用域,以及闭包。你不仅能在右侧 Scope Variables(变量作用域) 一栏处看到当前变量,而且还能把鼠标直接移到任意变量上,就可以查看该变量的值。

    用图说话(哈哈)

    图片 6

     

    刚刚我们介绍的只是在html里面能够看得到它绑定了onclick事件,这样我们就找到它绑定的js函数,如果它是在jQuery页面加载完成函数里面绑定的,这时候我们怎么知道它绑定的是哪个js函数呢,如果我们不知道绑定的js函数就更加不用说调试进去了

    下面介绍一下如何查看,还是以刚刚那个测试网页为例子吧,但是这次我们来看“提交评论”作说明吧,

    右击“提交评论”–>审核元素,我们可以清楚的看到在这个按钮上未绑定任何事件。在Console面板内输入如下代码

    JavaScript

    function lookEvents (elem) { return $.data ? $.data( elem, "events", undefined, true ) : $._data( elem, "events" ); } var event = lookEvents($("#btn_comment_submit")[0]); // 获取绑定的事件

    1
    2
    3
    4
    function lookEvents (elem) {
        return $.data ? $.data( elem, "events", undefined, true ) : $._data( elem, "events" );
    }
    var event = lookEvents($("#btn_comment_submit")[0]); // 获取绑定的事件

    如下图所示:

    图片 7

    按照上述介绍的方法定位到具体的blog-common.js里面,找到postComment  然后一层层的找到具体的代码,再设置断点就好了。

    最后介绍一下一个神器,很好用的debugger

    如果你自己写的代码,你执行的时候想让它在某一处停下来,只要写上的debugger就好了,不信你试试!哈哈

    赞 1 收藏 评论

    图片 8

    IE开发者工具教程

    2015/01/13 · JavaScript · IE

    原文出处: YouYaInsist的博客   

    一、开发流程

    前端切完图,处理好接口信息,接着就是把静态demo交给后台去拼接,这是一般的流程。这种流程存在很多的缺陷。

    • 后端同学对文件进行拆分拼接的时候,由于对前端知识不熟悉,可能会搞出一堆bug,到最后又需要前端同学帮助分析原因,而前端同学又不是特别了解后端使用的模板,造成尴尬的局面。
    • 如果前端没有使用统一化的文件夹结构,并且静态资源(如图片,css,js等)没有剥离出来放到 CDN,而是使用相对路径去引用,当后端同学需要对静态资源作相关配置时,又得修改各个link,script标签的src属性,容易出错。
    • 接口问题
      1. 后端数据没有准备好,前端需要自己模拟一套,成本高,如果后期接口有改变,自己模拟的那套数据又不行了。
      2. 后端数据已经开发好,接口也准备好了,本地需要代理线上数据进行测试。这里有两个费神的地方,一是需要代理,否则可能跨域,二是接口信息如果改动,后期接你项目的人需要改你的代码,麻烦。
    • 不方便控制输出。为了让首屏加载速度快一点,我们期望后端先吐出一点数据,剩下的才去 ajax 渲染,但让后端吐出多少数据,我们不好控。

    当然,存在的问题远不止上面枚举的这些,这种传统的方式实在是不酷(Kimi 附身^_^)。还有一种开发流程,SPA(single page application),前后端职责相当清晰,后端给我接口,我全部用 ajax 异步请求,这种方式,在现代浏览器中可以使用 PJAX 稍微提高体验,Facebook 早在三四年前对这种 SPA 的模式提出了一套解决方案,quickling+bigpipe,解决了 SEO 以及数据吐出过慢的问题。他的缺点也是十分明显的:

    • 页面太重,前端渲染工作量也大
    • 首屏还是慢
    • 前后端模板复用不了
    • SEO 依然很狗血(quickling 架构成本高)
    • history 管理麻烦

    问题多的已经是无力吐槽了,当然他依然有自己的优势,咱们也不能一票否决。

    针对上面看到的问题,现在也有一些团队在尝试前后端之间加一个中间层(比如淘宝UED的 MidWay )。这个中间层由前端来控制。

    JavaScript

    +----------------+ | F2E | +---↑--------↑---+ | | +---↓--------↓---+ | Middle | +---↑--------↑---+ | | +---↓--------↓---+ | R2E | +----------------+

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
        +----------------+
        |       F2E      |
        +---↑--------↑---+
            |        |
        +---↓--------↓---+
        |     Middle     |
        +---↑--------↑---+
            |        |  
        +---↓--------↓---+
        |       R2E      |
        +----------------+

    中间层的作用就是为了更好的控制数据的输出,如果用MVC模型去分析这个接口,R2E(后端)只负责 M(数据) 这部分,Middle(中间层)处理数据的呈现(包括 V 和 C)。淘宝UED有很多类似的文章,这里不赘述。

    写在前面

    一直非常谷歌的控制台,因为我是做前端的,谷歌浏览器在我看来是解析JS最快的浏览器,所谓的熟能生巧,用熟悉了谷歌浏览器之后就特别喜欢用谷歌的控制台调试脚本、改变样式、查看HTML、查看资源加载等信息。

    在这儿推荐两篇关于谷歌控制台怎么使用的三篇博文(在我看来这三篇博文是我看过介绍谷歌控制台最佳最全的使用手册啦)

    Chrome 控制台不完全指南

    Chrome 控制台console的用法

    Chrome控制台如何调试JavaScript

    二、核心问题

    上面提出了在业务中看到的常见的三种模式,问题的核心就是数据交给谁去处理。数据交给后台处理,这是模式一,数据交给前端处理,这是模式二,数据交给前端分层处理,这是模式三。三种模式没有优劣之分,其使用还是得看具体场景。

    既然都是数据的问题,数据从哪里来?这个问题又回到了接口。

    • 接口文档由谁来撰写和维护?
    • 接口信息的改动如何向前后端传递?
    • 如何根据接口规范拿到前后端可用的测试数据?
    • 使用哪种接口?JSON,JSONP?
    • JSONP 的安全性问题如何处理?

    这一系列的问题一直困扰着奋战在前线的前端工程师和后端开发者。淘宝团队做了两套接口文档的维护工具,IMS以及DIP,不知道有没有对外开放,两个东西都是基于 JSON Schema 的一个尝试,各有优劣。JSON Schema 是对 JSON 的一个规范,类似我们在数据库中创建表一样,对每个字段做一些限制,这里也是一样的原理,可以对字段进行描述,设置类型,限制字段属性等。

    接口文档这个事情,使用 JSON Schema 可以自动化生产,所以只需编写 JSON Schema 而不存在维护问题,在写好的 Schema 中多加些限制性的参数,我们就可以直接根据 Schema 生成 mock(测试) 数据。

    mock 数据的外部调用,这倒是很好处理:

    JavaScript

    typeof callback === "function" && callback({ json: "jsonContent" })

    1
    2
    3
    typeof callback === "function" && callback({
       json: "jsonContent"
    })

    在请求的参数中加入 callback 参数,如 /mock/hashString?cb=callback,一般的 io(ajax) 库都对异步数据获取做了封装,我们在测试的时候使用 jsonp,回头上线,将 dataType 改成 json 就行了。

    JavaScript

    IO({ url: "", dataType: "jsonp", //json success: function(){} })

    1
    2
    3
    4
    5
    IO({
      url: "http://barretlee.com",
      dataType: "jsonp", //json
      success: function(){}
    })

    这里略微麻烦的是 POST 方法,jsonp 只能使用 get 方式插入 script 节点去请求数据,但是 POST,只能呵呵了。

    这里的处理也有多重方式可以参考:

    • 修改 Hosts,让 mock 的域名指向开发域名
    • mock 设置 header 响应头,Access-Allow-Origin-Control

    对于如何拿到跨域的接口信息,我也给出几个参考方案:

    • fiddler 替换包,好像是支持正则的,感兴趣的可以研究下(求分享研究结果,因为我没找到正则的设置位置)
    • 使用 HTTPX 或者其他代理工具,原理和 fiddler 类似,不过可视化效果(体验)要好很多,毕竟人家是专门做代理用的。
    • 自己写一段脚本代理,也就是本地开一个代理服务器,这里需要考虑端口的占用问题。其实我不推荐监听端口,一个比较不错的方案是本地请求全部指向一个脚本文件,然后脚本转发URL,如:

    JavaScript

    原始请求: 在ajax请求的时候: $.ajax({ url: "" });

    1
    2
    3
    4
    5
    原始请求:http://barretlee.com/api/test.json
    在ajax请求的时候:
    $.ajax({
      url: "http://<local>/api.php?path=/api/text.json"
    });
    • php中处理就比较简单啦:

    JavaScript

    if(!isset($_GET["page"])){ echo 0; exit(); } echo file_get_contents($_GET["path"]);

    1
    2
    3
    4
    5
    if(!isset($_GET["page"])){
      echo 0;
      exit();
    }
    echo file_get_contents($_GET["path"]);
    • Ctrl+S,保存把线上的接口数据到本地的api文件夹吧-_-||

    进入正题

    我这篇文章可不是想介绍Chrome控制台,做前端最重要的就是要保持各个浏览器兼容,即使Chrome控制台很强大,但你能保证你的所有用户都能像你一样是Chrome的忠实粉丝吗?况且IE浏览器在中国市场上的占据份额那也是相当大的一部分的。

    在此介绍一下IE开发人员工具(在没熟悉使用IE开发人员工具之前,我是打心底里特别讨厌IE的,熟悉使用之后才发现原来IE开发人员工具也是蛮可爱的)

    其实从这件事情之后得到一个结论,不要议论任何人或者任何事不好,要怪只能怪你不懂。对万事万物还是怀着一颗宽容博大的心能让自己活得洒脱幸福些。(这是费话,大家跳过不看)

    三、小结

    本文只是对前后端协作存在的问题和现有的几种常见模式做了简要的列举,JSON Schema 具体如何去运用,还有接口的维护问题、接口信息的获取问题没有具体阐述,这个后续有时间会整理下我对他的理解。

    赞 2 收藏 1 评论

    图片 9

    简单介绍

    像Chrome控制台一样,要打开IE开发人员工具也是按快捷键F12即可。

    可以看到,在主工作区中有六个选项卡—-HTML、CSS、控制台、Javascript(脚本)、Profiler(探查器)、网络。这就是开发工作的主要环境。

    1、HTML是默认的选项卡,网页的源代码就以DOM树的形式在其中展示。点击最左边的+号,可以展开/收缩该DOM元素。

    2、CSS选项卡主要是列出页面的样式,如果当前页面有多个外部样式表的话,则可以从下拉选择框中进行选择来查看相应的样式文件。

    3、控制台选项卡主要是方便开发人员进行日志记录或者脚本调试等(现在IE9也支持console.log 不信你在下方的文本框里面输入试试),当然你也可以在里面输入多行脚本然后点击右侧的小绿色按钮(绿色按钮叫运行脚本)

    图片 10

    4、脚本选项卡就不多说了,主要是方便开发人员进行脚本调试。(在下文中将会介绍如何进行脚本调试)

    5、探查器选项卡主要用来进行脚本调优和脚本统计等功能,它列出Javascript脚本中每一个函数、每一个命令运行的次数和所花费的时间,很有助于找出网页代码的性能瓶颈。

    6、网络选项卡一般用来查看资源的加载信息

    本文由奥门新浦京网址发布于Wed前段,转载请注明出处:如何调试Javascript,IE开发者工具教程

    关键词:

上一篇:没有了

下一篇:没有了