从一次重写原生方法遇到的坑,总结一下Web中的事件系统

2019-01-14 admin

写在前面

前段时间,我写过一篇文章前端开发中的Error以及异常捕获。 在文章中,我提到了这个问题:

clipboard.png

经过不断探索(不想再喷自己了),我找到了原因。下面一一道来。本文主要讲解自己找问题原因的思路,如果想看结论和总结,请直接跳到文末。

问题复现

我是在自己以前的项目中测试addEventListener的重写的。这里直接上精简后的问题代码:

import React from 'react';
import ReactDOM from 'react-dom';

const nativeAddEventListener = EventTarget.prototype.addEventListener;
EventTarget.prototype.addEventListener = function (type, func, options) {
    const wrappedFunc = function (...args) {
        try {
             return func.apply(this, args);
        } catch (e) {
             const errorObj = {
                 error_msg: e.message || '',
                 error_stack: e.stack || (e.error && e.error.
                 error_native: e
             };
        }
    }
    return self.nativeAddEventListener.call(this, type, wrappedFunc, options);
};

const App = function() {
    return <div>11111</div>
};

ReactDOM.render(<App/>, document.body);

运行这段代码,浏览器上一片空白,但是却没有任何报错。我一脸懵逼。

clipboard.png

问题初探索

删掉那一点重写addEventListener的代码后,表现符合预期了。应该是重写那儿的问题。但是仔细看了过后,那段代码并没有什么问题。并且这段代码我在其他地方也试过,表现一直是正常的。是不是和React哪里冲突了?我使用的React版本是 clipboard.png 我搜索了react-dom源码中的addEventListener关键字,总共出现了四次。初步看了一下,并没有什么问题,只是注册了一些事件而已。没有具体分析这些代码的含义,我选择了先更换React的版本试一试,于是,我换成了15.6.2的版本。令人吃惊的是,表现符合预期了。难道真的和React的版本有关系? 在我的认知中,两个版本中最大的不同就是:React v16采用了全新的Fiber架构,而我对Fiber的理解大概就是:重新设计了react node的数据结构,模拟实现了自己的任务堆栈,结合时间分片来进行任务的调度,从而更新整个系统。另外,React有自己的一套任务系统,addEventListener和任务也是紧密相关的,难道影响到了这个?

继续探索

我决定从ReactDOM.render()这个方法入手,调试一下ReactDOM的源代码。之前并没有研究过React的源码,压力有点大。调试了一翻之后,我并没有发现什么问题,并且已经有点懵逼了。我准备同时调试react v15react v16的代码,看看有什么不同。为了方便,我将问题代码全部抽了出来,全部写到了一个html文件中,并且直接引用React的cdn地址。这个时候,我发现了一个神奇的问题:直接引用cdn地址后,不管React是什么版本,就算是v16版本,也不会出现之前问题,表现都是符合预期的。我更加懵逼了。

图片描述

发现问题

静下心来仔细观察后,我发现了,我cdn引用的都是reactproduction版本,而我在项目中使用的react代码,却是development版本的,难道是developmentproduction的diff代码,导致了上面的问题。于是我重新仔细看了一下v16development的代码,找到了代码中一段长长的注释:

clipboard.png

大意就是:在开发版本中,react不会采用try{}catch(){}的方式来捕获错误,而是会把所有开发者定义的callback用一个叫做invokeGuardedCallback的函数包裹起来,然后使用一个假的dom,监听、触发自定义事件来执行invokeGuardedCallback,并且通过一个全局的错误捕捉函数来捕获错误。

在这段注释的下面,就是注释中提到的invokeGuardedCallback的代码。

我仔细研究了这个invokeGuardedCallback的代码,其核心就是:

function invokeGuardedCallback(name, func, context, a, b, c, d, e, f){
     ...
     var fakeNode = document.createElement('react');
     var evt = document.createEvent('Event');
     var evtType = 'react-' + (name ? name : 'invokeguardedcallback');
     var callCallback = function(){
        ...
        fakeNode.removeEventListener(evtType, callCallback, false); // 这里很重要!!!
        ...
        func.apply(context, funcArgs); // 这里是真正执行react中的逻辑代码
     } 
     fakeNode.addEventListener(evtType, callCallback, false);
     evt.initEvent(evtType, false, false);
     fakeNode.dispatchEvent(evt);
     ...
}

react将所有容易出错的函数,都用这个invokeGuardedCallback包了起来。每一次都重新造一个虚拟的element,然后监听其自定义事件,并且立即触发这个自定义事件。调试了这个invokeGuardedCallback后,我发现在react v16中,发现很多函数被多次执行。 为什么会多次执行呢? 终于,我找到了问题的原因:

我重写了addEventListener, 在函数外包了一层try{}catch(){},返回的是一个新的函数,所以,最终注册在事件监听器上的,并不是我传入的那个函数。这个时候,调用removeEventListener时,无法移除我传入addEventListener的函数。

invokeGuardedCallback中,removeEventListener的逻辑相当于并没有生效。于是,在Fiber的调度中,某个函数被多次重复执行了,而被重复执行的函数并不是幂等的,问题便产生了。

问题的总结与思考

问题终于定位了,一句总结,就是:

重写了addEventListener,却并没有考虑到与之对应的removeEventListener,导致removeEventListener无法正常工作。

下面是一些思考:

  1. 一开始,如果我仔细看一下react源码中addEventListener周围的代码,或许能更早发现这个问题,就不用绕这么大一个圈了。
  2. 自己对于第三方库的development版本和production版本,并没有一个很强烈的认知、意识,以前上线的不少项目,线上竟然还是用的第三方库的development版本,这个毛病,一定得改掉。
  3. 分析问题的能力还很欠缺,不够敏感。考虑问题的全面性需要提高。
  4. 真的不要随便重写原生方法。。。

写在后面

在探索这个问题的过程中,我看到了react巧妙应用自定义事件来捕获错误。于是,我全面总结一下了Web中的事件系统,也算是对基础的巩固。由于篇幅已经不够了,这里就直接放文章链接吧:

谈一谈web中的事件 谈一谈web中的事件


欢迎关注我的公众号: 符合预期的CoyPan, 这里只有干货,符合你的预期。 图片描述

[转载]原文链接:https://segmentfault.com/a/1190000017877422

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处。

转载请注明:文章转载自 JavaScript中文网 [https://www.javascriptcn.com]

本文地址:https://www.javascriptcn.com/read-50909.html

文章标题:从一次重写原生方法遇到的坑,总结一下Web中的事件系统

相关文章
从2014年的发展来展望JS的未来将会如何
&lt;font face=&quot;寰�杞�闆呴粦, Arial, sans-serif &quot;&gt;2014骞达紝杞�浠惰�屼笟鍙戝睍杩呴€燂紝鍚勭�嶈��瑷€灞傚嚭涓嶇┓锛屼互婊¤冻鐢ㄦ埛涓嶆柇鍙樺寲鐨勯渶姹傘€傝繖浜涜��...
2015-11-12
12个你未必知道的CSS小知识
虽然CSS并不是一种很复杂的技术,但就算你是一个使用CSS多年的高手,仍然会有很多CSS用法/属性/属性值你从来没使用过,甚至从来没听说过。 1.CSS的color属性并非只能用于文本显示 对于CSS的color属性,相信所有Web开发人员...
2015-11-12
ajax为什么令人惊异?ajax的优缺点
使用Ajax的最大优点,就是能在不更新整个页面的前提下维护数据。这使得Web应用程序更为迅捷地回应用户动作,并避免了在网络上发送那些没有改变的信息。 Ajax不需要任何浏览器插件,但需要用户允许JavaScript在浏览器上执行。就像DHT...
2015-11-12
破解前端面试(80% 应聘者不及格系列):从 闭包说起
不起眼的开始 招聘前端工程师,尤其是中高级前端工程师,扎实的 JS 基础绝对是必要条件,基础不扎实的工程师在面对前端开发中的各种问题时大概率会束手无策。在考察候选人 JS 基础的时候,我经常会提供下面这段代码,然后让候选人分析它实际运行的结...
2017-06-02
HTML5的5个不错的开发工具推荐
HTML5规范终于在今年正式定稿,对于从事多年HTML5开发的人员来说绝对是一个重大新闻。数字天堂董事长,DCloud CEO王安也发表了文章,从开发者和用户两个角度分析了HTML对两个人群的优势。其实,关于HTML5的开发工具,我们以往的...
2015-11-12
JavaScript教程:JS中的原型
Keith Peters 几年前发表的一篇博文,关于学习没有“new”的世界,其中解释了使用原型继承代替构造函数。两者都是纯粹的原型编码。 标准方法(The Standard Way) 一直以来,我们学习的在 JavaScript 里创建对...
2015-11-12
v-charts | 饿了么团队开源的基于 Vue 和 ECharts 的图表工具
在使用echarts生成图表时,经常需要做繁琐的数据类型转化、修改复杂的配置项,v-charts的出现正是为了解决这个 痛点。基于Vue2.0和echarts封装的v-charts图表组件,只需要统一提供一种对前后端都友好的数据格式 设置简...
2018-05-24
AJAX的浏览器支持
AJAX 的要点是 XMLHttpRequest 对象。 不同的浏览器创建 XMLHttpRequest 对象的方法是有差异的。 IE 浏览器使用 ActiveXObject,而其他的浏览器使用名为 XMLHttpRequest 的 Jav...
2015-11-12
WebSocket断开原因分析,再也不怕为什么又断开了
阅读原文:https://wdd.js.org/websocket-… 1. 把错误打印出来 WebSocket断开的原因有很多,最好在WebSocket断开时,将错误打印出来。 在线demo地址:https://wdd.js.org/we...
2018-04-25
typeof、instanceof和contructor的区别
typeof:以字符串的形式返回变量的原始类型,typeof在两种情况下会返回&quot;undefined&quot;:一个变量没有被声明的时候,和一个变量的值是undefined的时候,注意,typeof null也会返回object,...
2015-11-12
回到顶部