摘要:和并不是一個標準的屬性,才是,所以火狐長久以來都不支持,同時也不支持。
這個系列保持開坑不埋的狀態(tài)已經過去三個月了,而在這幾個月中我才算第一次認真地深入理解js。雖然期間筆記是記了不少,但寫博文又不應是簡單的復制粘貼,還是得保證有討論價值、有干貨的。而我面對的現(xiàn)實是:一來基礎差導致識別和撈出有討論價值的干貨得自身功夫練到一定階段,二來又因為記的雜亂且缺乏日常整理,整理一下就是拖一下,再加上開學前后各種雜事層出不窮,所以這坑就一直留著。
但填坑是必須的,在深入學習的過程中,我意識到的最重要一點是:不能再攤大餅式地沒總結就向前跑了,學習得是個分階段上升的過程,而每個階段又是理論和實踐的交替往復,這樣才有動力和能力去朝技術之巔進發(fā)。所以今天我就來總結一下學習js中一些探究過的點,與大家分享:
script標簽的async、defer屬性script標簽除了有常見的type屬性外,還有兩個比較實用的屬性async、defer。我們在需要使用無阻塞下載、執(zhí)行的外部腳本、實現(xiàn)性能優(yōu)化時往往要用到這兩個屬性。他們具體的作用如下:
使用async="async":異步下載外部腳本,腳本一下載完就執(zhí)行,在先于load事件任何地方都可能執(zhí)行
不使用 async 且 defer="defer":異步下載外部腳本,腳本將在頁面完成解析時順序執(zhí)行,理論上先于DOMContentLoad事件執(zhí)行
不使用這兩屬性:下載外部腳本時會阻塞,腳本一下載完就執(zhí)行
就這個內容,我寫了個小demo,分析其運行結果,就執(zhí)行順序來講,帶async、defer屬性的腳本較慢執(zhí)行,不管原來script標簽的使用順序,確實異步了;而用defer屬性或者兩者都沒使用的腳本內部也確實是按順序執(zhí)行的。至于下載腳本的過程,我暫時沒想到測試方法,只能先擱一邊了。
當然,就加載和性能優(yōu)化來講,這兩個屬性只是一方面而已,若有興趣可看這篇較詳細的介紹。
parseInt()和parseFloat()的一些特性由于Number()函數(shù)在進行字符串向Number類型轉換時存在一些坑(比如Number("")返回的是0),parseInt()和parseFloat()這兩個函數(shù)是專門用來替代Number()函數(shù)實現(xiàn)字符串向Number類型的轉換的。兩者間對比的一些要點:
要點 | parseInt() | parseFloat() |
---|---|---|
1.解析過程 | 忽略串前空格符,找到第一個非空格字符 | 忽略串前空格符,找到第一個非空格字符 |
--- | ↓數(shù)字或負號? | ↓數(shù)字或負號? |
--- | Y:解析至字符串結束或遇到非數(shù)字字符,返回整數(shù); N:返回NaN |
Y:解析至字符串結束或遇到無效浮點字符(多個小數(shù)點或非數(shù)字),可解析為整數(shù)則返回整數(shù)返回整數(shù),否則返回浮點數(shù); N:返回NaN |
2.進制識別與轉換 | 支持(8進制在ES5中會忽略前導0而變?yōu)槭M制) | 不支持(忽略所有前導0,十六進制數(shù)被識別為0) |
3.采用第二參數(shù)指定基數(shù) | 有(指定基數(shù)后原串不加數(shù)制前綴也可順利轉換) | 沒有,只支持十進制 |
這里面順便注意下js的一個坑---parseInt(0.000001)返回的是0,但parseInt(0.0000001)卻會返回1。
其實這個坑不在于parseInt()本身,而在于js一個將小于1e-6的數(shù)自動轉為科學計數(shù)法表示的規(guī)定,比如0.0000001會自動表示為1e-7。
可以看到,parseInt(0.0000001)的過程涉及兩次轉換,首先參數(shù)為Number類型將調用toString()變?yōu)樽址?.000001會變成"1e-7"。其次便是將字符串轉化為數(shù)字,根據前面提到的parseInt()的解析過程,自然就出現(xiàn)了那個返回1的坑爹結果。
NaN是js里一個奇特的存在,有著既是Number類型卻并不是一個數(shù)、自己不等于自己等奇葩特點。如果不清楚什么情況下NaN會出現(xiàn),冷不防就會對執(zhí)行結果判斷錯誤。其實NaN的出現(xiàn)還是有點規(guī)律的,如下所示:
除了!NaN外的其他含有NaN的操作
無法得出結果的運算:Infinity*0、0/0、Infinity-Infinity、Infinity除以任何數(shù)···
其他類型轉換為數(shù)字時失敗,如Number("abc")
除了NaN,Infinity也是個特殊的Number類型,當它和0糾葛在一起乘除取余時,結果表面看起來也有點迷:
demo
其實這里面相乘的最容易理解,而有一點基本的極限知識都知道1/0==Infinity、1/Infinity==0,把除看成乘也容易理解了。相除的理解、剩下的取余也就自然明了。
innerText和textContentinnerText并不是一個標準的屬性,textContent才是,所以火狐長久以來都不支持innerText,同時IE<9也不支持textContent。當然這兩者也不是完全相同,區(qū)別在于讀取屬性時,innerText不返回隱藏元素的文本,而textContent返回所有文本(如元素文本里的換行符)。
至于選用哪個的問題,我覺得不要求兼容低版本IE的話,就直接用textContent,如果不希望獲得隱藏的文本,則后期再根據獲取的字符串進行修改。
Date()類型的使用看起來簡單,比如創(chuàng)建Date對象:
var d = new Date(年, 月, 日, 時, 分, 秒, 毫秒)/(時間戳)/(標準時間格式字符串);
但真要細究起來其內部的細碎之處也是叫人蛋疼,就上面三種傳參方法,有這些區(qū)別:
時間參數(shù):各瀏覽器都以當前時區(qū)返回日期對象,此處月份范圍用整數(shù)表示是0~11
時間戳:各瀏覽器都以0時區(qū)返回日期對象
標準時間格式字符串:
RFC2822時間字符串:"YYYY+:MMM:DD+ HH+:MM+:SS+"+"Z或±HH:MM","YYYY/MM/DD HH:MM:SS"+"Z或±HH:MM" ,沒加Z(零時區(qū))或時區(qū)標志時各瀏覽器以當前時區(qū)返回日期對象
ISO 8601時間字符串:"YYYY-MM-DDTHH:MM:SS.mmm"+"Z或±HH:MM",chrome傳參寬松而FF和IE嚴格按順序和大小寫,chrome會全部以0時區(qū)返回日期對象而FF和IE在加了HH:MM:SS后以按當前時區(qū)返回日期對象
我認為一味死摳沒多少營養(yǎng)的細枝末節(jié)就是在浪費時間、降低效率,而看到這樣一個創(chuàng)建對象的操作就包含這么多瑣碎的東西,再死摳下去也是蠻無聊的,但還好已經有人寫了個關于Date冷知識的全面總結了,我就不重復在這上面勞神費力了。
其他在FF和chrome下使用firstChild,lastChild,nextSibling,previousSibling四個屬性時,會把標簽之間的空格當成文本節(jié)點影響節(jié)點的獲取,而在IE9以下的瀏覽器中卻可正常獲取。還是那句話,既然IE9之后大家都情況統(tǒng)一了,以后就不用考慮這點小兼容,全都乖乖用firstElementChild,lastElementChild,nextElementSibling,previousElementSibling這幾個可靠的替代吧
將數(shù)組轉化為字符串時可用join()方法代替toString(),因為這樣寫可以自定義分隔符
getElementById()只能通過document調用,而不能通過其他DOM節(jié)點對象
一點感想這次“重新”投入js學習,先是在暑假的開發(fā)中找教程從頭看起,輔以一些小實踐,也算讓自己一直單薄許久的js知識有了些飛躍;但如果說以前我是站在js門外觀望、走馬觀花,那現(xiàn)在也只是一只腳剛伸進門檻而已,在這個行業(yè)劇烈變換的今天,在node、angular、react等正式風生水起時,我既是為身處時代洪流感到興奮,又不免感慨任重道遠。參照別人的學習之路,再考慮自己的實際,接下來要做的還有許多。而現(xiàn)在大學過了一半了,出了這校門,大段的、連續(xù)的用來學習和自我提升的日子怕也是很難再有了吧;那么大三應是鑄造堅實基礎、或者說讓自己跨進“專業(yè)人士”行列的重要階段了,前路漫漫,待我渡之。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/86146.html
閱讀 3077·2019-08-30 15:56
閱讀 1234·2019-08-29 15:20
閱讀 1571·2019-08-29 13:19
閱讀 1473·2019-08-29 13:10
閱讀 3381·2019-08-26 18:27
閱讀 3069·2019-08-26 11:46
閱讀 2234·2019-08-26 11:45
閱讀 3753·2019-08-26 10:12