前端碎語（2）

FrancisSoung 發(fā)布于2019-08-21 10:46 / 3590人閱讀

摘要：和并不是一個(gè)標(biāo)準(zhǔn)的屬性，才是，所以火狐長(zhǎng)久以來都不支持，同時(shí)也不支持。

這個(gè)系列保持開坑不埋的狀態(tài)已經(jīng)過去三個(gè)月了，而在這幾個(gè)月中我才算第一次認(rèn)真地深入理解js。雖然期間筆記是記了不少，但寫博文又不應(yīng)是簡(jiǎn)單的復(fù)制粘貼，還是得保證有討論價(jià)值、有干貨的。而我面對(duì)的現(xiàn)實(shí)是：一來基礎(chǔ)差導(dǎo)致識(shí)別和撈出有討論價(jià)值的干貨得自身功夫練到一定階段，二來又因?yàn)橛浀碾s亂且缺乏日常整理，整理一下就是拖一下，再加上開學(xué)前后各種雜事層出不窮，所以這坑就一直留著。

但填坑是必須的，在深入學(xué)習(xí)的過程中，我意識(shí)到的最重要一點(diǎn)是：不能再攤大餅式地沒總結(jié)就向前跑了，學(xué)習(xí)得是個(gè)分階段上升的過程，而每個(gè)階段又是理論和實(shí)踐的交替往復(fù)，這樣才有動(dòng)力和能力去朝技術(shù)之巔進(jìn)發(fā)。所以今天我就來總結(jié)一下學(xué)習(xí)js中一些探究過的點(diǎn)，與大家分享：

script標(biāo)簽的async、defer屬性

script標(biāo)簽除了有常見的type屬性外，還有兩個(gè)比較實(shí)用的屬性async、defer。我們?cè)谛枰褂脽o阻塞下載、執(zhí)行的外部腳本、實(shí)現(xiàn)性能優(yōu)化時(shí)往往要用到這兩個(gè)屬性。他們具體的作用如下：

使用async="async"：異步下載外部腳本，腳本一下載完就執(zhí)行，在先于load事件任何地方都可能執(zhí)行

不使用 async 且 defer="defer"：異步下載外部腳本，腳本將在頁面完成解析時(shí)順序執(zhí)行，理論上先于DOMContentLoad事件執(zhí)行

不使用這兩屬性：下載外部腳本時(shí)會(huì)阻塞，腳本一下載完就執(zhí)行

就這個(gè)內(nèi)容，我寫了個(gè)小demo，分析其運(yùn)行結(jié)果，就執(zhí)行順序來講，帶async、defer屬性的腳本較慢執(zhí)行，不管原來script標(biāo)簽的使用順序，確實(shí)異步了；而用defer屬性或者兩者都沒使用的腳本內(nèi)部也確實(shí)是按順序執(zhí)行的。至于下載腳本的過程，我暫時(shí)沒想到測(cè)試方法，只能先擱一邊了。

當(dāng)然，就加載和性能優(yōu)化來講，這兩個(gè)屬性只是一方面而已，若有興趣可看這篇較詳細(xì)的介紹。

parseInt()和parseFloat()的一些特性

由于Number()函數(shù)在進(jìn)行字符串向Number類型轉(zhuǎn)換時(shí)存在一些坑（比如Number("")返回的是0），parseInt()和parseFloat()這兩個(gè)函數(shù)是專門用來替代Number()函數(shù)實(shí)現(xiàn)字符串向Number類型的轉(zhuǎn)換的。兩者間對(duì)比的一些要點(diǎn)：

要點(diǎn)	parseInt()	parseFloat()
1.解析過程	忽略串前空格符，找到第一個(gè)非空格字符	忽略串前空格符，找到第一個(gè)非空格字符
---	↓數(shù)字或負(fù)號(hào)？	↓數(shù)字或負(fù)號(hào)？
---	Y：解析至字符串結(jié)束或遇到非數(shù)字字符，返回整數(shù)； N：返回NaN	Y：解析至字符串結(jié)束或遇到無效浮點(diǎn)字符（多個(gè)小數(shù)點(diǎn)或非數(shù)字），可解析為整數(shù)則返回整數(shù)返回整數(shù)，否則返回浮點(diǎn)數(shù)； N：返回NaN
2.進(jìn)制識(shí)別與轉(zhuǎn)換	支持（8進(jìn)制在ES5中會(huì)忽略前導(dǎo)0而變?yōu)槭M(jìn)制）	不支持（忽略所有前導(dǎo)0，十六進(jìn)制數(shù)被識(shí)別為0）
3.采用第二參數(shù)指定基數(shù)	有（指定基數(shù)后原串不加數(shù)制前綴也可順利轉(zhuǎn)換）	沒有，只支持十進(jìn)制

這里面順便注意下js的一個(gè)坑---parseInt(0.000001)返回的是0，但parseInt(0.0000001)卻會(huì)返回1。
其實(shí)這個(gè)坑不在于parseInt()本身，而在于js一個(gè)將小于1e-6的數(shù)自動(dòng)轉(zhuǎn)為科學(xué)計(jì)數(shù)法表示的規(guī)定，比如0.0000001會(huì)自動(dòng)表示為1e-7。
可以看到，parseInt(0.0000001)的過程涉及兩次轉(zhuǎn)換，首先參數(shù)為Number類型將調(diào)用toString()變?yōu)樽址?.000001會(huì)變成"1e-7"。其次便是將字符串轉(zhuǎn)化為數(shù)字，根據(jù)前面提到的parseInt()的解析過程，自然就出現(xiàn)了那個(gè)返回1的坑爹結(jié)果。

摳一下NaN和Infinity的細(xì)節(jié)

NaN是js里一個(gè)奇特的存在，有著既是Number類型卻并不是一個(gè)數(shù)、自己不等于自己等奇葩特點(diǎn)。如果不清楚什么情況下NaN會(huì)出現(xiàn)，冷不防就會(huì)對(duì)執(zhí)行結(jié)果判斷錯(cuò)誤。其實(shí)NaN的出現(xiàn)還是有點(diǎn)規(guī)律的，如下所示：

除了!NaN外的其他含有NaN的操作

無法得出結(jié)果的運(yùn)算：Infinity*0、0/0、Infinity-Infinity、Infinity除以任何數(shù)···

其他類型轉(zhuǎn)換為數(shù)字時(shí)失敗，如Number("abc")

除了NaN，Infinity也是個(gè)特殊的Number類型，當(dāng)它和0糾葛在一起乘除取余時(shí)，結(jié)果表面看起來也有點(diǎn)迷：

demo

其實(shí)這里面相乘的最容易理解，而有一點(diǎn)基本的極限知識(shí)都知道1/0==Infinity、1/Infinity==0，把除看成乘也容易理解了。相除的理解、剩下的取余也就自然明了。

innerText和textContent

innerText并不是一個(gè)標(biāo)準(zhǔn)的屬性，textContent才是，所以火狐長(zhǎng)久以來都不支持innerText，同時(shí)IE<9也不支持textContent。當(dāng)然這兩者也不是完全相同，區(qū)別在于讀取屬性時(shí)，innerText不返回隱藏元素的文本，而textContent返回所有文本（如元素文本里的換行符）。
至于選用哪個(gè)的問題，我覺得不要求兼容低版本IE的話，就直接用textContent，如果不希望獲得隱藏的文本，則后期再根據(jù)獲取的字符串進(jìn)行修改。

關(guān)于原生的Date()

Date()類型的使用看起來簡(jiǎn)單，比如創(chuàng)建Date對(duì)象：
var d = new Date(年, 月, 日, 時(shí), 分, 秒, 毫秒)/(時(shí)間戳)/(標(biāo)準(zhǔn)時(shí)間格式字符串);
但真要細(xì)究起來其內(nèi)部的細(xì)碎之處也是叫人蛋疼，就上面三種傳參方法，有這些區(qū)別：

時(shí)間參數(shù)：各瀏覽器都以當(dāng)前時(shí)區(qū)返回日期對(duì)象，此處月份范圍用整數(shù)表示是0~11

時(shí)間戳：各瀏覽器都以0時(shí)區(qū)返回日期對(duì)象

標(biāo)準(zhǔn)時(shí)間格式字符串:
RFC2822時(shí)間字符串："YYYY+:MMM:DD+ HH+:MM+:SS+"+"Z或±HH:MM"，"YYYY/MM/DD HH:MM:SS"+"Z或±HH:MM" ，沒加Z（零時(shí)區(qū)）或時(shí)區(qū)標(biāo)志時(shí)各瀏覽器以當(dāng)前時(shí)區(qū)返回日期對(duì)象

ISO 8601時(shí)間字符串："YYYY-MM-DDTHH:MM:SS.mmm"+"Z或±HH:MM"，chrome傳參寬松而FF和IE嚴(yán)格按順序和大小寫，chrome會(huì)全部以0時(shí)區(qū)返回日期對(duì)象而FF和IE在加了HH:MM:SS后以按當(dāng)前時(shí)區(qū)返回日期對(duì)象

我認(rèn)為一味死摳沒多少營(yíng)養(yǎng)的細(xì)枝末節(jié)就是在浪費(fèi)時(shí)間、降低效率，而看到這樣一個(gè)創(chuàng)建對(duì)象的操作就包含這么多瑣碎的東西，再死摳下去也是蠻無聊的，但還好已經(jīng)有人寫了個(gè)關(guān)于Date冷知識(shí)的全面總結(jié)了，我就不重復(fù)在這上面勞神費(fèi)力了。

其他

在FF和chrome下使用firstChild,lastChild,nextSibling,previousSibling四個(gè)屬性時(shí)，會(huì)把標(biāo)簽之間的空格當(dāng)成文本節(jié)點(diǎn)影響節(jié)點(diǎn)的獲取，而在IE9以下的瀏覽器中卻可正常獲取。還是那句話，既然IE9之后大家都情況統(tǒng)一了，以后就不用考慮這點(diǎn)小兼容，全都乖乖用firstElementChild,lastElementChild,nextElementSibling,previousElementSibling這幾個(gè)可靠的替代吧

將數(shù)組轉(zhuǎn)化為字符串時(shí)可用join()方法代替toString()，因?yàn)檫@樣寫可以自定義分隔符

getElementById()只能通過document調(diào)用，而不能通過其他DOM節(jié)點(diǎn)對(duì)象

一點(diǎn)感想

這次“重新”投入js學(xué)習(xí)，先是在暑假的開發(fā)中找教程從頭看起，輔以一些小實(shí)踐，也算讓自己一直單薄許久的js知識(shí)有了些飛躍；但如果說以前我是站在js門外觀望、走馬觀花，那現(xiàn)在也只是一只腳剛伸進(jìn)門檻而已，在這個(gè)行業(yè)劇烈變換的今天，在node、angular、react等正式風(fēng)生水起時(shí)，我既是為身處時(shí)代洪流感到興奮，又不免感慨任重道遠(yuǎn)。參照別人的學(xué)習(xí)之路，再考慮自己的實(shí)際，接下來要做的還有許多。而現(xiàn)在大學(xué)過了一半了，出了這校門，大段的、連續(xù)的用來學(xué)習(xí)和自我提升的日子怕也是很難再有了吧；那么大三應(yīng)是鑄造堅(jiān)實(shí)基礎(chǔ)、或者說讓自己跨進(jìn)“專業(yè)人士”行列的重要階段了，前路漫漫，待我渡之。