当array含有NaN的时候，sort时需要考虑NaN的对比
在对["1","2","3"...]做sort的时候，由于自己写的comparator，里面在对string做parseInt的时候，没有考虑NaN的情况，所以通过parseInt(a)>parseInt(b)进行对比的时候，就会出现错乱。同时发现NaN和数字比较都会返回false。比如NaN>3返回false,NaN<3也返回false
parseInt会出现坑
由上面的问题我跟群里的大神聊天的时候，他们已经不建议使用parseInt了，会有很多坑。比如parseInt(0.000000004)会返回4，而不是0。大神们建议使用Number(string),+numString的方法进行转换。
n转换为换行符的时候，注意使用n来匹配
针对一个在页面上显示出来的string: "stringstringnstringstring"，虽然显示的是"n"，但通过string.indexOf("n")就是获取不到。后来想明白了，其实中间的string.indexOf("n")就有了。做replace的时候也是要这样string.replace(/n/g,"n")
isNaN(null)返回false
isNaN会先通过Number(arg)转换后来进行判断。所以isNaN(null)返回的是false，isNaN(undefined)返回的是true。也就是说，如果在判断一个对象是不是number，不能单纯的只用isNaN来判断。
可以考虑使用来进行判断：
value = +value; // 强制string转化为number
typeof value === "number" && isNaN(value);
内存泄漏
之前在一个里面，聊到内存泄漏，mcfog是这么回答的：关于内存泄漏，理想的情况是：1)dom元素增加属性，所以就算去掉事件监听，这个属性也不会被释放 2)闭包是待在事件监听器上的，所以去掉时间监听就能释放掉对应的内存，所以如果后续存在只去除事件而不移除dom节点的情况，2好一点； 实际情况是浏览器的gc各种浏览器实现不同策略不同，要到具体的浏览器里构造极端case去试；更实际的情况是由于只是个整数，这点内存比起一个完整dom节点的占用小太多，并且如果这个数量真的多到需要考虑内存泄露的数量级，那先崩溃的也是dom树(的性能)，所以其实不用关心这两种写法的内存问题
React.setState不保证同步的
在setState中，他并不一定是同步的，也不一定是异步的。可以看一下自己的文章，里面有一个连接中讲了一个例子，在不同种类的事件中，setState同步/异步的情况也不同。但是作为开发，倾向于以异步来操作setState，可以避免不必要的问题。 （编辑：李大同）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
