在ES6以後,Reflect與Proxy API是實作meta-programming的利器,但開發者多半的誤解是「Reflect為Proxy而生,Reflect API不過是Object的進階版」;實際上兩者同等重要,獨立思考存在的意義,試著結合兩者時,才有更大助益。

ESLint與Reflect

先前〈ES6與meta程式設計〉提過,符號(Symbol)、Proxy與Reflect,是ES6以後提供的meta-programming利器。多數開發者應該最熟悉「符號」,它主要用來定義獨一無二的行為象徵,不同符號對物件來說,代表著不同metadata,具體而言,就是透過符號實作物件間的協定掛勾,有些符號實作甚至能影響語言內建語法、運算子的行為,如Symbol.hasInstance可以影響instanceof的結果等。

相對來說,Reflect的角色看似尷尬,不少文件都會細談符號與Proxy,然而,對Reflect都是約略帶過,這不禁令人產生疑問:不搭配Proxy,Reflect就無用武之地了嗎?另外,Reflect上的API為何與Object有所重疊?

解答這兩個疑問的來源之一,是ESLint的〈prefer-reflect〉(https://bit.ly/2ZxcuCY),列出一些用Reflect API取代函式apply或Object API的建議。

開發者多半知道控制函式的this時,可以使用函式繼承而來的apply與call方法;然而,對於函式func.apply(self, args),實際是在隱含地假設函式實例本身沒有定義apply方法,若想避免這層假設,方式之一,是使用Function.prototype.apply.apply(o.test, [o, [o, o]]),就程式碼的閱讀上,這麼做顯然難以理解;Reflect.apply沒有這層顧慮,同樣的需求改用Reflect.apply(func, obj, args)就簡潔多了。

另一方面,若仔細觀察Reflect與Object重疊的API,我們可以發現,Reflect列出的API,能夠用來存取JavaScript引擎的內部方法(Internal method),而且,這些內部方法,實現了CMAScript中、、等演算規範(可參考https://bit.ly/2MDPjDj)。

為了便於辨識,這類與底層審視(Introspection)相關的API,未來基本上會以Reflect作為名稱空間,因此,ESLint才建議,使用Reflect上的getOwnPropertyDescriptor、getPrototypeOf等,來取代Object上既有的對應函式;將來與物件處理相關,然而不涉及引擎底層的API,才是新增到Object,例如,ES10新增的Object.fromEntries等。

Reflect、物件與運算子

除了提供審視引擎底層的API之外,Reflect上有些函式,可以對物件做進階控制。例如,物件可以定義設值函式(setter)與取值函式(getter),然而無法直接取得這類函式實例,這意謂著,此類函式實作中,若有this關鍵字,無法透過函式apply、call,或Reflect.apply來調整對象。然而,Reflect提供了set與get函式,它們都提供一個可選的receiver參數,可用來指定設值函式、取值函式的this對象。

Reflect也將原本只以運算子形式呈現的行為,以函式方式提供。例如,in運算子的對應是Reflect.has,這比較沒有問題,傳回值是布林值,若被測試的不是物件,也是拋回TypeError;new運算子的行為對應是Reflect.construct,對於建構式C來說,new C(1, 2, 3)這個動作,可以使用Reflect.construct(C, [1, 2, 3]),但是,不可以使用C.apply({}, [1, 2, 3]),因為這只是等同於C(1, 2, 3)呼叫罷了。

不少文件都會談到,Reflect.construct可以令new建構式這個動作接受陣列作為引數。實際上,這需求只要藉由Spread運算子也可達到,例如new C(...[1, 2, 3])。比較重要的功能其實是,ES6以後新增new.target,在使用new建構實例時,new.target代表了建構式或類別本身,否則就會是undefined,而Reflect.construct第三個可選參數,就可用來控制new.target的對象,也就是說,相對於使用new建構物件,Reflect.construct能控制的更多。

delete運算子的對應是Reflect.deleteProperty,不過,在行為上有些修正。在嚴格模式下,若用delete刪除不可組態的特性,會引發TypeError;然而,Reflect.deleteProperty刪除不可組態特性時只會傳回false,看似回歸到delete在非嚴格模式下的行為。

因此,對於ESLint建議使用Reflect.deleteProperty來取代delete,開發者持有各自不同的觀點(https://bit.ly/31mVKi9)。有的人從簡潔性、速錯觀點支持delete;有人從可讀性、Reflect API的一致性支持Reflect.deleteProperty。我個人是覺得,在嚴格模式下,刪除不可組態特性既然有兩個選擇,就看需求而定,不見得要按照ESLint的建議。

實現代理模式的Proxy

代理模式簡單來說,是提供一個代理物件給客戶端操作,代理物件具有與目標物件相同的介面,在客戶端對實作毫不知情下,不會意識到正在操作的是代理物件,而代理物件可以單純地將任務轉發給目標物件,或者是在這前後附加額外的邏輯。

在ES6以後,可以透過建構Proxy來實現代理模式,建構時指定目標物件以及處理器,處理器可以代理的行為,與Reflect一對一對應(因此才會有「Reflect為Proxy而生」的這種說法吧!)也就是說,可以代理的介面不單是物件特性,也包括了、、等底層行為,某些程度來說,就是讓開發者可以干涉JavaScript引擎的行為。

要活用Proxy,深入認識Reflect是必要的,因為Proxy提供干涉內部方法的時機,Reflect提供存取內部方法的管道,兩者結合就提供meta-programming的重量級支援,只是簡單地干涉get、set,就能實現日誌、驗證、效能量測等常見需求,透過has、construct、deleteProperty,開發者還能神不知鬼不覺地干涉、改變in、new、delete運算子的行為。

雖說如此,還是要有分寸,實現代理模式基本原則,是「在客戶端對實作毫不知情下,不會意識到正在操作的是代理物件」,引擎為此提供了一定程度的檢測,若明顯地被違反物件協定,試圖實作代理會拋出TypeError。

例如,target的foo特性configurable與writable,若都是false,特性值為10,底下程式碼會拋出錯誤:

const proxy = new Proxy(target, {
get() { return 20; }
});
console.log(proxy.foo);

如果從違反協定的角度來理解,原因就很簡單,由於configurable與writable都是false,這表示該特性是個不能刪的常數10。在上例中,代理物件的實作卻試圖傳回20,顯然違反協定;類似地,若target特性的configurable為false,代理物件的處理器deleteProperty方法傳回true,就會引發TypeError。

獨立地思考Reflect、Proxy

Reflect不是Object的進階版,而是與Proxy更是同等重要的存在,開發者應獨立地思考Reflect API存在之意義,有興趣的話,你可以進一步參考〈What does the Reflect object do in JavaScript?〉(https://bit.ly/2Yva8I8)的討論。

事實上,Proxy肩負的職責是實現代理模式,應該思考代理模式的意義,而不是同時思考Proxy與Reflect可以做到的部分,否則遇到無法代理的情況時,也許會覺得不明就理;若能思考這兩個API各自存在的意義,自然能理解何時兩者應該結合,也才能發揮meta-programming的最大可能性。

作者簡介


Advertisement

更多 iThome相關內容