在JavaScript當中,直到ES5為止,都只有陣列,到了ES6之後持續對陣列進行加強,並加入了ArrayBuffer、TypedArray等,在字典與集合方面,提供Map、WeakMap、Set、WeakSet等類型。因此,開發者應認識這些API特性,在適當場合善加利用,不過,需留意API之間的不一致。

熟悉又陌生的陣列

JavaScript的陣列,本質上就是物件,索引其實就是使用數字作為特性名稱,物件若以數字為特性名稱並加上length,就成了類陣列(Array-like)物件。

若將物件的__proto__指定為Array.prototype,類陣列物件甚至會被instanceof視為Array實例,功能上,就差在無法依元素個數自行維護length值;在其他語言,陣列通常不被視為群集,然而在JavaScript中,由於Array.prototype定義了shift、unshift、push、pop等函式,使得陣列本身可以不只是陣列,也能作為列表(list)、堆疊(stack)來使用。

另一方面,JavaScript本身具備函數式的風格,而在Array.prototype物件上,也定義了filter、map、reduce、some、every等具備函數式風格的函式,未來ES10也預計新增具備Monad概念的flatMap函式。若能善用這類函數式風格函式,不單是程式碼的可讀性,在效率上也可以有所改進。

JavaScript開發者對於陣列,或許很熟悉,然而由於歷史性的原因,陣列使用上有不少的坑。最經典的就是sort函式,預設排序的順序,竟然是根據元素轉字串後的Unicode碼點(code point),而且排序結果是否穩定(Stable),一直都是依實作環境而定,由於大部份主流瀏覽器在實作上都採穩定排序,目前TC39中出現了提案,考慮將穩定排序納入規範之中(https://bit.ly/2QHnVEf)。

陣列API在處理NaN、undefined或空項目(empty item)時,也必須留意不一致的行為。indexOf、lastIndexOf無法處理NaN,因為它們使用===來比對元素,而NaN不等於NaN,陣列中若有NaN作為元素,這兩個函式無法找到它;ES6新增了findIndex,可以使用arr.findIndex(elem => elem !== elem)來尋找NaN,因為NaN是唯一不等於自身的值,另外,ES6新增的includes也可以處理NaN,若陣列arr中有NaN,arr.includes(NaN)會是true。

對於陣列具有undefined與空項目的情況,不少開發者會混淆,例如,搞不清楚 [1, undefined, 3]與[1,,3]的差別。

試著用1 in來測試看看兩者吧!前者確實有索引1的元素,後者沒有;實務開發上,應該避免陣列中出現空項目,因為API對空項目的處理方式並不一致,例如,filter、every等會跳過空項目,不會視為undefined傳入回呼函式,map雖然也不會傳入undefined,然而最後結果會保留空項目(而非undefined),join卻會將空項目視為undefined等。

處理位元組資料

使用XMLHttpRequest Level 1、Fetch API時,若要接受位元組資料,就會接觸到ArrayBuffer、TypedArray等介面。這些介面包含在ES6中,然而它們其實更早是WebGL規範的一部份,為了JavaScript與GPU之間位元組資料處理的需求而存在。

真正用來儲存位元組資料的是ArrayBuffer,就真的只代表位元組資料,除了byteLength可以得知長度,slice方法能夠進行切割之外,沒什麼能做的。怎麼看待這組位元組資料,視開發者選擇哪個TypedArray而定,但TypedArray不是類型,只是一組類型的統稱,像是Int8Array、Uint8Array、Int16Array、Float32Array等,而這些是類陣列,然而也擁有與Array相似的函式,像是filter、map、forEach等。

ArrayBuffer單純就代表著一組位元組,TypedArray才擁有操作位元組的觀點(View),一個ArrayBuffer不單只能有一個TypedArray觀點,TypedArray可以選定ArrayBuffer任何一個區段來操作,因此,一個ArrayBuffer實例,可以含有多種結構的資料,使用多個TypedArray來操作。

如果需要更隨意地處理ArrayBuffer中的位元組資料,可以用DataView來看待ArrayBuffer,它提供getInt8、setFloat32等更靈活的方法,可以從指定索引處,以指定的觀點來設定與取得資料,如果需要確認ArrayBuffer採用的位元組順序(Endianness),是大端序(big-endian)或小端序(little-endian),我們也可以使用DataView,例如:

const littleEndian = (() => {
const buffer = new ArrayBuffer(2);
new DataView(buffer).setInt16(0, 256, true);
return new Int16Array(buffer)[0] === 256;
})();

主流瀏覽器與Node.js採用小端序,然而,網站回應的資料或許不是,如果上頭的程式片段略做修改,令buffer代表著接受到的位元組資料,就可以用來判斷回應資料的位元組順序。

字典與集合

JavaScript很長一段時間,沒有內建字典這類資料結構,原因或許在於其物件本身,本質上就是個鍵值複合體,搭配in、delete、[]等,也能達到字典的相關操作,只不過鍵只能是字串,因為JavaScript在相等性方面,並沒有像其他語言中,有equals、hashCode之類的協定,就算鍵只能是字串,也已經滿足許多場合時的字典操作需求。

然而,物件終究不是字典類型,在ES6新增了Map,可以使用物件作為鍵,Map本身也可以進行迭代,在需要字典對應的場合時,ES6之後應該選擇Map而不是物件;另外,ES6也新增了Set,作為元素不得重複的集合操作時,使用上還算方便。

不得重複,正是使用Map、Set時必須注意的。Map的鍵不得重複,Set的元素不得重複,那麼,開發者知道判定重複的標準是什麼嗎?因為歷史性的原因,JavaScript有四種相等性的判定方式,分別是抽象相等、嚴格相等、SameValue與SameValueZero演算,不同的API採用的相等性判斷,並不相同,這在先前專欄〈ECMAScript 6相等演算〉曾經討論,而Map、Set採用的是SameValueZero演算。

談到Map、Set時,通常也會談到ES6新增的WeakMap、WeakSet,簡單來說,垃圾收集時,不會考慮物件是否被WeakMap作為鍵,或者是否為WeakSet的元素,只要物件沒有其他名稱參考著,就會回收物件,在一些場合可避免記憶體洩漏狀況。

例如,若要建立與物件對應的資料,物件可作為Map的鍵,對應資料為值的部份,但須在物件不使用時,自行刪除Map中的鍵值,開發者一疏忽這點,就會發生記憶體洩漏,若用WeakMap可避免。

在撰寫本文的這個時間點,TC39有個處於階段2的WeakRef提案(https://bit.ly/2MqtJDO),當一個變數或特性參考至WeakRef實例時,並不會被計入參考計數,垃圾收集時,可以回收該物件,而其應用的場合之一,是可以將WeakRef實例作為Map的值,實現快取的功能。

留意API的不一致

判斷一門語言是否越來越成熟,從內建的群集API往往可見一斑。從這點來看,JavaScript確實朝著越來越成熟的道路前進,開發者應多加留意與善用。

然而,JavaScript畢竟是從不成熟狀態逐步發展而來,由於歷史性的原因,有些特性令API在使用上,有著奇怪甚至不一致的結果。所以,開發者在使用前,應瞭解並測試API的行為確實符合所需,畢竟,與不一致為伍,也是使用JavaScript必要的課題!

作者簡介


Advertisement

更多 iThome相關內容