翻譯:瘋狂的技術宅
原文: https://www.valentinog.com/bl...
本文首發微信公衆號:前端先鋒
歡迎關注,天天都給你推送新鮮的前端技術文章javascript
JavaScript 創建在一系列基本單元之上。你應該對其中的一些已經很熟悉了,好比字符串和數字:css
var greet = "Hello"; var year = 89;
字符串和數字是該語言所謂「原語」的一部分。完整清單是:前端
布爾值用來表示多是真或假的值。 null 是故意不去賦值,它一般被分配給一個變量,用於表示綁定完畢,稍後將填充有意義的內容。java
var maybe = null;
而後纔是 undefined,這意味着變量仍然沒有被附加上:python
var name; console.log(name) undefined
null 和 undefined 看起來很是類似,但它們是兩個大相徑庭的實體,不少開發人員仍然不肯定應該使用哪一個。git
若是要判斷 JavaScript 實例的類型,能夠用 typeof
運算符。讓咱們用字符串嘗試一下:程序員
typeof "alex" > "string"
還有數字:github
typeof 9 > "number"
用於布爾值:面試
typeof false > "boolean"
undefined:編程
typeof undefined > "undefined"
還有 null:
typeof null > "object"
結果使人驚訝! null 看起來像一個對象,但實際上它是 JavaScript 中的一個歷史性錯誤,自語言誕生就躺在那裏了。 因爲這些問題,JavaScript 一直聲名狼借。但這僅僅是個開始。
在 JavaScript 中,在兩種類型之間進行轉換時有一些奇怪的規則。讓我給你一些背景信息。先用 Python 舉一個例子。 在 Python 中執行如下指令:
'hello' + 89
會給你一個明確的錯誤:
TypeError: can only concatenate str (**not** "int") to str
而在 JavaScript 中,只有天空纔是你的極限:
'hello' + 89
事實上給出:
"hello89"
若是咱們嘗試向字符串添加數組,看起來會更加奇怪:
'hello' + []
將會獲得
1. 'hello'
還有
1. 'hello' + [89]
會給你一個驚喜:
1. "hello89"
看起來這種轉換背後存在某種邏輯。它甚至適用於存在更多元素的 array :
1. 'hello' + [89, 150.156, 'mike']
獲得:
1. "hello89,150.156,mike"
這兩行 JavaScript 足以讓 Java 程序員逃離。可是這種行爲在 JavaScript 中 100% 是又意義的。所以這種隱式轉換,也稱爲強制類型轉換是很是值得探索的。
一些編程語言有一個叫作類型轉換的概念,這意味着:若是我想把一個數字或實例轉換爲另外一種類型,那麼我必須使顯式轉換。它也適用於 JavaScript。請看如下示例:
var greet = "Hello"; var year = 89;
若是我想明確的進行轉換,能夠在代碼中代表意圖:
var greet = "Hello"; var year = 89; var yearString = year.toString()
要麼這樣作:
var greet = "Hello"; var year = 89; var yearString = String(year)
而後我能夠鏈接兩個變量:
greet + yearString;
可是在 JavaScript 中有一種被稱爲隱式轉換的微妙機制,由 JavaScript 引擎提供。該語言不會阻止咱們對數字和字符串進行加法操做:
'hello' + 89
會獲得:
"hello89"
可是這種轉換背後的邏輯是什麼?你可能會驚訝地發現 JavaScript 中的加法運算符 +
會自動將兩個操做數中的任何一個都轉換爲字符串,若是其中至少有一個是字符串的話!
你會發現更使人驚訝的是,這條規則在ECMAScript規範中一脈相承。 第11.6.1節 定義了加法運算符的行爲,我在這裏爲你作了總結:
若是 x 是 String 或 y 是String,則返回 ToString(x),而後返回ToString(y)
這個花招只適用於數字嗎?並非。 數組和對象也會受到相同的轉換:
'hello' + [89, 150.156, 'mike']
會獲得:
"hello89,150.156,mike"
那麼下面的代碼會獲得怎樣的結果:
'hello' + { name: "Jacopo" }
要找到答案,你能夠經過將對象轉換爲字符串來進行快速測試:
String({ name: "Jacopo" })
將會獲得:
"[object Object]"
因此我有一種感受:
1. 'hello' + { name: "Jacopo" }
會獲得:
1. "hello[object Object]"
打住!這又是什麼?
「[object Object]」 是最多見的 JavaScript 「怪癖」之一。
幾乎每一個 JavaScript 實例都有一個名爲 toString()
的方法,有些方法是由 Object.prototype.toString
提供的。
某些類型(如數組)實現了 toString()
的自定義版本,以便在調用方法時將值轉換爲字符串。例如 Array.prototype.toString
會覆蓋 Object.toString()
(也稱爲 method shadowing)。
可是當你在普通的 JavaScript 對象上調用 toString()
時,引擎會給出「[object Object]」,由於 Object.toString()
的默認行爲是由實體類型(在這種狀況下爲Object)返回字符串 object 。
如今讓咱們把注意力集中在 JavaScript 比較運算符上,它們與算術運算符同樣奇怪。
JavaScript 中有兩個主要的比較運算符。
第一個咱們稱之爲「弱比較」。這是抽象比較運算符(雙等號):==
。
另外一個是「強比較」,能夠經過三等號進行識別:===
也稱爲嚴格比較運算符。它們二者的行爲方式徹底不一樣。
來看一些例子。首先,若是咱們將兩個字符串與兩個運算符進行比較,咱們獲得相同的結果
"hello" == "hello" > true "hello" === "hello" > true
看上去一切都還好。
如今嘗試比較兩種不一樣的類型,數字和字符串。首先是「強比較」:
1. "1" === 1 2. false
這說得通!字符串「1」與數字1是不一樣的。可是「弱比較」會發生什麼?
1. "1" == 1 2. true
竟然是true!它沒有任何意義,除非這種行爲與咱們以前看到的隱式轉換有關。
若是適用相同的規則怎麼辦?沒錯! ECMAScript spec 再次罷工。結果抽象比較運算符在比較它們以前在類型之間進行自動轉換。這是規範的摘要:
比較 x == y 執行以下:若是 x 是 String 且 y 是Number,則返回比較結果 ToNumber(x)== y
規範說:若是第一個操做數是一個字符串,第二個操做數是一個數字,那麼將第一個操做數轉換爲數字。有趣。
JavaScript 規範充滿了這個瘋狂的規則,我強烈鼓勵你們對它深刻挖掘。
在此期間除非你有充分的理由不然在 JavaScript 代碼中避免使用抽象比較運算符。你之後會感謝本身的。
那麼「強勢比較」怎麼樣?規範中的說 嚴格相等比較在把值與三等 ===
進行比較以前沒有進行自動轉換。在代碼中使用嚴格相等比較能夠避免愚蠢的 bug。
JavaScript 中有七個構建塊,即 String,Number,Boolean,Null,Undefined,Object 和 Symbol。這些類型被稱爲基元。
JavaScript 開發人員可使用算術和比較運算符來操做這些類型。可是咱們要特別注意加法運算符 +
和抽象比較運算符 ==
,它本質上傾向於在類型之間進行轉換。
JavaScript 中的隱式轉換稱爲強制類型轉換,並在 ECMAScript 規範中定義。不管何時你的代碼都要使用嚴格的比較運算符 ===
而不是 ==
。
做爲最佳實踐,當你打算在兩種類型之間進行轉換時,請務必明確操做。JavaScript 有一堆內置對象,它們反映了原始類型:String
,Number
,Boolean
。這些內置類型可用於在不一樣類型之間進行顯式轉換。