那些前端工作中遇到的坑(01)

3,158 阅读3分钟

前段时间接手一个老项目(jQuery+React混在一块)的迁移工作,除了用React重写一些老页面(这种至少是自己写的,心里有数,调起来也省心),剩下的就是将原有的React迁到新仓库里,复制!粘贴!改路径!完事!是个体力活。

你以为这样就结束了?一大堆bug在等着,整整改了半个月,虽然都是些小问题,但整天被测试钉来钉去还是蛮头疼的。

现在来说说今天的主角吧,这是一个不起眼的问题,最初发现的时候很让人摸不着头脑。

part one

const res = request(url);
console.log(res);   // { stat: 'ok', data: { value: 1, childs: [1, 2, 3] } }

上面的代码很普通,但是打开控制台的Network去看这个接口的返回结果是:{ stat: 'ok', data: { value: 1, children: [1, 2, 3] } },你没有看错,返回的数据中是children,而console.log打印出来的是childs,是不是很不可思议?接下来我们逐一排查问题。

part two

const res = request(url);
console.log(JSON.stringify(res));   // { stat: 'ok', data: { value: 1, children: [1, 2, 3] } }
console.log(res);   // { stat: 'ok', data: { value: 1, childs: [1, 2, 3] } }

这里我们把res转成字符串再输出,和直接输出对比发现转成字符串后的结果是和接口返回的结果一样的,都是children。看到这里相信有不少小伙伴已经清楚是怎么回事了,但应该也有部分同学脑子里全是问号了(比如当时的我)。

如果光是靠这些线索,确实还没发定位问题。那我们进一步探索,既然出问题的的是res,那就顺藤摸瓜,找到使用他的地方。然后就发现了这段代码:

res.data.children = res.data.childs;
delete res.data.childs;

原来是为了换字段,直接操作了源数据,而对象,数组都是引用类型的,so...

那难道console.log难道是异步执行的吗,不然代码顺序执行的话前面输出的结果应该是对的呀?

这么说其实不准确,我们把同样的代码换个方式执行,比如node.js:

然后跟在浏览器中执行对比一下:

这样就很清晰了,问题在于浏览器控制台的输出机制,但为什么要这么设计呢?在网上查阅了一番后,得出的结论是:如果顺序执行console.log(输出的内容较大,层级较深),可能会造成阻塞,影响用户体验,所以浏览器在后台异步处理了console.log

在某些条件下,某些浏览器的console.log(..) 并不会把传入的内容立即输出。出现这种情况的主要原因是,在许多程序(不只是JavaScript)中,I/O 是非常低速的阻塞部分。所以,(从页面/UI 的角度来说)浏览器在后台异步处理控制台I/O 能够提高性能,这时用户甚至可能根本意识不到其发生。 ---《你不知道的javascript》

而通过JSON.stringify转成字符串再输出相当于给res拍了一次快照(记录了他最初的样子),后面再操作该对象也不会影响到这个字符串(你操作对象关我字符串什么事)。

问题搞清楚了,下面要考虑的就是怎么解决以及以后如何避免。

归根到底就是一句话:

不要操作源数据!

不要操作源数据!

不要操作源数据!

使用之前深拷贝一下,可以使用最简单粗暴的JSON.parse(JSON.stringify(res))

鸡汤:坑踩多了不要紧,反正后面还多着呢